From Hannes.Tschofenig@gmx.net Thu Oct 1 00:15:52 2009 Return-Path: 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 DD7C03A67B6 for ; Thu, 1 Oct 2009 00:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[AWL=0.616, 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 3GmABO-BPdcd for ; Thu, 1 Oct 2009 00:15:52 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 7DE6B3A67A1 for ; Thu, 1 Oct 2009 00:15:51 -0700 (PDT) Received: (qmail invoked by alias); 01 Oct 2009 07:17:14 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.123.77] by mail.gmx.net (mp005) with SMTP; 01 Oct 2009 09:17:14 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+l3sgpIZmlagivg3IWiFOhpivxaHiN4sc/yGEPwH rqFiysB+KwqXvU From: "Hannes Tschofenig" To: "'Ted Hardie'" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" References: <3D3C75174CB95F42AD6BCC56E5555B4501BE7D30@FIESEXC015.nsn-intra.net> <6e04e83a0909300944n2cd0ded0xef54b1b671de42c4@mail.gmail.com> Date: Thu, 1 Oct 2009 10:20:13 +0300 Message-ID: <031901ca4267$a001fcf0$8501fe0a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpB7UaKEzreg9EiSbSTrZHbjsxgzAAeityA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <6e04e83a0909300944n2cd0ded0xef54b1b671de42c4@mail.gmail.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54 Cc: ecrit@ietf.org Subject: Re: [Ecrit] Service URN IANA Policy 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: , X-List-Received-Date: Thu, 01 Oct 2009 07:15:53 -0000 Hi Ted, >Howdy, > >I don't have any problems with this allocation policy, but I >see two things in the draft that should probably change. The >appointment should be by the IESG, not the RAI area director >or directors; this is the traditional appointment mechanism >and it allows other ADs to contribute, even if RAI leads. For >services that are not SOS-related, other areas may have >significant input. Sounds reasonable. Second, some text in the document that >describes the conditions under which new entries are approved >or denied is very useful, as it guides the later incumbents in >the role. In the URI space, for example, there are two >strains of thought about minting new schemes: one is that it >should be restricted to cases which absolutely cannot be met >by an existing scheme; the second is that the schemes will be >minted anyway and that registration largely serves to avoid >interoperability problems. >Having the working group provide general guidance on this >point is very useful, in my opinion. Sounds also useful. Andrea + Henning: Could you make these changes? Ciao Hannes > >My two cents, > >Ted > >On Wed, Sep 30, 2009 at 6:36 AM, Tschofenig, Hannes (NSN - >FI/Espoo) wrote: >> Hi all, >> >> we discussed the need to change the IANA allocation policy for the >> definition of new top-level services within this working group a few >> times. With the >> http://tools.ietf.org/html/draft-forte-ecrit-service-urn-policy-00 >> proposal Henning and Andrea have describe the modification. We would >> change the allocation policy of top-level services from "Standards >> Action" to "Expert Review". >> >> The policy for assigning labels to sub-services is left >unchanged and >> may differ for each top-level service designation and must >be defined >> by the document describing the top-level service. For the >Service URN >> RFC (RFC 5031) two sub-services are defined, namely 'sos' >and 'counseling'. >> The policy for adding sub-services to the 'sos' and the 'counseling' >> services, as defined in RFC 5031, is "Expert Review". >> >> In order to progress draft-forte-ecrit-service-urn-policy-00 >we would >> like to know whether someone has problems with this >allocation policy >> change. >> >> Ciao >> Hannes & Marc >> _______________________________________________ >> 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 khwolf1@gmail.com Thu Oct 1 06:41:30 2009 Return-Path: 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 576AF3A6A64 for ; Thu, 1 Oct 2009 06:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.737 X-Spam-Level: X-Spam-Status: No, score=-1.737 tagged_above=-999 required=5 tests=[AWL=0.863, 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 cwnvX4QH5bUG for ; Thu, 1 Oct 2009 06:41:29 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by core3.amsl.com (Postfix) with ESMTP id 5B7643A67F1 for ; Thu, 1 Oct 2009 06:41:27 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id e21so1595369fga.13 for ; Thu, 01 Oct 2009 06:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=Zfku6w0DmRPKZyu5Pt/h5CrAt0u340TF30Caco2VwBw=; b=COL2NdA5AfX95QKY0leQIYML5d9QwpQOaQ2FAwYbGTeoPlKo2T9pPciGUAXuqZ+3Uh tep2WMLzmoj8nbrMZwCMzyOiJ+DyAPmObWB50OGodtrDE5NRp9vakHo8n6NwP1huAMNF OCdRPaWpf+8icekQJkj9qqAmi9a+7L5Jz3bYA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=R598wBRtPCG9sO/OqmXk7/qI9HekxFz8cTwcmiiZT0xpWgayUdkh5Lu0sg4ajP7SjI qYHOWKGS7Boa1f+PXSJN8OxVq4WDvCLof7l5hGt8NsqU8ScCBp5QeLF6RLC8zX5SkSoy YNUnaksI12M/sQgE+zJgU68B52u6p6WDD3DA0= MIME-Version: 1.0 Received: by 10.86.226.32 with SMTP id y32mr1108906fgg.77.1254404566947; Thu, 01 Oct 2009 06:42:46 -0700 (PDT) Date: Thu, 1 Oct 2009 15:42:46 +0200 Message-ID: From: Karl Heinz Wolf To: ECRIT Content-Type: text/plain; charset=ISO-8859-1 Subject: [Ecrit] New Version Notification for draft-wolf-ecrit-lost-servicelistboundary-02 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: , X-List-Received-Date: Thu, 01 Oct 2009 13:41:30 -0000 I just posted a new version of the service list boundary draft: http://www.ietf.org/id/draft-wolf-ecrit-lost-servicelistboundary-02.txt Since there was some confusion about this draft I want to mention again that it is not about changes in time of the service list. The issue is that in different places, different services may be offered. The listServicesByLocation query tells which services are available at a particular location but the client has no way to figure out when to perform a new listServicesByLocation query in order to not miss the availability of a service when moving. As a solution this draft proposes a boundary information which tells the client the area a service list is valid for. There was also some discussion if it is possible to create such boundaries. I added the following paragraph to the draft: The mapping architecture and framework [RFC5582] describes that each tree announces its coverage region (for one type of service, e.g. sos.police) to one or more forest guides. Forest guides peer with each other and synchronize their data. Hence, a forest guide has sufficient knowledge (it knows all the services and their coverage regions) to answer a listServicesByLocation query and additionally add the serviceListBoundary as well. Comments are appreciated. Thanks, Karl Heinz From jmpolk@cisco.com Thu Oct 1 14:53:28 2009 Return-Path: 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 46CDD3A6861 for ; Thu, 1 Oct 2009 14:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.5 X-Spam-Level: X-Spam-Status: No, score=-6.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 I86u+1-dIx4q for ; Thu, 1 Oct 2009 14:53:27 -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 647633A6857 for ; Thu, 1 Oct 2009 14:53:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1999; q=dns/txt; s=sjiport06001; t=1254434094; x=1255643694; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"James=20M.=20Polk"=20 |Subject:=20Re:=20[Ecrit]=20Service=20URN=20IANA=20Policy |Date:=20Thu,=2001=20Oct=202009=2016:54:51=20-0500 |Message-ID:=20|To:=20"Tschofenig,=20Hannes=20(NSN=20-=20F I/Espoo)"=20,=0D=0A=20=20=20 =20=20=20=20=20|Mime-Version:=201.0 |In-Reply-To:=20<3D3C75174CB95F42AD6BCC56E5555B4501BE7D30 @FIESEXC015.nsn-in=0D=0A=20tra.net>|References:=20<3D3C75 174CB95F42AD6BCC56E5555B4501BE7D30@FIESEXC015.nsn-intra.n et>; bh=RXTgflCBSIEkO+G67y7FOhAN/qdnr1VjS8hPHjWpOLQ=; b=sU9UaWtrqtkMaeoPgniE/yhwB7U6eGr29Ac4BGDFAHfT4lc1Btm75hRC Gm6mzSycWMfDp3gEVQRRyUl+cpo8PExgqhIiDV9k++vJckFC0F6r+ECBx U7z9HD8ParViVjStffJv7xrMwrriyznyq83J97L6pZW5mpS/C4v7d97wT k=; Authentication-Results: sj-iport-6.cisco.com; dkim=pass (signature verified [TEST]) header.i=jmpolk@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoEAB3CxEqrR7MV/2dsb2JhbACIFrddiFsBj08GgjeBcg X-IronPort-AV: E=Sophos;i="4.44,489,1249257600"; d="scan'208";a="400366566" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 01 Oct 2009 21:54:53 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n91Lsrmn010924; Thu, 1 Oct 2009 14:54:53 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n91Lsr2l011231; Thu, 1 Oct 2009 21:54:53 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Oct 2009 14:54:53 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.0.122]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Oct 2009 14:54:52 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 01 Oct 2009 16:54:51 -0500 To: "Tschofenig, Hannes (NSN - FI/Espoo)" , From: "James M. Polk" In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4501BE7D30@FIESEXC015.nsn-in tra.net> References: <3D3C75174CB95F42AD6BCC56E5555B4501BE7D30@FIESEXC015.nsn-intra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 01 Oct 2009 21:54:52.0996 (UTC) FILETIME=[CE50D840:01CA42E1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1999; t=1254434093; x=1255298093; c=relaxed/simple; s=sjdkim1004; 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]=20Service=20URN=20IANA=20Policy |Sender:=20; bh=RXTgflCBSIEkO+G67y7FOhAN/qdnr1VjS8hPHjWpOLQ=; b=LLydAA2ClCLwOV7dCtGW6uPKjih1432wdGQAxhjNxapgopyULaD5W1N+2O OWI3ZcotTNg6G8YocvpIzoVF2N00pH0ip9Yka4RH07sphJrSK0VUl3SbIUnx hPgoORhUQOtAtu9k4XbVFy1qISBuMD3Fszd8RAd8tbz9IGOnBRWdI=; Subject: Re: [Ecrit] Service URN IANA Policy 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: , X-List-Received-Date: Thu, 01 Oct 2009 21:53:28 -0000 Chairs With respect to http://www.ietf.org/internet-drafts/draft-polk-ecrit-lost-geocoding-00.txt and forte's draft, I assume they keep -ecrit- in their filename, and are individually submitted to the RFC-Editor when the author feels they are ready? I don't mean this to be nefarious sounding, as I plan on working within the WG until this doc has consensus of at least those that care about it (knowing that because this isn't going to be a WG item, the whole WG doesn't necessarily need to have reached consensus. Is this the general plan of action for these types of IDs? Of should each of these IDs have -ecrit- removed from the filenames because there is no hope of them ever being WG items now? Looking for clarification and guidance James At 08:36 AM 9/30/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >Hi all, > >we discussed the need to change the IANA allocation policy for the >definition of new top-level services within this working group a few >times. With the >http://tools.ietf.org/html/draft-forte-ecrit-service-urn-policy-00 >proposal Henning and Andrea have describe the modification. We would >change the allocation policy of top-level services from "Standards >Action" to "Expert Review". > >The policy for assigning labels to sub-services is left unchanged and >may differ for each top-level service designation and must be defined by >the document describing the top-level service. For the Service URN RFC >(RFC 5031) two sub-services are defined, namely 'sos' and 'counseling'. >The policy for adding sub-services to the 'sos' and the 'counseling' >services, as defined in RFC 5031, is "Expert Review". > >In order to progress draft-forte-ecrit-service-urn-policy-00 we would >like to know whether someone has problems with this allocation policy >change. > >Ciao >Hannes & Marc >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From Hannes.Tschofenig@gmx.net Thu Oct 1 23:27:28 2009 Return-Path: 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 5ACE53A6A01 for ; Thu, 1 Oct 2009 23:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.027 X-Spam-Level: X-Spam-Status: No, score=-2.027 tagged_above=-999 required=5 tests=[AWL=0.572, 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 ZeEM2CvfRPQN for ; Thu, 1 Oct 2009 23:27:27 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 7D63F3A6993 for ; Thu, 1 Oct 2009 23:27:26 -0700 (PDT) Received: (qmail invoked by alias); 02 Oct 2009 06:28:51 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.123.77] by mail.gmx.net (mp025) with SMTP; 02 Oct 2009 08:28:51 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18XjdszHlAXHWCqelRuWrOfRTPh7Gg1dEGDsD5EpF DqCt4l+4fETBqr From: "Hannes Tschofenig" To: "'James M. Polk'" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , References: <3D3C75174CB95F42AD6BCC56E5555B4501BE7D30@FIESEXC015.nsn-intra.net> Date: Fri, 2 Oct 2009 09:31:52 +0300 Message-ID: <033a01ca432a$085bc5c0$8501fe0a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpC4dFM7XNEBgtKThqN8RhojwAW9AARxMRw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.55 Subject: Re: [Ecrit] Service URN IANA Policy 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: , X-List-Received-Date: Fri, 02 Oct 2009 06:27:28 -0000 Hi James, >Chairs > >With respect to >http://www.ietf.org/internet-drafts/draft-polk-ecrit-lost-geoco >ding-00.txt >and forte's draft, I assume they keep -ecrit- in their >filename, and are individually submitted to the RFC-Editor >when the author feels they are ready? Andrea has worked on a few documents, namely: http://tools.ietf.org/html/draft-forte-ecrit-service-urn-policy http://tools.ietf.org/html/draft-forte-ecrit-service-classification http://tools.ietf.org/html/draft-forte-ecrit-lost-extensions So, which one do you mean? Regarding your document draft-polk-ecrit-lost-geocoding-00.txt >From what I could hear at the last IETF meeting (via my remote participation) a couple of folks had suggestions regarding your document and they roughly proposed the following approach: * Define a protocol for geocoding (not based on LoST) * Define a discovery mechanism (based on LoST) for discovering the server that does the geocoding Regarding the overall approach of working on non-emergency services I have not spoken to Cullen/Robert about this particular document. I plan to post a separate mail about our very recent chat with them. > >I don't mean this to be nefarious sounding, as I plan on >working within the WG until this doc has consensus of at least >those that care about it (knowing that because this isn't >going to be a WG item, the whole WG doesn't necessarily need >to have reached consensus. > >Is this the general plan of action for these types of IDs? > >Of should each of these IDs have -ecrit- removed from the >filenames because there is no hope of them ever being WG items now? > >Looking for clarification and guidance Thanks for raising this issue. Ciao Hannes > >James > >At 08:36 AM 9/30/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>Hi all, >> >>we discussed the need to change the IANA allocation policy for the >>definition of new top-level services within this working group a few >>times. With the >>http://tools.ietf.org/html/draft-forte-ecrit-service-urn-policy-00 >>proposal Henning and Andrea have describe the modification. We would >>change the allocation policy of top-level services from "Standards >>Action" to "Expert Review". >> >>The policy for assigning labels to sub-services is left unchanged and >>may differ for each top-level service designation and must be defined >>by the document describing the top-level service. For the Service URN >>RFC (RFC 5031) two sub-services are defined, namely 'sos' and >'counseling'. >>The policy for adding sub-services to the 'sos' and the 'counseling' >>services, as defined in RFC 5031, is "Expert Review". >> >>In order to progress draft-forte-ecrit-service-urn-policy-00 we would >>like to know whether someone has problems with this allocation policy >>change. >> >>Ciao >>Hannes & Marc >>_______________________________________________ >>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 Hannes.Tschofenig@gmx.net Fri Oct 2 00:14:16 2009 Return-Path: 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 40BAD3A67F4 for ; Fri, 2 Oct 2009 00:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=0.533, 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 M9nXQt0b+YKM for ; Fri, 2 Oct 2009 00:14:14 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 4438D3A689B for ; Fri, 2 Oct 2009 00:14:07 -0700 (PDT) Received: (qmail invoked by alias); 02 Oct 2009 07:15:33 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.123.77] by mail.gmx.net (mp008) with SMTP; 02 Oct 2009 09:15:33 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19ShUp8OMVSfQXAglXIWAVtr6Iw+QBu+FJWy7EHYo sP/84mNgDYIYb6 From: "Hannes Tschofenig" To: Date: Fri, 2 Oct 2009 10:18:34 +0300 Message-ID: <034d01ca4330$8e1bacb0$8501fe0a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpDMIz7H1v+DgocQJCsPYWkLvH/vQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 Subject: [Ecrit] Status with the work in ECRIT 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: , X-List-Received-Date: Fri, 02 Oct 2009 07:14:16 -0000 Hi all, We wanted to provide you a short status update of the work in ECRIT. In August we proposed the text for the new charter, see http://www.ietf.org/mail-archive/web/ecrit/current/msg06663.html And after the deadline expired we submitted it to our AD so that it gets discussed in the IESG conf. call. Unfortunately, it turned out that a charter approval would come too late for the next meeting (with regard to the draft submission deadlines). Hence, we had a chat (Marc, Cullen, Robert and myself) to chat about the individual items and to determine whether they can be submitted without a re-chartering activitiy. We also spoke about the charter overall. The feedback from our Ads regarding the charter was that they see it as a bit too open-ended and hence want us to make it more restrictive. We will do that. Regarding the documents we had the following discussion: Oct 2009 Submit "IANA Registering a SIP RPH Namespace for Local Emergency Communications" to the IESG for consideration as a Standards Track RFC --> This is an item that requires rechartering and Marc will discuss a few questions on the list, namely * Where will it be used? * Why is it needed? * How is it secured? Cullen and Robert expect problems in the IESG with this document and hence they would like to get some of the questions being addressed already in the working group (rather at an IESG review later). Dec 2009 Submit "LoST ServiceListBoundary Extension" to the IESG for consideration as an Experimental RFC -> This is OK within the current charter but the suggested wording for the milestone has to be changed to make it more understandable. Dec 2009 Submit "Registry Policy Update to RFC 5031" to the IESG for consideration as a Standards Track RFC -> The text will have to be changed to "Update IANA consideration procedures for Service URN allocation (RFC 5031)" and it is believed to be OK within the current charter. Nevertheless, Cullen wants to check with the other Ads whether they agree with it. So, at the moment it will not be added to the charter. Jan 2010 Submit "Location-to-Service Translation Protocol (LoST) Extensions" to the IESG for consideration as an Informational RFC --> This document clearly goes beyond the emergency services use case. The suggestion was made (and I like that idea) that the ECRIT group would do reviews and the AD would shepherd the document as an Experimental RFC. Another option that is always possible for any extension that does not fit into the scope of the ECRIT charter can be submitted to DISPATCH. What this means from a time schedule point of view I don't know. May 2010 Submit "Marking of Calls initiated by Public Safety Answering Points (PSAPs)" to the IESG for consideration as an Informational RFC --> Cullen suggested to re-phrase it so that the call-back aspect is more visible (rather than touching on the generic authority-to-citizen communication topic). He believes that the document is not yet ready for a WG item since the group has not decided on one of the solutions in the document yet. Hannes got the action item to discuss the described solution approaches with the group and to pick one. May 2010 Submit "Emergency Services Architecture Extensions for Unauthenticated and Unauthorized Devices" to the IESG for consideration as an Experimental RFC --> We need to add a paragraph to the charter describing this task. Mar 2010 Submit "Using Imprecise Location for Emergency Context Resolution" to the IESG for consideration as an Informational RFC --> This document falls under the current charter. Based on the above-mentioned comments we have submitted the following milestone update to the IESG secretary: --------- Done Informational RFC containing terminology definitions and the requirements Done An Informational document describing the threats and security considerations Done A Standards Track RFC describing how to identify a session set-up request is to an emergency response center Done A Standards Track RFC describing how to route an emergency call based on location information Done An Informational document describing the Mapping Protocol Architecture Done Submit 'Location Hiding: Problem Statement and Requirements' to the IESG for consideration as an Informational RFC. Done Submit 'Framework for Emergency Calling using Internet Multimedia' to the IESG for consideration as an Informational RFC. Done Submit 'Best Current Practice for Communications Services in support of Emergency Calling' to the IESG for consideration as a BCP document Oct 2009 Submit 'Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements' to the IESG for consideration as an Experimental RFC. Dec 2009 Submit "LoST Extension for returning Boundary Information for Services" to the IESG for consideration as an Experimental RFC Mar 2010 Submit "Using Imprecise Location for Emergency Call Routing" to the IESG for consideration as an Informational RFC ---------- As you can see, it contains 2 new documents. 2 others might follow soon (hopefully!). Ciao Hannes & Marc From Hannes.Tschofenig@gmx.net Fri Oct 2 01:17:13 2009 Return-Path: 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 B784A28C0FE for ; Fri, 2 Oct 2009 01:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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 xHUBUZHPjBBz for ; Fri, 2 Oct 2009 01:17:12 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 59E8E3A6931 for ; Fri, 2 Oct 2009 01:17:11 -0700 (PDT) Received: (qmail invoked by alias); 02 Oct 2009 08:18:37 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.123.77] by mail.gmx.net (mp020) with SMTP; 02 Oct 2009 10:18:37 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/gc7gvoBjgv7cJQSqiDP5BwfrTowaXmZmHTF96kr 0zNtIVJbkVuyEY From: "Hannes Tschofenig" To: Date: Fri, 2 Oct 2009 11:21:37 +0300 Message-ID: <035601ca4339$5da67f70$8501fe0a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpDOVwhamb7JDIfRrCie3fgt4zlLg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.59 Subject: [Ecrit] Status of the ongoing document editing work 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: , X-List-Received-Date: Fri, 02 Oct 2009 08:17:13 -0000 Hi all, based on the chat with various document authors I will try to summarize the open issues with the current documents: * Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements --> Update needed based on the discussions on the list (initially triggered by Karl Heinz) * draft-barnes-ecrit-rough-loc --> No open issues known * draft-patel-ecrit-sos-parameter --> Milan told me at the end of August that he had a discussion about the document offline at the meeting (Cullen is the AD shepherd). Cullen has agreed to take the draft forwards and there are no further issues with this draft from the working group point of view nor from Cullen's review. So, the document is on Cullen's plate. * draft-wolf-ecrit-lost-servicelistboundary --> Karl Heinz updated the document based on the feedback from Ted. There are no known open issues. * "IANA Registering a SIP RPH Namespace for Local Emergency Communications" As mentioned in my other mail (see http://www.ietf.org/mail-archive/web/ecrit/current/msg06710.html) Marc is going to discuss a few issues on the list. I believe that James said that he does not see any open issues with the document at the moment. * "Registry Policy Update to RFC 5031" I have recently posted a mail to the list about this document, see http://www.ietf.org/mail-archive/web/ecrit/current/msg06704.html A draft update is necessary. * "Marking of Calls initiated by Public Safety Answering Points (PSAPs)" I will trigger a discussion about the solution approaches on the list, as mentioned in http://www.ietf.org/mail-archive/web/ecrit/current/msg06710.html Anything I forgot? Ciao Hannes From jmpolk@cisco.com Mon Oct 5 15:19:49 2009 Return-Path: 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 BF50A3A682A for ; Mon, 5 Oct 2009 15:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.501 X-Spam-Level: X-Spam-Status: No, score=-6.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 c7muOW3kivaW for ; Mon, 5 Oct 2009 15:19:48 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 82CAA3A67B5 for ; Mon, 5 Oct 2009 15:19:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=4880; q=dns/txt; s=sjiport05001; t=1254781283; x=1255990883; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"James=20M.=20Polk"=20 |Subject:=20RE:=20[Ecrit]=20Service=20URN=20IANA=20Policy =20&=20the=20Geocoding=20ID|Date:=20Mon,=2005=20Oct=20200 9=2017:21:21=20-0500|Message-ID:=20|To:=20"Hannes=20Tschof enig"=20,=0D=0A=20=20=20=20=20 =20=20=20"Tschofenig,=20Hannes=20\(NSN=20-=20FI/Espoo\)" =20,=0D=0A=20=20=20=20=20=20 =20=20|Mime-Version:=201.0|In-Reply-To: =20<033a01ca432a$085bc5c0$8501fe0a@nsnintra.net> |References:=20<3D3C75174CB95F42AD6BCC56E5555B4501BE7D30@ FIESEXC015.nsn-intra.net>=0D=0A=20=0D=0A=20<033a01ca432a$0 85bc5c0$8501fe0a@nsnintra.net>; bh=EDQtveNQ/A8Oyi2gatIq6hEqyHfztNX87exX9Vr2rks=; b=eSCzP2p/dg4i2n5vIswPliSbug8K1zlIbYItibKClpUkldE21l7bAgK9 OnZYyJpCHjw+yJJA0UfQh/ZgBCQ9zbC4dvGoSF6xXnRfSh12j5WtqlnEj 2qgr6B5qfjF+gQX4ddm3VSB4Jxey8h1oVknzOl0mQyt4uAphYGyUGBMPH M=; Authentication-Results: sj-iport-5.cisco.com; dkim=pass (signature verified [TEST]) header.i=jmpolk@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAKMOykqrR7PE/2dsb2JhbACIGbMhiGEBjj0GgjaBdA X-IronPort-AV: E=Sophos;i="4.44,508,1249257600"; d="scan'208";a="97527692" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 05 Oct 2009 22:21:22 +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 n95MLOkb003341; Mon, 5 Oct 2009 15:21:24 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n95MLO8n007280; Mon, 5 Oct 2009 22:21:24 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Oct 2009 15:21:24 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.0.14]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Oct 2009 15:21:23 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 05 Oct 2009 17:21:21 -0500 To: "Hannes Tschofenig" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , From: "James M. Polk" In-Reply-To: <033a01ca432a$085bc5c0$8501fe0a@nsnintra.net> References: <3D3C75174CB95F42AD6BCC56E5555B4501BE7D30@FIESEXC015.nsn-intra.net> <033a01ca432a$085bc5c0$8501fe0a@nsnintra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 05 Oct 2009 22:21:23.0427 (UTC) FILETIME=[2BF05B30:01CA460A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4880; t=1254781284; x=1255645284; 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]=20Service=20URN=20IANA=20Policy =20&=20the=20Geocoding=20ID |Sender:=20; bh=EDQtveNQ/A8Oyi2gatIq6hEqyHfztNX87exX9Vr2rks=; b=prFwEfNfN8RHRekJ1ST5gyaW8sdOIzZW/47qed0idd8nTOurUV4ZTTZDo3 p3bJCw6mwXFnPLpNJkoaebOaOOw25xzKZr6PQhoCok7YQmr7BAXCHWxgzHsm d7pxd4PPdI; Subject: Re: [Ecrit] Service URN IANA Policy & the Geocoding ID 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: , X-List-Received-Date: Mon, 05 Oct 2009 22:19:49 -0000 At 01:31 AM 10/2/2009, Hannes Tschofenig wrote: >Hi James, > > >Chairs > > > >With respect to > >http://www.ietf.org/internet-drafts/draft-polk-ecrit-lost-geoco > >ding-00.txt > >and forte's draft, I assume they keep -ecrit- in their > >filename, and are individually submitted to the RFC-Editor > >when the author feels they are ready? > >Andrea has worked on a few documents, namely: >http://tools.ietf.org/html/draft-forte-ecrit-service-urn-policy >http://tools.ietf.org/html/draft-forte-ecrit-service-classification >http://tools.ietf.org/html/draft-forte-ecrit-lost-extensions > >So, which one do you mean? I meant each of them (I think) >Regarding your document draft-polk-ecrit-lost-geocoding-00.txt > > From what I could hear at the last IETF meeting (via my remote >participation) a couple of folks had suggestions regarding your document and >they roughly proposed the following approach: > >* Define a protocol for geocoding (not based on LoST) >* Define a discovery mechanism (based on LoST) for discovering the server >that does the geocoding There were these two suggestions, but there were others as well - notably from Andy, who said we need to be conscious of the user experience in making this solution have to have more round-trips (or contact more servers) than is necessary - when the information might (I'd argue probably) be in/at the first server contacted (i.e., the first LoST server) -- which is where the initial -00 was thinking. My next rev plans on addressing what Andy offered. Additionally, when looking at the two bullets above, if one looks at them in a reverse order to which they are currently in, that makes for a two-step solution. That's fair, but why do a solution in two steps when one can accomplish this in one step? I believe the best solution is to do both what you suggested and what I'm suggesting above. In other words, use LoST to ask for geocoding. If that server knows the answer, it gives it; if it doesn't know the answer, but knows a server that can solve the geocoding query, it gives the URI of that server (which is more like what LoST is defined to do now). Also, there was a suggestion by Brian that wanted me to move the geocoding URN underneath a new top level URN called "transformation". I've been thinking about this, feeling it probably is a good idea, though I haven't spent enough time on this rev to figure out exactly how I'm going to write it in. >Regarding the overall approach of working on non-emergency services I have >not spoken to Cullen/Robert about this particular document. I plan to post a >separate mail about our very recent chat with them. look forward to that update! > > > >I don't mean this to be nefarious sounding, as I plan on > >working within the WG until this doc has consensus of at least > >those that care about it (knowing that because this isn't > >going to be a WG item, the whole WG doesn't necessarily need > >to have reached consensus. > > > >Is this the general plan of action for these types of IDs? > > > >Of should each of these IDs have -ecrit- removed from the > >filenames because there is no hope of them ever being WG items now? > > > >Looking for clarification and guidance > >Thanks for raising this issue. np -- always here to help ;-) James >Ciao >Hannes > > > > >James > > > >At 08:36 AM 9/30/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > >>Hi all, > >> > >>we discussed the need to change the IANA allocation policy for the > >>definition of new top-level services within this working group a few > >>times. With the > >>http://tools.ietf.org/html/draft-forte-ecrit-service-urn-policy-00 > >>proposal Henning and Andrea have describe the modification. We would > >>change the allocation policy of top-level services from "Standards > >>Action" to "Expert Review". > >> > >>The policy for assigning labels to sub-services is left unchanged and > >>may differ for each top-level service designation and must be defined > >>by the document describing the top-level service. For the Service URN > >>RFC (RFC 5031) two sub-services are defined, namely 'sos' and > >'counseling'. > >>The policy for adding sub-services to the 'sos' and the 'counseling' > >>services, as defined in RFC 5031, is "Expert Review". > >> > >>In order to progress draft-forte-ecrit-service-urn-policy-00 we would > >>like to know whether someone has problems with this allocation policy > >>change. > >> > >>Ciao > >>Hannes & Marc > >>_______________________________________________ > >>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 jmpolk@cisco.com Mon Oct 5 15:24:43 2009 Return-Path: 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 3D2413A679C for ; Mon, 5 Oct 2009 15:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.502 X-Spam-Level: X-Spam-Status: No, score=-6.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 Sm1nGPysvBtB for ; Mon, 5 Oct 2009 15:24:42 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 31FD03A6937 for ; Mon, 5 Oct 2009 15:24:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=924; q=dns/txt; s=sjiport05001; t=1254781576; x=1255991176; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"James=20M.=20Polk"=20 |Subject:=20Re:=20[Ecrit]=20Status=20of=20the=20ongoing =20document=20editing=20work|Date:=20Mon,=2005=20Oct=2020 09=2017:26:03=20-0500|Message-ID:=20|To:=20"Hannes=20Tscho fenig"=20,=20 |Mime-Version:=201.0|In-Reply-To:=20<035601ca4339$5da67f7 0$8501fe0a@nsnintra.net>|References:=20<035601ca4339$5da6 7f70$8501fe0a@nsnintra.net>; bh=6YRozg9K9tnBZj8z2AunllsK2I7qCwsLyWMQkDYmuCE=; b=G727uQIeWeYhlT3IdWRul94pNJC7uThGBX3MRVFEeBuykcL61F6Hgzee LfRe1v4wtnETayIIpI8HpyJ0xDzdyjJCgoQjnKHHyvN1pwcP5GNkZ7FeE 3udx1GYr3QhlQOmiia6FWpVc0+zOlidg5bmZQTA3RHKaeJLVaW/4VHjjV E=; Authentication-Results: sj-iport-5.cisco.com; dkim=pass (signature verified [TEST]) header.i=jmpolk@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAM8PykqrR7MV/2dsb2JhbACIGbMsiGEBjj0GhCo X-IronPort-AV: E=Sophos;i="4.44,508,1249257600"; d="scan'208";a="97531505" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 05 Oct 2009 22:26:04 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n95MQ5ma005560; Mon, 5 Oct 2009 15:26:05 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n95MQ5Vh022773; Mon, 5 Oct 2009 22:26:05 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Oct 2009 15:26:05 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.0.14]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Oct 2009 15:26:04 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 05 Oct 2009 17:26:03 -0500 To: "Hannes Tschofenig" , From: "James M. Polk" In-Reply-To: <035601ca4339$5da67f70$8501fe0a@nsnintra.net> References: <035601ca4339$5da67f70$8501fe0a@nsnintra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 05 Oct 2009 22:26:04.0748 (UTC) FILETIME=[D39E88C0:01CA460A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=924; t=1254781565; x=1255645565; c=relaxed/simple; s=sjdkim1004; 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]=20Status=20of=20the=20ongoing=2 0document=20editing=20work |Sender:=20; bh=6YRozg9K9tnBZj8z2AunllsK2I7qCwsLyWMQkDYmuCE=; b=Ph61gSFGu15rkn9dsGbgcNlVFBQD1oTTlTxq6BOPpNm3I2ddgUt/elrX+O DsMj52Xxl8pbNwcecxG+6Fe6loVQEqpSRTnbscKBYvKKPWtfsIvnR6Ad9new wKqZ+a4UxvLBPLrBKgTGPBiJxHcBjvnYE7lnmrDnXXszH/VMsrE24=; Subject: Re: [Ecrit] Status of the ongoing document editing work 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: , X-List-Received-Date: Mon, 05 Oct 2009 22:24:43 -0000 At 03:21 AM 10/2/2009, Hannes Tschofenig wrote: >Hi all, > >based on the chat with various document authors I will try to summarize the >open issues with the current documents: > >* "IANA Registering a SIP RPH Namespace for Local Emergency Communications" > >As mentioned in my other mail (see >http://www.ietf.org/mail-archive/web/ecrit/current/msg06710.html) Marc is >going to discuss a few issues on the list. > >I believe that James said that he does not see any open issues with the >document at the moment. minor correction - Keith sent me a small list of nits and edits to make. None are substantial, or change the text very much - however they make the doc better. I just need to incorporate them. James >Anything I forgot? > >Ciao >Hannes > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From jmpolk@cisco.com Tue Oct 6 19:45:30 2009 Return-Path: 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 EED4E28C244 for ; Tue, 6 Oct 2009 19:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.504 X-Spam-Level: X-Spam-Status: No, score=-6.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 3xiiohauq-Nr for ; Tue, 6 Oct 2009 19:45:30 -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 E568B28C1E5 for ; Tue, 6 Oct 2009 19:45:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=673; q=dns/txt; s=sjiport06001; t=1254883629; x=1256093229; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"James=20M.=20Polk"=20 |Subject:=20Transformations=20ID=20(was=20only=20for=20ge ocoding)|Date:=20Tue,=2006=20Oct=202009=2021:47:08=20-050 0|Message-ID:=20|To:=20"'ECRIT'"=20 |Mime-Version:=201.0; bh=lyZbJ+rs7ccVB4g7xAcrWd1O3Z9vegbg0PV4M0bB1kM=; b=BdIQmGeUWSj9XfuffFdSGHW8kR1Rsn/+p/ptZT+dwOpJMhVusXUnTcRG hixmWVk6H+AQetctsY7uJAgnd/fF+ROXABJ76f9UGcs32lYTvcNP8pMmT noNnBLbHUJ8oJ6M+KOnh9okPfJZVcMNCVmVZ3Gxk/OAjVsdqRPbhMBQW6 8=; Authentication-Results: sj-iport-6.cisco.com; dkim=pass (signature verified [TEST]) header.i=jmpolk@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFAMedy0qrR7PD/2dsb2JhbACIGbRqiGMBjz0GhCo X-IronPort-AV: E=Sophos;i="4.44,516,1249257600"; d="scan'208";a="403440157" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 07 Oct 2009 02:47:08 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n972l8UC023019 for ; Tue, 6 Oct 2009 19:47:08 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n972l8cQ012881 for ; Wed, 7 Oct 2009 02:47:08 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Oct 2009 19:47:08 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.12.110]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Oct 2009 19:47:07 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 06 Oct 2009 21:47:08 -0500 To: "'ECRIT'" From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 07 Oct 2009 02:47:08.0026 (UTC) FILETIME=[7612D5A0:01CA46F8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=673; t=1254883628; x=1255747628; c=relaxed/simple; s=sjdkim3002; 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:=20Transformations=20ID=20(was=20only=20for=20geoc oding) |Sender:=20; bh=lyZbJ+rs7ccVB4g7xAcrWd1O3Z9vegbg0PV4M0bB1kM=; b=nExlP/TwVRjdbSJC1Z8lnukNEyBl/kv4EuMU80hGYDCdocon3FHASVEh0d e/Rcn6tyIQRjbnOJpQWFxSNCanAT+SajQk0gILFsXJco3sGn6MyOm3jkpdmY dO8rZnPwEV; Subject: [Ecrit] Transformations ID (was only for geocoding) 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: , X-List-Received-Date: Wed, 07 Oct 2009 02:45:31 -0000 Hey In Stockholm during my preso on the ID draft-polk-ecrit-lost-geocoding, there was a suggestion by Brian to move geocoding/reverse-geocoding down a level and have a new top level URN for "transformations". There were examples given during the meeting that I'm having a hard time remembering (other than geocoding/reverse-geocoding). Can anyone remember these, or can anyone come up with examples of transformations between similar values, but in different formats (which is how I am scoping this transformations URN)? Or, does anyone have a different scope of transformations that I should consider? Any help would be appreciated! James From root@core3.amsl.com Wed Oct 7 02:30:01 2009 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C2BDC28C0DB; Wed, 7 Oct 2009 02:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091007093001.C2BDC28C0DB@core3.amsl.com> Date: Wed, 7 Oct 2009 02:30:01 -0700 (PDT) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-lost-servicelistboundary-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: , X-List-Received-Date: Wed, 07 Oct 2009 09:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Location-to-Service Translation Protocol (LoST) Extension: ServiceListBoundary Author(s) : K. Wolf Filename : draft-ietf-ecrit-lost-servicelistboundary-00.txt Pages : 9 Date : 2009-10-07 LoST maps service identifiers and location information to service contact URIs. If a LoST client wants to discover available services for a particular location, it will perform a query to the LoST server. However, the response from the LoST server does not provide information about the geographical region for which the returned service list is valid. Therefore, this document proposes a ServiceListBoundary to assist the client to not miss a change in available services when moving. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-servicelistboundary-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 Content-Type: Message/External-body; name="draft-ietf-ecrit-lost-servicelistboundary-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-07022607.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Wed Oct 7 04:30:02 2009 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D2F4028C1CE; Wed, 7 Oct 2009 04:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091007113001.D2F4028C1CE@core3.amsl.com> Date: Wed, 7 Oct 2009 04:30:01 -0700 (PDT) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-rough-loc-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: , X-List-Received-Date: Wed, 07 Oct 2009 11:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Using Imprecise Location for Emergency Context Resolution Author(s) : R. Barnes, M. Lepinski Filename : draft-ietf-ecrit-rough-loc-00.txt Pages : 14 Date : 2009-10-07 Emergency calling works best when precise location is available for emergency call routing. However, there are situations in which a location provider is unable or unwilling to provide precise location, yet still wishes to enable subscribers to make emergency calls. This document describes the level of location accuracy that providers must provide to enable emergency call routing. In addition, we descibe how emergency services and non-emergency services can be invoked by an endpoint that does not have access to its precise location. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-rough-loc-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 Content-Type: Message/External-body; name="draft-ietf-ecrit-rough-loc-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-07041706.I-D@ietf.org> --NextPart-- From rbarnes@bbn.com Wed Oct 7 04:35:36 2009 Return-Path: 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 0EE4F28C27A for ; Wed, 7 Oct 2009 04:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[AWL=-0.702, BAYES_00=-2.599, MISSING_HEADERS=1.292] 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 rAn97X2POZJY for ; Wed, 7 Oct 2009 04:35:35 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 5474C28C21F for ; Wed, 7 Oct 2009 04:35:35 -0700 (PDT) Received: from [128.89.254.18] (helo=col-rbarnes-l1.local) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1MvUpV-0003VE-CY for ecrit@ietf.org; Wed, 07 Oct 2009 07:37:14 -0400 Message-ID: <4ACC7D69.5040004@bbn.com> Date: Wed, 07 Oct 2009 12:37:13 +0100 From: Richard Barnes User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 CC: ecrit@ietf.org References: <20091007113001.D2F4028C1CE@core3.amsl.com> In-Reply-To: <20091007113001.D2F4028C1CE@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-rough-loc-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: , X-List-Received-Date: Wed, 07 Oct 2009 11:35:36 -0000 Pursuant to a request from the chairs, I have submitted this draft as a WG draft. There are no changes from the last individual version. --Richard Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. > > > Title : Using Imprecise Location for Emergency Context Resolution > Author(s) : R. Barnes, M. Lepinski > Filename : draft-ietf-ecrit-rough-loc-00.txt > Pages : 14 > Date : 2009-10-07 > > Emergency calling works best when precise location is available for > emergency call routing. However, there are situations in which a > location provider is unable or unwilling to provide precise location, > yet still wishes to enable subscribers to make emergency calls. This > document describes the level of location accuracy that providers must > provide to enable emergency call routing. In addition, we descibe > how emergency services and non-emergency services can be invoked by > an endpoint that does not have access to its precise location. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-rough-loc-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 MILANPA@nortel.com Wed Oct 7 10:45:28 2009 Return-Path: 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 332BA28C121 for ; Wed, 7 Oct 2009 10:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 ErnksepavcMO for ; Wed, 7 Oct 2009 10:45:27 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 072653A6872 for ; Wed, 7 Oct 2009 10:45:26 -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 n97Hl0t25221; Wed, 7 Oct 2009 17:47:00 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Oct 2009 18:46:57 +0100 Message-ID: <0913B6CD18F370498CD65864CF254E900AF88919@zharhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-patel-ecrit-sos-parameter-06 Thread-Index: AcpHdiqIy6feprN/QpeHeq7szoFzbg== From: "Milan Patel" To: "ecrit" , "Cullen Jennings" , "Hannes Tschofenig" Subject: [Ecrit] draft-patel-ecrit-sos-parameter-06 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: , X-List-Received-Date: Wed, 07 Oct 2009 17:45:28 -0000 Hi folks, I have emailed Cullen about "draft-patel-ecrit-sos-parameter-06" which is AD sponsored to remind him about publication request etc so we can progress this draft. As far as I'm concerned, the PROTO write-up has been provided and updated as per the tracker comments, and the draft has been expert reviewed by Gonzalo Camarillo with updates made as per his comments. =20 I've not received any further comments from the working group, so I believe the draft should be progressed towards last call/IESG review.=20 Best regards, Milan From mlinsner@cisco.com Fri Oct 9 07:26:22 2009 Return-Path: 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 4089628C11E for ; Fri, 9 Oct 2009 07:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.504 X-Spam-Level: X-Spam-Status: No, score=-5.504 tagged_above=-999 required=5 tests=[AWL=-0.302, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 XiEXorRjuiBS for ; Fri, 9 Oct 2009 07:26:21 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 1B7D83A6A3A for ; Fri, 9 Oct 2009 07:26:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mlinsner@cisco.com; l=1624; q=dns/txt; s=sjiport02001; t=1255098486; x=1256308086; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Marc=20Linsner=20|Subject: =20Hiroshima=20Meeting|Date:=20Fri,=2009=20Oct=202009=201 0:28:01=20-0400|Message-ID:=20|To:=20"'ecrit'"=20|Mime-version: =201.0; bh=TdHgnfeyc+C/xI2xWzRT98BnV8M72ud+oF/aQO1PNJs=; b=qdOOC0UcB7DmGcEsNFcNivSYCt0u7lt5V3MVIPsDmb9s1A1r0HKgJM0J HlJpz1PNU75HObPdpk3jG7EAIf2vBaZWW7W6pnOa3YzYNgOyr6x1PZip6 PZXa+bpB9R3kYYF8nLoMeq4boIU8M0KhptFbzp9ieSXnYI/J0WTqEgEd8 E=; Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0FANPlzkqrR7H+/2dsb2JhbACCJDGXC6kNmESEKgQ X-IronPort-AV: E=Sophos;i="4.44,532,1249257600"; d="scan'208,217";a="213009014" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 09 Oct 2009 14:28:05 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n99ES15V023021 for ; Fri, 9 Oct 2009 14:28:05 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 10:28:04 -0400 Received: from [10.116.195.126] ([10.116.195.126]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 10:28:03 -0400 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Fri, 09 Oct 2009 10:28:01 -0400 From: Marc Linsner To: "'ecrit'" Message-ID: Thread-Topic: Hiroshima Meeting Thread-Index: AcpI7LRsssEbB4IhfUa3fG5eXyC5VA== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3337928883_464886" X-OriginalArrivalTime: 09 Oct 2009 14:28:03.0745 (UTC) FILETIME=[B60FC910:01CA48EC] Subject: [Ecrit] Hiroshima Meeting 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: , X-List-Received-Date: Fri, 09 Oct 2009 14:26:22 -0000 > 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_3337928883_464886 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit All, We are attempting to put together the agenda for the upcoming meeting in Hiroshima and have realized that the principles of our current documents are not going to attend the Hiroshima meeting. This is causing us to adjust the agenda accordingly. So, if you are planning to submit a 00 draft by the October 19 deadline that you wish to discuss at the microphone in Hiroshima, please let us know quickly as we have to make decisions about the agenda. Thanks, -Marc & Hannes- --B_3337928883_464886 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Hiroshima Meeting All,

We are attempting to put together the agenda for the upcoming meeting in Hi= roshima and have realized that the principles of our current documents are n= ot going to attend the Hiroshima meeting.  This is causing us to adjust= the agenda accordingly.

So, if you are planning to submit a 00 draft by the October 19 deadline tha= t you wish to discuss at the microphone in Hiroshima, please let us know qui= ckly as we have to make decisions about the agenda.

Thanks,

-Marc & Hannes- --B_3337928883_464886-- From James.Winterbottom@andrew.com Sat Oct 17 01:34:02 2009 Return-Path: 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 544E43A6874 for ; Sat, 17 Oct 2009 01:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.397 X-Spam-Level: * X-Spam-Status: No, score=1.397 tagged_above=-999 required=5 tests=[BAYES_50=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 ntO41yn2zOWB for ; Sat, 17 Oct 2009 01:34:02 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 17E173A6856 for ; Sat, 17 Oct 2009 01:34:02 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_10_17_03_58_12 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); Sat, 17 Oct 2009 03:58:12 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 17 Oct 2009 03:34:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 17 Oct 2009 03:34:05 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: November Emergency Services Workshop in Kuala Lumpur Malaysia thread-index: AcpPBJab1WrT98lqTraZlgQb4P779Q== From: "Winterbottom, James" To: X-OriginalArrivalTime: 17 Oct 2009 08:34:06.0751 (UTC) FILETIME=[9721AAF0:01CA4F04] Subject: [Ecrit] November Emergency Services Workshop in Kuala Lumpur Malaysia 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: , X-List-Received-Date: Sat, 17 Oct 2009 08:34:02 -0000 =0D=0AHi All,=0D=0A=0D=0AThis is just a reminder that the next emergency se= rvices workshop will be held in Kuala Lumpur Malaysia on the 4th and 5th of= November 2009.=0D=0AIf you plan to attend this meeting could you please re= gister through the following link:=0D=0A=0D=0Ahttp://www.emergency-services= -coordination.info/esw6.html=0D=0A=0D=0ACheers=0D=0AJames=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, please notify the sender=0D=0Aimmediat= ely and delete the original. Any unauthorized use of=0D=0Athis email is pr= ohibited.=0D=0A------------------------------------------------------------= ------------------------------------=0D=0A[mf2]=0D=0A From Hannes.Tschofenig@gmx.net Tue Oct 20 14:33:45 2009 Return-Path: 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 CA1043A6954 for ; Tue, 20 Oct 2009 14:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.879 X-Spam-Level: X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_05=-1.11] 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 E6BBo1plfO7M for ; Tue, 20 Oct 2009 14:33:45 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 678FB3A6951 for ; Tue, 20 Oct 2009 14:33:43 -0700 (PDT) Received: (qmail invoked by alias); 20 Oct 2009 21:33:51 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO 4FIL42860) [88.115.222.204] by mail.gmx.net (mp071) with SMTP; 20 Oct 2009 23:33:51 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX185FFtP6g45GK7LqcLGpQJnzjrCCg7XcIM8UpjbWw 1noT2cHpRjbmM+ From: "Hannes Tschofenig" To: Date: Wed, 21 Oct 2009 00:37:02 +0300 Message-ID: <058201ca51cd$767b0640$03ffa8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 thread-index: AcpRzXXigKN4Qkk8Qz2azGYK0LBxmQ== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.71 Subject: [Ecrit] LoST Sync -08 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: , X-List-Received-Date: Tue, 20 Oct 2009 21:33:45 -0000 Hi all, A little while ago we had a discussion about the LoST sync document and I now provided the update and added a more descriptive example. Please find the latest version here: http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost-sync/draft-ietf-ecri t-lost-sync-08.txt Let me know if the update addresses the raised comments. Ciao Hannes PS: I believe the discussion started with this comment: http://www.ietf.org/mail-archive/web/ecrit/current/msg06634.html From khwolf1@gmail.com Thu Oct 22 05:16:52 2009 Return-Path: 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 B57083A6875 for ; Thu, 22 Oct 2009 05:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 56pJtpL4y5iP for ; Thu, 22 Oct 2009 05:16:51 -0700 (PDT) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id AE03F3A6874 for ; Thu, 22 Oct 2009 05:16:51 -0700 (PDT) Received: by pwi4 with SMTP id 4so1478973pwi.29 for ; Thu, 22 Oct 2009 05:16:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=IEtG11hrQ85pWKvGxy5YL6LtEm/NyhttFgBldI6BuQg=; b=gWXXSo3bt1w+lHxIw24Y3/KAEuVq4VO3SC/b9WD6f4OBLvsv/5QRBhr3/EhoQlu7bA SdkSoN+zDrrl/LNSrGRQELJw/T7vLlD2+TisTWV719qh2lE2oN7cIYAXmQJXuKmO4ZEw NjBmQ1wXVEgGFzAz/Upp+RdvItCSDlWczzzTQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=TwAN3fHbDmwMtOMgcSLetMuU0tzElddMz/7XHVWGpFnoLvpY0ZX3zgVH9kbVOCmTWG d3xdW8l6EtEv53h2fteHvKu/xLZkMs0te6hUCaQbvgwrp8B3XCK1lUV5J5ztV+2O+30p 2hJPyOCIBydX5ceVo84Ve9JXXDioZIhupSemw= MIME-Version: 1.0 Received: by 10.141.2.5 with SMTP id e5mr1792292rvi.230.1256213817999; Thu, 22 Oct 2009 05:16:57 -0700 (PDT) In-Reply-To: <058201ca51cd$767b0640$03ffa8c0@nsnintra.net> References: <058201ca51cd$767b0640$03ffa8c0@nsnintra.net> Date: Thu, 22 Oct 2009 14:16:57 +0200 Message-ID: From: Karl Heinz Wolf To: Hannes Tschofenig Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org Subject: Re: [Ecrit] LoST Sync -08 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: , X-List-Received-Date: Thu, 22 Oct 2009 12:16:52 -0000 Hannes, I looked at the diff and have some comments. First I think it is good to have an example with a figure to better understand how it works. However, shouldn't Figure 1 be labeled with LoST sync for every arrow? Figure 3: shouldn=92t the FG exchange mappings pointing to LoST servers only and not mappings pointing directly to PSAPs? karl heinz On Tue, Oct 20, 2009 at 11:37 PM, Hannes Tschofenig wrote: > Hi all, > > A little while ago we had a discussion about the LoST sync document and I > now provided the update and added a more descriptive example. Please find > the latest version here: > http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost-sync/draft-ietf-e= cri > t-lost-sync-08.txt > > Let me know if the update addresses the raised comments. > > Ciao > Hannes > > PS: I believe the discussion started with this comment: > http://www.ietf.org/mail-archive/web/ecrit/current/msg06634.html > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From Hannes.Tschofenig@gmx.net Thu Oct 22 11:18:03 2009 Return-Path: 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 285103A69CD for ; Thu, 22 Oct 2009 11:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=0.899, 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 gkYsMJb8Jyp5 for ; Thu, 22 Oct 2009 11:18:02 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 812CD3A679F for ; Thu, 22 Oct 2009 11:18:01 -0700 (PDT) Received: (qmail invoked by alias); 22 Oct 2009 18:18:08 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO 4FIL42860) [88.115.222.204] by mail.gmx.net (mp007) with SMTP; 22 Oct 2009 20:18:08 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18XfXxjPxsXmRh5e/lXSzM0/dp/+l8nsdyla4puQ8 ZvwvYQOe9SbGRs From: "Hannes Tschofenig" To: "'Karl Heinz Wolf'" References: <058201ca51cd$767b0640$03ffa8c0@nsnintra.net> Date: Thu, 22 Oct 2009 21:21:20 +0300 Message-ID: <026201ca5344$74c32cb0$03ffa8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: Thread-Index: AcpTEY0VoZfWQujMQFiqQs4boBCQ9QAMVaTg X-Y-GMX-Trusted: 0 X-FuHaFi: 0.61 Cc: ecrit@ietf.org Subject: Re: [Ecrit] LoST Sync -08 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: , X-List-Received-Date: Thu, 22 Oct 2009 18:18:03 -0000 Hi Karl Heinz, Thanks for your quick feedback. >Hannes, > >I looked at the diff and have some comments. First I think it >is good to have an example with a figure to better understand >how it works. Thought so too. >However, shouldn't Figure 1 be labeled with LoST sync for every arrow? One could use LoST sync also in other places but in my example the synchronization only happens between the FGs. I thought it would confuse if I indicate LoST Sync also between the Austrian FG and the 3 LoST servers. The reader could easily get the impression that the boundaries stored at these three servers are then further distributed to the FG Finland. Although one could do that this is not really the idea of the FG. >Figure 3: shouldn't the FG exchange mappings pointing to LoST >servers only and not mappings pointing directly to PSAPs? The FG exchanges whatever it is configured to exchange. In the Finland example there is no other LoST server and hence it only exchanges what it has. Does this make sense? Ciao Hannes > >karl heinz > >On Tue, Oct 20, 2009 at 11:37 PM, Hannes Tschofenig > wrote: >> Hi all, >> >> A little while ago we had a discussion about the LoST sync document >> and I now provided the update and added a more descriptive example. >> Please find the latest version here: >> >http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost-sync/draft-iet >> f-ecri >> t-lost-sync-08.txt >> >> Let me know if the update addresses the raised comments. >> >> Ciao >> Hannes >> >> PS: I believe the discussion started with this comment: >> http://www.ietf.org/mail-archive/web/ecrit/current/msg06634.html >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > From khwolf1@gmail.com Thu Oct 22 11:49:16 2009 Return-Path: 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 327613A69D0 for ; Thu, 22 Oct 2009 11:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 bUKiDrEMU2vD for ; Thu, 22 Oct 2009 11:49:14 -0700 (PDT) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id CD6BC3A659B for ; Thu, 22 Oct 2009 11:49:14 -0700 (PDT) Received: by pwi4 with SMTP id 4so1696971pwi.29 for ; Thu, 22 Oct 2009 11:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=jpsLqwDnicsUOjthjoBuGW+s5ewPJtyrafZBqKyQIKM=; b=ZozNynYzYJS/ur9H0IScDcQxzNQQDj/wNkUi5b/rNuVzC8GTXF6XFt/pgNIpWSXjT3 BMLdkPIL7tf3VuN6UiEpg1MNCsm3UPlCVNSE62cTFgyWLFdCKUQDCWRd9f90pdUfr1AQ hgoLS7/3ScaPq2QtlgU9NsCpKpiXbqXYjnAjM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uIK/jIVY8EFz1a9a9yJ0vEjx1D+C2cF9oztnqjb4MLeG8C7zaNsQ0RXZWg9ml6halu c/sk7H4kiYLFvK+FZdyr7LTJSZyDpAYQzGzhvzjN2fZK3Bgnfxr5IXpPfJZWxTs/n14s TXtRTAA5jq2MPjQf47E8Xd1LjnDfkSMJupHH4= MIME-Version: 1.0 Received: by 10.140.143.9 with SMTP id q9mr1772647rvd.240.1256237357785; Thu, 22 Oct 2009 11:49:17 -0700 (PDT) In-Reply-To: <026201ca5344$74c32cb0$03ffa8c0@nsnintra.net> References: <058201ca51cd$767b0640$03ffa8c0@nsnintra.net> <026201ca5344$74c32cb0$03ffa8c0@nsnintra.net> Date: Thu, 22 Oct 2009 20:49:17 +0200 Message-ID: From: Karl Heinz Wolf To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Cc: ecrit@ietf.org Subject: Re: [Ecrit] LoST Sync -08 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: , X-List-Received-Date: Thu, 22 Oct 2009 18:49:16 -0000 >> >>I looked at the diff and have some comments. First I think it >>is good to have an example with a figure to better understand >>how it works. > > Thought so too. > >>However, shouldn't Figure 1 be labeled with LoST sync for every arrow? > > One could use LoST sync also in other places but in my example the > synchronization only happens between the FGs. > > I thought it would confuse if I indicate LoST Sync also between the Austrian > FG and the 3 LoST servers. The reader could easily get the impression that > the boundaries stored at these three servers are then further distributed to > the FG Finland. Although one could do that this is not really the idea of > the FG. ok, I see, so you wanted to prohibit that someone thinks that the mapping data will be syncronized all the way to the Finish FG? I have a suggestion for a different (maybe additional?) example: why not show the usage of LoST-sync between two LoST servers in the same cluster synchronizing complete mappings and one LoST server pushing up it's coverage reagion. Perhaps this makes it clearer, what do you think? >>Figure 3: shouldn't the FG exchange mappings pointing to LoST >>servers only and not mappings pointing directly to PSAPs? > > The FG exchanges whatever it is configured to exchange. In the Finland > example there is no other LoST server and hence it only exchanges what it > has. > > Does this make sense? I just looked at RFC 5582: "Forest guides do not provide mapping information themselves, but rather redirect to mapping servers." I would argue that having the URI of the PSAP is a mapping information, and therefore not intented to be contained in the FG. As you write in your draft, Finland has one server acting as forest guide and mapping server, I would say when acting as a FG it would have to distribute something pointing to itself when doing a lost-sync with another FG. Does this make sense? karl heinz > Ciao > Hannes > >> >>karl heinz >> >>On Tue, Oct 20, 2009 at 11:37 PM, Hannes Tschofenig >> wrote: >>> Hi all, >>> >>> A little while ago we had a discussion about the LoST sync document >>> and I now provided the update and added a more descriptive example. >>> Please find the latest version here: >>> >>http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost-sync/draft-iet >>> f-ecri >>> t-lost-sync-08.txt >>> >>> Let me know if the update addresses the raised comments. >>> >>> Ciao >>> Hannes >>> >>> PS: I believe the discussion started with this comment: >>> http://www.ietf.org/mail-archive/web/ecrit/current/msg06634.html >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> >> > > From Hannes.Tschofenig@gmx.net Fri Oct 23 01:09:53 2009 Return-Path: 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 6A6E63A68A4 for ; Fri, 23 Oct 2009 01:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[AWL=0.674, 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 eacWsnEiLE82 for ; Fri, 23 Oct 2009 01:09:52 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 8B6163A6817 for ; Fri, 23 Oct 2009 01:09:51 -0700 (PDT) Received: (qmail invoked by alias); 23 Oct 2009 08:10:00 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO 4FIL42860) [88.115.222.204] by mail.gmx.net (mp015) with SMTP; 23 Oct 2009 10:10:00 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/noxZclxTnWz34fIlCYMZRd0kzL6rbyuJux3Xycg 5vSFRnyj3lvItW From: "Hannes Tschofenig" To: "'Karl Heinz Wolf'" References: <058201ca51cd$767b0640$03ffa8c0@nsnintra.net> <026201ca5344$74c32cb0$03ffa8c0@nsnintra.net> Date: Fri, 23 Oct 2009 11:13:13 +0300 Message-ID: <027f01ca53b8$aaccd940$03ffa8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: Thread-Index: AcpTSFyc3xOsX3lxQWaW/8bzgKLf5QAbJhEw X-Y-GMX-Trusted: 0 X-FuHaFi: 0.55 Cc: ecrit@ietf.org Subject: Re: [Ecrit] LoST Sync -08 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: , X-List-Received-Date: Fri, 23 Oct 2009 08:09:53 -0000 Hi Karl Heinz, >>>I looked at the diff and have some comments. First I think >it is good >>>to have an example with a figure to better understand how it works. >> >> Thought so too. >> >>>However, shouldn't Figure 1 be labeled with LoST sync for >every arrow? >> >> One could use LoST sync also in other places but in my example the >> synchronization only happens between the FGs. >> >> I thought it would confuse if I indicate LoST Sync also between the >> Austrian FG and the 3 LoST servers. The reader could easily get the >> impression that the boundaries stored at these three servers >are then >> further distributed to the FG Finland. Although one could do >that this >> is not really the idea of the FG. >ok, I see, so you wanted to prohibit that someone thinks that >the mapping data will be syncronized all the way to the Finish FG? > >I have a suggestion for a different (maybe additional?) >example: why not show the usage of LoST-sync between two LoST >servers in the same cluster synchronizing complete mappings >and one LoST server pushing up it's coverage reagion. Perhaps >this makes it clearer, what do you think? > I am OK with additionally describing how the LoST servers push their mappings up to the FG. >>>Figure 3: shouldn't the FG exchange mappings pointing to >LoST servers >>>only and not mappings pointing directly to PSAPs? >> >> The FG exchanges whatever it is configured to exchange. In >the Finland >> example there is no other LoST server and hence it only >exchanges what >> it has. >> >> Does this make sense? > >I just looked at RFC 5582: "Forest guides do not provide >mapping information > themselves, but rather redirect to mapping servers." > >I would argue that having the URI of the PSAP is a mapping >information, and therefore not intented to be contained in the >FG. As you write in your draft, Finland has one server acting >as forest guide and mapping server, I would say when acting as >a FG it would have to distribute something pointing to itself >when doing a lost-sync with another FG. Does this make sense? It is true that the definition in RFC 5582 seems to suggest that. However, when you consider that the FG must have the mapping data of all its immediate children (in our case of the three LoST servers for the Austrian FG) then this definition already seems a bit outdated. When a LoST request gets sent to a FG it then has to look at the mappings it has to indicate to what other LoST server one has to talk to. One could, of course, configure the Finnish FG in a way that it matches the definition, namely by letting the mapping to point to a FG again (which co-locates the LoST server). This would be possible, no doubt, but it is worth the additional layer of indirection? I can still make the change. Ciao Hannes > >karl heinz > >> Ciao >> Hannes >> >>> >>>karl heinz >>> >>>On Tue, Oct 20, 2009 at 11:37 PM, Hannes Tschofenig >>> wrote: >>>> Hi all, >>>> >>>> A little while ago we had a discussion about the LoST sync >document >>>> and I now provided the update and added a more descriptive example. >>>> Please find the latest version here: >>>> >>>http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost-sync/ >draft-iet >>>> f-ecri >>>> t-lost-sync-08.txt >>>> >>>> Let me know if the update addresses the raised comments. >>>> >>>> Ciao >>>> Hannes >>>> >>>> PS: I believe the discussion started with this comment: >>>> http://www.ietf.org/mail-archive/web/ecrit/current/msg06634.html >>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>> >> >> > From Hannes.Tschofenig@gmx.net Fri Oct 23 02:41:32 2009 Return-Path: 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 6712A3A6869 for ; Fri, 23 Oct 2009 02:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.06 X-Spam-Level: X-Spam-Status: No, score=-2.06 tagged_above=-999 required=5 tests=[AWL=0.539, 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 TINoi5EtEcHN for ; Fri, 23 Oct 2009 02:41:30 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 853463A6767 for ; Fri, 23 Oct 2009 02:41:29 -0700 (PDT) Received: (qmail invoked by alias); 23 Oct 2009 09:41:38 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO 4FIL42860) [88.115.222.204] by mail.gmx.net (mp006) with SMTP; 23 Oct 2009 11:41:38 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19NQCcr2dtN6HhRV3CC1lDNT14x7RXWB0S4WxIiPm 7CFJ92CZITqZMy From: "Hannes Tschofenig" To: "'Hannes Tschofenig'" , "'Karl Heinz Wolf'" References: <058201ca51cd$767b0640$03ffa8c0@nsnintra.net><026201ca5344$74c32cb0$03ffa8c0@nsnintra.net> <027f01ca53b8$aaccd940$03ffa8c0@nsnintra.net> Date: Fri, 23 Oct 2009 12:44:50 +0300 Message-ID: <029801ca53c5$778e5600$03ffa8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <027f01ca53b8$aaccd940$03ffa8c0@nsnintra.net> Thread-Index: AcpTSFyc3xOsX3lxQWaW/8bzgKLf5QAbJhEwAAIZk+A= X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Cc: ecrit@ietf.org Subject: Re: [Ecrit] LoST Sync -08 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: , X-List-Received-Date: Fri, 23 Oct 2009 09:41:32 -0000 Btw, I noticed that there are even more ways to deploy it. For example, the Austrian FG could distribute a single mapping that says it is responsible for Austria only (instead of re-distributing the mappings provided from it's child LoST servers). In any case, here is the updated draft: http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost-sync/draft-ietf-ecri t-lost-sync-08.txt Let me know if you like it better now. Ciao Hannes >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of Hannes Tschofenig >Sent: 23 October, 2009 11:13 >To: 'Karl Heinz Wolf' >Cc: ecrit@ietf.org >Subject: Re: [Ecrit] LoST Sync -08 > >Hi Karl Heinz, > > >>>>I looked at the diff and have some comments. First I think >>it is good >>>>to have an example with a figure to better understand how it works. >>> >>> Thought so too. >>> >>>>However, shouldn't Figure 1 be labeled with LoST sync for >>every arrow? >>> >>> One could use LoST sync also in other places but in my example the >>> synchronization only happens between the FGs. >>> >>> I thought it would confuse if I indicate LoST Sync also between the >>> Austrian FG and the 3 LoST servers. The reader could easily get the >>> impression that the boundaries stored at these three servers >>are then >>> further distributed to the FG Finland. Although one could do >>that this >>> is not really the idea of the FG. >>ok, I see, so you wanted to prohibit that someone thinks that the >>mapping data will be syncronized all the way to the Finish FG? >> >>I have a suggestion for a different (maybe additional?) >>example: why not show the usage of LoST-sync between two LoST servers >>in the same cluster synchronizing complete mappings and one >LoST server >>pushing up it's coverage reagion. Perhaps this makes it clearer, what >>do you think? >> > >I am OK with additionally describing how the LoST servers push their >mappings up to the FG. > >>>>Figure 3: shouldn't the FG exchange mappings pointing to >>LoST servers >>>>only and not mappings pointing directly to PSAPs? >>> >>> The FG exchanges whatever it is configured to exchange. In >>the Finland >>> example there is no other LoST server and hence it only >>exchanges what >>> it has. >>> >>> Does this make sense? >> >>I just looked at RFC 5582: "Forest guides do not provide >>mapping information >> themselves, but rather redirect to mapping servers." >> >>I would argue that having the URI of the PSAP is a mapping >>information, and therefore not intented to be contained in the >>FG. As you write in your draft, Finland has one server acting >>as forest guide and mapping server, I would say when acting as >>a FG it would have to distribute something pointing to itself >>when doing a lost-sync with another FG. Does this make sense? > > >It is true that the definition in RFC 5582 seems to suggest that. >However, when you consider that the FG must have the mapping >data of all its >immediate children (in our case of the three LoST servers for >the Austrian >FG) then this definition already seems a bit outdated. When a >LoST request >gets sent to a FG it then has to look at the mappings it has >to indicate to >what other LoST server one has to talk to. > >One could, of course, configure the Finnish FG in a way that >it matches the >definition, namely by letting the mapping to point to a FG again (which >co-locates the LoST server). > >This would be possible, no doubt, but it is worth the >additional layer of >indirection? I can still make the change. > >Ciao >Hannes > >> >>karl heinz >> >>> Ciao >>> Hannes >>> >>>> >>>>karl heinz >>>> >>>>On Tue, Oct 20, 2009 at 11:37 PM, Hannes Tschofenig >>>> wrote: >>>>> Hi all, >>>>> >>>>> A little while ago we had a discussion about the LoST sync >>document >>>>> and I now provided the update and added a more >descriptive example. >>>>> Please find the latest version here: >>>>> >>>>http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost-sync/ >>draft-iet >>>>> f-ecri >>>>> t-lost-sync-08.txt >>>>> >>>>> Let me know if the update addresses the raised comments. >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> PS: I believe the discussion started with this comment: >>>>> http://www.ietf.org/mail-archive/web/ecrit/current/msg06634.html >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 Hannes.Tschofenig@gmx.net Fri Oct 23 07:24:32 2009 Return-Path: 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 551273A67E1 for ; Fri, 23 Oct 2009 07:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.943 X-Spam-Level: X-Spam-Status: No, score=-0.943 tagged_above=-999 required=5 tests=[AWL=-0.758, BAYES_40=-0.185] 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 tDnN3giqETIQ for ; Fri, 23 Oct 2009 07:24:31 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 2205B3A67D9 for ; Fri, 23 Oct 2009 07:24:30 -0700 (PDT) Received: (qmail invoked by alias); 23 Oct 2009 14:24:35 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO 4FIL42860) [88.115.222.204] by mail.gmx.net (mp017) with SMTP; 23 Oct 2009 16:24:35 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+9SpwqHju9+gyaFE7F+Ae6aWOf+dedc0i2Y1wmqW ZlvZvo3pz3iAVy From: "Hannes Tschofenig" To: Date: Fri, 23 Oct 2009 17:27:46 +0300 Message-ID: <04c501ca53ed$01030490$03ffa8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcpT6xrEyw1oycZlS32UxbvbCvFlkQ== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.78 Subject: [Ecrit] Regulatory Requirments for Callback 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: , X-List-Received-Date: Fri, 23 Oct 2009 14:24:32 -0000 Hi all, I am looking for some references to regulatory requirements for PSAP callbacks. I would like to see what is required from a regulatory point of view as input for the PSAP callback document. So, if someone has some documents please let me know. Ciao Hannes From br@brianrosen.net Fri Oct 23 07:34:56 2009 Return-Path: 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 A9C443A67E1 for ; Fri, 23 Oct 2009 07:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[AWL=-0.348, BAYES_20=-0.74] 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 DCF2i-GBrMHX for ; Fri, 23 Oct 2009 07:34:56 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id E10A03A67D9 for ; Fri, 23 Oct 2009 07:34:55 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.216]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1N1LEI-0005pm-P9; Fri, 23 Oct 2009 09:34:59 -0500 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Fri, 23 Oct 2009 10:34:58 -0400 From: Brian Rosen To: Hannes Tschofenig , Message-ID: Thread-Topic: [Ecrit] Regulatory Requirments for Callback Thread-Index: AcpT6xrEyw1oycZlS32UxbvbCvFlkQAAuP9Q In-Reply-To: <04c501ca53ed$01030490$03ffa8c0@nsnintra.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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] Regulatory Requirments for Callback 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: , X-List-Received-Date: Fri, 23 Oct 2009 14:34:56 -0000 There is an interesting one in the U.S. There are services for the deaf and hard of hearing called "Video Relay Service" and "IP Relay Service". The former uses videophones to an interpreter who uses sign language to communicate with the deaf/HoH person and places (or recieves) voice calls with hearing persons. IP Relay uses a text device like a laptop or PDA with an IM client, and the interpreter interprets text to voice. Both VRS and IP Relay have been upgraded recently to give the deaf/HoH user a (10 digit, U.S. Number plan) telephone number. Calls to the number are answered by an interpreter who has access to a database that maps the TN to the URI of the video/text device. These services now have regulatory requirements to support emergency calling (9-1-1). One of the requirements is that calls to 9-1-1 get priority on the interpreter queue. The regulator ALSO requires that callbacks get priority. This is very hard to do, because it is very hard to identify which calls are callbacks from the PSAP. The providers currently use a heuristic that any calls to the caller who placed an emergency call get priority for some hours after the emergency call is placed. Brian On 10/23/09 10:27 AM, "Hannes Tschofenig" wrote: > Hi all, > > I am looking for some references to regulatory requirements for PSAP > callbacks. I would like to see what is required from a regulatory point of > view as input for the PSAP callback document. > > So, if someone has some documents please let me know. > > Ciao > Hannes > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From James.Winterbottom@andrew.com Fri Oct 23 09:40:21 2009 Return-Path: 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 9FE8A3A6970 for ; Fri, 23 Oct 2009 09:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, 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 3bT5bPg6Fqeb for ; Fri, 23 Oct 2009 09:40:20 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 745413A6965 for ; Fri, 23 Oct 2009 09:40:20 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_10_23_12_04_43 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); Fri, 23 Oct 2009 12:04:43 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 11:40:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Oct 2009 11:38:48 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Regulatory Requirments for Callback Thread-Index: AcpT6xrEyw1oycZlS32UxbvbCvFlkQAFDDQe References: <04c501ca53ed$01030490$03ffa8c0@nsnintra.net> From: "Winterbottom, James" To: "Hannes Tschofenig" , X-OriginalArrivalTime: 23 Oct 2009 16:40:30.0542 (UTC) FILETIME=[888146E0:01CA53FF] Subject: Re: [Ecrit] Regulatory Requirments for Callback 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: , X-List-Received-Date: Fri, 23 Oct 2009 16:40:21 -0000 Hi Hannes,=0D=0A=0D=0AIt seems that for this to be useful you probably need= pointers to the various regulations and clauses. I will see what I can do = from an Australian perspective.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D= =0A-----Original Message-----=0D=0AFrom: ecrit-bounces@ietf.org on behalf o= f Hannes Tschofenig=0D=0ASent: Fri 10/23/2009 9:27 AM=0D=0ATo: ecrit@ietf.o= rg=0D=0ASubject: [Ecrit] Regulatory Requirments for Callback=0D=0A=20=0D=0A= Hi all,=20=0D=0A=0D=0AI am looking for some references to regulatory requir= ements for PSAP=0D=0Acallbacks. I would like to see what is required from a= regulatory point of=0D=0Aview as input for the PSAP callback document.=20=0D= =0A=0D=0ASo, if someone has some documents please let me know.=20=0D=0A=0D=0A= Ciao=0D=0AHannes=0D=0A=0D=0A=0D=0A_________________________________________= ______=0D=0AEcrit mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www.ietf.or= g/mailman/listinfo/ecrit=0D=0A=0D=0A=0D=0A---------------------------------= ---------------------------------------------------------------=0D=0AThis m= essage is for the designated recipient only and may=0D=0Acontain privileged= , proprietary, or otherwise private information. =20=0D=0AIf you have recei= ved it in error, please notify the sender=0D=0Aimmediately and delete the o= riginal. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A-----= ---------------------------------------------------------------------------= ----------------=0D=0A[mf2]=0D=0A From ted.ietf@gmail.com Fri Oct 23 09:55:15 2009 Return-Path: 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 6DB753A67BD for ; Fri, 23 Oct 2009 09:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 6DZvwMXo-oof for ; Fri, 23 Oct 2009 09:55:14 -0700 (PDT) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 86DD73A67AD for ; Fri, 23 Oct 2009 09:55:14 -0700 (PDT) Received: by pwi4 with SMTP id 4so2272920pwi.29 for ; Fri, 23 Oct 2009 09:55:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=N+6hoygJh/Inq/hz9ClQe040WwWUdelxxbgQkyJ/uIY=; b=H2UZ/XKhcbBAcfJFJXn8MS8dbCgJIiI2Wz52uC/7JWp9pJ216R8zyvpRakxDcAf/PE eaohYUSZOZkxbm8POBS+9DKlQOgEUdzPtJBWXIgwUxgFKbZZExOerJJctxOv3PycY34H kGyLl1kLj3NHRpZW5+EWgU+X7t0mG2O8WnWMk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=b4ejkWvu5STGdbCivfAc+1GVMUb+jEQAACG5Yw8Vn3kuc345vrb0NREF1LqNBKv1YC fDhgbjKkVYfyUn+61ETIY+ayepKR/YvZUYCArn+I8+By2bO9fLNeT6vgSEwnbeEAu0R9 1tTqNnQMdmVca+McxA1LL6Sq7AmBXHfeCYnms= MIME-Version: 1.0 Received: by 10.142.249.39 with SMTP id w39mr800053wfh.278.1256316922625; Fri, 23 Oct 2009 09:55:22 -0700 (PDT) In-Reply-To: References: <04c501ca53ed$01030490$03ffa8c0@nsnintra.net> Date: Fri, 23 Oct 2009 09:55:22 -0700 Message-ID: <6e04e83a0910230955n4d362d3fjf25e16fa7ff4ca56@mail.gmail.com> From: Ted Hardie To: Brian Rosen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org Subject: Re: [Ecrit] Regulatory Requirments for Callback 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: , X-List-Received-Date: Fri, 23 Oct 2009 16:55:15 -0000 > > The regulator ALSO requires that callbacks get priority. =A0This is very = hard > to do, because it is very hard to identify which calls are callbacks from > the PSAP. =A0The providers currently use a heuristic that any calls to th= e > caller who placed an emergency call get priority for some hours after the > emergency call is placed. This actually seems like a reasonable heuristic, given that callbacks from referred services may be at issue (e.g. a callback from a poison control specialist, rather than hospital). It has some false positives, but the risk of false negative seems low. As an aside, how long are the queue depths in the normal case? Does the wait for an interpreter to be available run in the seconds/minutes/tens of minutes/hours, on average? regards, Ted From Hannes.Tschofenig@gmx.net Fri Oct 23 11:18:26 2009 Return-Path: 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 654093A6963 for ; Fri, 23 Oct 2009 11:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.297 X-Spam-Level: X-Spam-Status: No, score=-1.297 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_05=-1.11] 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 fe-+kb2-W8eB for ; Fri, 23 Oct 2009 11:18:25 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 3CBDA3A6891 for ; Fri, 23 Oct 2009 11:18:25 -0700 (PDT) Received: (qmail invoked by alias); 23 Oct 2009 18:18:34 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO 4FIL42860) [88.115.222.204] by mail.gmx.net (mp025) with SMTP; 23 Oct 2009 20:18:34 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18k0ghMIeUkasyIoxbw6+7UAdNjR+Fr7nU5Hq+r+j ikndUM2LERsmUo From: "Hannes Tschofenig" To: "'Ted Hardie'" , "'Brian Rosen'" References: <04c501ca53ed$01030490$03ffa8c0@nsnintra.net> <6e04e83a0910230955n4d362d3fjf25e16fa7ff4ca56@mail.gmail.com> Date: Fri, 23 Oct 2009 21:21:45 +0300 Message-ID: <051e01ca540d$ae7a2930$03ffa8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <6e04e83a0910230955n4d362d3fjf25e16fa7ff4ca56@mail.gmail.com> Thread-Index: AcpUAZxzwYVpVKXOTLWcybWsk7YYwQAC+/7Q X-Y-GMX-Trusted: 0 X-FuHaFi: 0.82 Cc: ecrit@ietf.org Subject: Re: [Ecrit] Regulatory Requirments for Callback 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: , X-List-Received-Date: Fri, 23 Oct 2009 18:18:26 -0000 >> The regulator ALSO requires that callbacks get priority. Any reference to a document that would allow me to cite it in a document? From khwolf1@gmail.com Sun Oct 25 13:52:42 2009 Return-Path: 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 3E27528C179 for ; Sun, 25 Oct 2009 13:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 THcO305htjdS for ; Sun, 25 Oct 2009 13:52:41 -0700 (PDT) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 345ED28C173 for ; Sun, 25 Oct 2009 13:52:41 -0700 (PDT) Received: by pwi4 with SMTP id 4so3051040pwi.29 for ; Sun, 25 Oct 2009 13:52:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NtKLcYv4qI8Dd60btIJv63DEXcFod5UzX2BZpIf/kCo=; b=IG/4mfojYlcDkCHkMJJxQndXgwJjW8GRDpOQ8vlmsesyAcl6H2vLrg9uMKnKpssqrN VLHAoUgi+H5O8Rnz+XHhdO/zqZhdtz37DJxJw/EFRVyXtGXJkxCrybS0NTdFr06LQX+4 L8Zv3u1j8G3tQz4DB9RPWmlP2q6kiUAZbUH0k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Od2XWjYjQWKVy9hWMVykbz7Kb1V81Qyr/cVsaw6Pt/K8nL7Bq95rlCgUCXMrkdo91c c/Z2Ay8imRllBoqe4G2HK0wHhA22z/blQKOYrS3RYZA39Tsa4nkEictnRX8sPuZoAWXl aHzBXWclx62wRYF4zI8OMi5qfg7wnV2BEMCjQ= MIME-Version: 1.0 Received: by 10.140.164.1 with SMTP id m1mr1960728rve.134.1256503970738; Sun, 25 Oct 2009 13:52:50 -0700 (PDT) In-Reply-To: <029801ca53c5$778e5600$03ffa8c0@nsnintra.net> References: <058201ca51cd$767b0640$03ffa8c0@nsnintra.net> <026201ca5344$74c32cb0$03ffa8c0@nsnintra.net> <027f01ca53b8$aaccd940$03ffa8c0@nsnintra.net> <029801ca53c5$778e5600$03ffa8c0@nsnintra.net> Date: Sun, 25 Oct 2009 21:52:50 +0100 Message-ID: From: Karl Heinz Wolf To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org Subject: Re: [Ecrit] LoST Sync -08 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: , X-List-Received-Date: Sun, 25 Oct 2009 20:52:42 -0000 Since lost-sync references RFC5582, it should be in sync with this RFC I would suggest. On Fri, Oct 23, 2009 at 10:44 AM, Hannes Tschofenig wrote: > Btw, I noticed that there are even more ways to deploy it. For example, t= he > Austrian FG could distribute a single mapping that says it is responsible > for Austria only (instead of re-distributing the mappings provided from i= t's > child LoST servers). In this case it would be necessary to have a LoST server at the top of the Austrian tree the FG can refer to. This LoST server would direct requests to the West, East and Vienna servers, respectively. karl heinz > > In any case, here is the updated draft: > http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost-sync/draft-ietf-e= cri > t-lost-sync-08.txt > > Let me know if you like it better now. > > Ciao > Hannes > > >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>On Behalf Of Hannes Tschofenig >>Sent: 23 October, 2009 11:13 >>To: 'Karl Heinz Wolf' >>Cc: ecrit@ietf.org >>Subject: Re: [Ecrit] LoST Sync -08 >> >>Hi Karl Heinz, >> >> >>>>>I looked at the diff and have some comments. First I think >>>it is good >>>>>to have an example with a figure to better understand how it works. >>>> >>>> Thought so too. >>>> >>>>>However, shouldn't Figure 1 be labeled with LoST sync for >>>every arrow? >>>> >>>> One could use LoST sync also in other places but in my example the >>>> synchronization only happens between the FGs. >>>> >>>> I thought it would confuse if I indicate LoST Sync also between the >>>> Austrian FG and the 3 LoST servers. The reader could easily get the >>>> impression that the boundaries stored at these three servers >>>are then >>>> further distributed to the FG Finland. Although one could do >>>that this >>>> is not really the idea of the FG. >>>ok, I see, so you wanted to prohibit that someone thinks that the >>>mapping data will be syncronized all the way to the Finish FG? >>> >>>I have a suggestion for a different (maybe additional?) >>>example: why not show the usage of LoST-sync between two LoST servers >>>in the same cluster synchronizing complete mappings and one >>LoST server >>>pushing up it's coverage reagion. Perhaps this makes it clearer, what >>>do you think? >>> >> >>I am OK with additionally describing how the LoST servers push their >>mappings up to the FG. >> >>>>>Figure 3: shouldn't the FG exchange mappings pointing to >>>LoST servers >>>>>only and not mappings pointing directly to PSAPs? >>>> >>>> The FG exchanges whatever it is configured to exchange. In >>>the Finland >>>> example there is no other LoST server and hence it only >>>exchanges what >>>> it has. >>>> >>>> Does this make sense? >>> >>>I just looked at RFC 5582: "Forest guides do not provide >>>mapping information >>> =A0 themselves, but rather redirect to mapping servers." >>> >>>I would argue that having the URI of the PSAP is a mapping >>>information, and therefore not intented to be contained in the >>>FG. As you write in your draft, Finland has one server acting >>>as forest guide and mapping server, I would say when acting as >>>a FG it would have to distribute something pointing to itself >>>when doing a lost-sync with another FG. Does this make sense? >> >> >>It is true that the definition in RFC 5582 seems to suggest that. >>However, when you consider that the FG must have the mapping >>data of all its >>immediate children (in our case of the three LoST servers for >>the Austrian >>FG) then this definition already seems a bit outdated. When a >>LoST request >>gets sent to a FG it then has to look at the mappings it has >>to indicate to >>what other LoST server one has to talk to. >> >>One could, of course, configure the Finnish FG in a way that >>it matches the >>definition, namely by letting the mapping to point to a FG again (which >>co-locates the LoST server). >> >>This would be possible, no doubt, but it is worth the >>additional layer of >>indirection? I can still make the change. >> >>Ciao >>Hannes >> >>> >>>karl heinz >>> >>>> Ciao >>>> Hannes >>>> >>>>> >>>>>karl heinz >>>>> >>>>>On Tue, Oct 20, 2009 at 11:37 PM, Hannes Tschofenig >>>>> wrote: >>>>>> Hi all, >>>>>> >>>>>> A little while ago we had a discussion about the LoST sync >>>document >>>>>> and I now provided the update and added a more >>descriptive example. >>>>>> Please find the latest version here: >>>>>> >>>>>http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost-sync/ >>>draft-iet >>>>>> f-ecri >>>>>> t-lost-sync-08.txt >>>>>> >>>>>> Let me know if the update addresses the raised comments. >>>>>> >>>>>> Ciao >>>>>> Hannes >>>>>> >>>>>> PS: I believe the discussion started with this comment: >>>>>> http://www.ietf.org/mail-archive/web/ecrit/current/msg06634.html >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 hannes.tschofenig@nsn.com Mon Oct 26 02:35:35 2009 Return-Path: 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 171F53A68E9 for ; Mon, 26 Oct 2009 02:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.241 X-Spam-Level: X-Spam-Status: No, score=-2.241 tagged_above=-999 required=5 tests=[AWL=0.358, 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 HsV66512F-Gk for ; Mon, 26 Oct 2009 02:35:33 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 1B0593A6801 for ; Mon, 26 Oct 2009 02:35:32 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n9Q9Zfa6029411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 26 Oct 2009 10:35:41 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n9Q9ZZ1K031397; Mon, 26 Oct 2009 10:35:41 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.31]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 10:35:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Oct 2009 11:38:53 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4501D054BB@FIESEXC015.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST Sync -08 Thread-Index: AcpVtSL2I8hvXXKaQ2mA8K/B+RLxdgAat7LA References: <058201ca51cd$767b0640$03ffa8c0@nsnintra.net><026201ca5344$74c32cb0$03ffa8c0@nsnintra.net><027f01ca53b8$aaccd940$03ffa8c0@nsnintra.net><029801ca53c5$778e5600$03ffa8c0@nsnintra.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Karl Heinz Wolf" , "Hannes Tschofenig" X-OriginalArrivalTime: 26 Oct 2009 09:35:40.0397 (UTC) FILETIME=[AE6F11D0:01CA561F] Cc: ecrit@ietf.org Subject: Re: [Ecrit] LoST Sync -08 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: , X-List-Received-Date: Mon, 26 Oct 2009 09:35:35 -0000 >Since lost-sync references RFC5582, it should be in sync with=20 >this RFC I would suggest. Well. When one recognizes that a past document is not completely right = there is also the option to revise it.=20 > >On Fri, Oct 23, 2009 at 10:44 AM, Hannes Tschofenig=20 > wrote: >> Btw, I noticed that there are even more ways to deploy it. For=20 >> example, the Austrian FG could distribute a single mapping that says=20 >> it is responsible for Austria only (instead of re-distributing the=20 >> mappings provided from it's child LoST servers). > >In this case it would be necessary to have a LoST server at=20 >the top of the Austrian tree the FG can refer to. This LoST=20 >server would direct requests to the West, East and Vienna=20 >servers, respectively. It is largely a configuration aspect, I believe.=20 Ciao Hannes >karl heinz > >> >> In any case, here is the updated draft: >>=20 >http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost-sync/draft-iet >> f-ecri >> t-lost-sync-08.txt >> >> Let me know if you like it better now. >> >> Ciao >> Hannes >> >> >>>-----Original Message----- >>>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf=20 >>>Of Hannes Tschofenig >>>Sent: 23 October, 2009 11:13 >>>To: 'Karl Heinz Wolf' >>>Cc: ecrit@ietf.org >>>Subject: Re: [Ecrit] LoST Sync -08 >>> >>>Hi Karl Heinz, >>> >>> >>>>>>I looked at the diff and have some comments. First I think >>>>it is good >>>>>>to have an example with a figure to better understand how=20 >it works. >>>>> >>>>> Thought so too. >>>>> >>>>>>However, shouldn't Figure 1 be labeled with LoST sync for >>>>every arrow? >>>>> >>>>> One could use LoST sync also in other places but in my=20 >example the=20 >>>>> synchronization only happens between the FGs. >>>>> >>>>> I thought it would confuse if I indicate LoST Sync also=20 >between the=20 >>>>> Austrian FG and the 3 LoST servers. The reader could=20 >easily get the=20 >>>>> impression that the boundaries stored at these three servers >>>>are then >>>>> further distributed to the FG Finland. Although one could do >>>>that this >>>>> is not really the idea of the FG. >>>>ok, I see, so you wanted to prohibit that someone thinks that the=20 >>>>mapping data will be syncronized all the way to the Finish FG? >>>> >>>>I have a suggestion for a different (maybe additional?) >>>>example: why not show the usage of LoST-sync between two=20 >LoST servers=20 >>>>in the same cluster synchronizing complete mappings and one >>>LoST server >>>>pushing up it's coverage reagion. Perhaps this makes it=20 >clearer, what=20 >>>>do you think? >>>> >>> >>>I am OK with additionally describing how the LoST servers push their=20 >>>mappings up to the FG. >>> >>>>>>Figure 3: shouldn't the FG exchange mappings pointing to >>>>LoST servers >>>>>>only and not mappings pointing directly to PSAPs? >>>>> >>>>> The FG exchanges whatever it is configured to exchange. In >>>>the Finland >>>>> example there is no other LoST server and hence it only >>>>exchanges what >>>>> it has. >>>>> >>>>> Does this make sense? >>>> >>>>I just looked at RFC 5582: "Forest guides do not provide mapping=20 >>>>information >>>> =A0 themselves, but rather redirect to mapping servers." >>>> >>>>I would argue that having the URI of the PSAP is a mapping=20 >>>>information, and therefore not intented to be contained in=20 >the FG. As=20 >>>>you write in your draft, Finland has one server acting as forest=20 >>>>guide and mapping server, I would say when acting as a FG it would=20 >>>>have to distribute something pointing to itself when doing a=20 >>>>lost-sync with another FG. Does this make sense? >>> >>> >>>It is true that the definition in RFC 5582 seems to suggest that. >>>However, when you consider that the FG must have the mapping data of=20 >>>all its immediate children (in our case of the three LoST=20 >servers for=20 >>>the Austrian >>>FG) then this definition already seems a bit outdated. When a LoST=20 >>>request gets sent to a FG it then has to look at the mappings it has=20 >>>to indicate to what other LoST server one has to talk to. >>> >>>One could, of course, configure the Finnish FG in a way that it=20 >>>matches the definition, namely by letting the mapping to=20 >point to a FG=20 >>>again (which co-locates the LoST server). >>> >>>This would be possible, no doubt, but it is worth the=20 >additional layer=20 >>>of indirection? I can still make the change. >>> >>>Ciao >>>Hannes >>> >>>> >>>>karl heinz >>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>>> >>>>>>karl heinz >>>>>> >>>>>>On Tue, Oct 20, 2009 at 11:37 PM, Hannes Tschofenig=20 >>>>>> wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> A little while ago we had a discussion about the LoST sync >>>>document >>>>>>> and I now provided the update and added a more >>>descriptive example. >>>>>>> Please find the latest version here: >>>>>>> >>>>>>http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost-sync/ >>>>draft-iet >>>>>>> f-ecri >>>>>>> t-lost-sync-08.txt >>>>>>> >>>>>>> Let me know if the update addresses the raised comments. >>>>>>> >>>>>>> Ciao >>>>>>> Hannes >>>>>>> >>>>>>> PS: I believe the discussion started with this comment: >>>>>>> http://www.ietf.org/mail-archive/web/ecrit/current/msg06634.html >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 root@core3.amsl.com Mon Oct 26 06:45:01 2009 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id DAA7F28C0E8; Mon, 26 Oct 2009 06:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091026134501.DAA7F28C0E8@core3.amsl.com> Date: Mon, 26 Oct 2009 06:45:01 -0700 (PDT) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-lost-sync-08.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: , X-List-Received-Date: Mon, 26 Oct 2009 13:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements Author(s) : H. Schulzrinne, H. Tschofenig Filename : draft-ietf-ecrit-lost-sync-08.txt Pages : 27 Date : 2009-10-26 The Location-to-Service Translation (LoST) protocol is an XML-based protocol for mapping service identifiers and geodetic or civic location information to service URIs and service boundaries. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. The main data structure, the element, used for encapsulating information about service boundaries is defined in the LoST protocol specification and circumscribes the region within which all locations map to the same service Uniform Resource Identifier (URI) or set of URIs for a given service. This document defines an XML protocol to exchange these mappings between two nodes. This mechanism is designed for the exchange of authoritative elements between two entities. Exchanging cached elements, i.e. non-authoritative elements, is possible but not envisioned. In any case, this document can also be used without the LoST protocol even though the format of the element is re-used from the LoST specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-08.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 Content-Type: Message/External-body; name="draft-ietf-ecrit-lost-sync-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26063053.I-D@ietf.org> --NextPart-- From Hannes.Tschofenig@gmx.net Mon Oct 26 14:27:47 2009 Return-Path: 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 12E7228C2B8 for ; Mon, 26 Oct 2009 14:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[AWL=0.581, 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 VHVrBYvpBosV for ; Mon, 26 Oct 2009 14:27:46 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 2255228C181 for ; Mon, 26 Oct 2009 14:27:44 -0700 (PDT) Received: (qmail invoked by alias); 26 Oct 2009 21:20:20 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO 4FIL42860) [88.115.222.204] by mail.gmx.net (mp072) with SMTP; 26 Oct 2009 22:20:20 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+XO3QBg/qXoxc64ibP3HNK529cQtvig+Me4JZjjB dk6Z5auSgjlhul From: "Hannes Tschofenig" To: Date: Mon, 26 Oct 2009 23:23:27 +0200 Message-ID: <087901ca5682$93adf970$03ffa8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: AcpWgLxkSiEL2R0NsU6jGpn0Z/MHbAAAcM9w X-Y-GMX-Trusted: 0 X-FuHaFi: 0.61 Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered harmful, at least given our current experiences 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: , X-List-Received-Date: Mon, 26 Oct 2009 21:27:47 -0000 FYI: feedback from Brian regarding a recent ECRIT contribution. >-----Original Message----- >From: geopriv-bounces@ietf.org >[mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian >Sent: 26 October, 2009 23:10 >To: geopriv@ietf.org >Subject: [Geopriv] Winterbottom-ecrit-direct considered >harmful, at least given our current experiences > >The notion behind -direct is to not use a service provider to >place an emergency call. Instead, the device registers with >an Emergency Services Routing Proxy immediately before the >call and the call is routed directly from the device to the ESRP. > >At least at the moment, this is an exceedingly bad idea. > >Emergency calling authorities like service providers, a lot. >They like them because they can hold them accountable, and the >service providers don't like theft of service, which is >something the emergency call guys have an analog to. > >The facts are that where unaccountable access to emergency >calling is allowed, huge numbers of false calls occur, with no >way to stop them, and no way to tell the good ones from the >bad ones. This has been seen multiple times where so called >"simless" or "unauthenticated" calls are allowed. > >-direct precisely duplicates simless calling. The only >"registration" is an emergency registration, only emergency >calls are allowed, any device can make an emergency call if >all it has is a (radio) connection to any network. >We can predict, with a very high degree of certainty, that the >feature will be horribly abused: for example to test that a >phone without a service plan works. > >There have been studies which show tens of thousands of bad >calls with zero good ones. Nearly every authority I know >where the regulator has insisted on simless calling wants it >repealed. There is one counter example I know where the fact >that they got a couple, literally, of good calls among the >tens of thousands of bad calls was considered enough reason to >put up with the problem. > >Service providers give us information that may be useful: a >subscriber name and address for example, which is not >spoofable by the caller. They have ways to trace callers, >especially bad callers. They don't want their systems abused >any more than the emergency calling authorities do. > >This is a bad idea. A very bad idea. Please stop it. > >Someday, we may have better ways to prevent abuse. Until we >do, service providers are a good thing on an emergency call. >We don't want them cut out. > >Brian > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www.ietf.org/mailman/listinfo/geopriv > From Martin.Dawson@andrew.com Mon Oct 26 16:56:34 2009 Return-Path: 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 C64CE28C1AE for ; Mon, 26 Oct 2009 16:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 Msh3sFe2h5wa for ; Mon, 26 Oct 2009 16:56:33 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.243]) by core3.amsl.com (Postfix) with ESMTP id 8A2A728C1AB for ; Mon, 26 Oct 2009 16:56:33 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:55732 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S4798461AbZJZX4r convert rfc822-to-8bit (ORCPT ); Mon, 26 Oct 2009 18:56:47 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.393.1; Mon, 26 Oct 2009 18:56:46 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Tue, 27 Oct 2009 07:56:44 +0800 From: "Dawson, Martin" To: Hannes Tschofenig , "ecrit@ietf.org" Date: Tue, 27 Oct 2009 07:56:42 +0800 Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpWgLxkSiEL2R0NsU6jGpn0Z/MHbAAAcM9wAARjeVA= Message-ID: <8B0A9FCBB9832F43971E38010638454F0F1EA6DC@SISPE7MB1.commscope.com> References: <087901ca5682$93adf970$03ffa8c0@nsnintra.net> In-Reply-To: <087901ca5682$93adf970$03ffa8c0@nsnintra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Dawson@andrew.com Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Mon, 26 Oct 2009 23:56:34 -0000 I am glad this has come up. It's a debate that has to happen if we are to move beyond a long standing legacy misconception. In the circuit service world - whether it was POTS or mobile, the access network had full responsibility for delivering the emergency call. In that world, routing an emergency call meant getting a circuit established to the correct call center. In most parts of the world, this was done using the regional part of the PSTN to switch the circuit to a call center on the PSTN. In some jurisdictions, such as the US, it was done directly from the local exchange carrier to the call center. Either way, there was no third party involved. Now we have the Internet. We still have public access network providers. They switch packets onto the Internet for their subscribers. They can similarly ensure that packets reach the local emergency call centers. The fact is that there was no equivalent of a VSP in the traditional environment. VoIP is a presence service, and it had no common equivalent in the PSTN world. It could have, but the narrowband state of technology and the common market use cases didn't support its development. By the time ISDN arrived, the PSTN had already slipped into its palliative stage without realizing it. It's an entrenched misconception that because the circuit service provided by exchange carriers was most commonly used for "voice" (but, it should be noted, also for fax, telex, tty, security system monitoring and, even, IP data) that VSPs are somehow equivalent to exchange carriers. They are not. Indeed, involving VSPs in emergency calls is the Internet equivalent of involving long distance providers in POTS emergency calls. They are neither necessary nor particularly helpful; they can't be guaranteed to be within the emergency jurisdiction; depending on them actually diminishes the efficacy of emergency service access. It does not help the caller, the emergency service, nor the third party to insist on the third party's involvement. It can't be helped if you have over sold the benefits of VSP involvement to yourself and others Brian. It is time to have a reasoned debate. From my perspective, the argument that there is no "subscription" involved is patently false. There has to be a subscription of some description in order to get to the Internet. Yes, there is free public Internet access (just as there are free courtesy phones on the PSTN and free access to emergency services from pay phones. All these services are still connected to the public Internet infrastructure and they all represent an "operator" with some level of information about the caller. With the over-emphasis on VSPs, what is missing from the ECRIT and i3 models is the direct interface for querying the access network for subscriber data (should it prove necessary). These models need to take the long view of how emergency calling is done in the Internet age; they should not be protracting an unnecessary reliance on VSPs. I have deleted the premature and prejudicial text from the subject heading. And I'll leave this on ECRIT as the most appropriate WG. Cheers, Martin -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Tuesday, 27 October 2009 8:23 AM To: ecrit@ietf.org Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered harmful, at least given our current experiences FYI: feedback from Brian regarding a recent ECRIT contribution. >-----Original Message----- >From: geopriv-bounces@ietf.org >[mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian >Sent: 26 October, 2009 23:10 >To: geopriv@ietf.org >Subject: [Geopriv] Winterbottom-ecrit-direct considered >harmful, at least given our current experiences > >The notion behind -direct is to not use a service provider to >place an emergency call. Instead, the device registers with >an Emergency Services Routing Proxy immediately before the >call and the call is routed directly from the device to the ESRP. > >At least at the moment, this is an exceedingly bad idea. > >Emergency calling authorities like service providers, a lot. >They like them because they can hold them accountable, and the >service providers don't like theft of service, which is >something the emergency call guys have an analog to. > >The facts are that where unaccountable access to emergency >calling is allowed, huge numbers of false calls occur, with no >way to stop them, and no way to tell the good ones from the >bad ones. This has been seen multiple times where so called >"simless" or "unauthenticated" calls are allowed. > >-direct precisely duplicates simless calling. The only >"registration" is an emergency registration, only emergency >calls are allowed, any device can make an emergency call if >all it has is a (radio) connection to any network. >We can predict, with a very high degree of certainty, that the >feature will be horribly abused: for example to test that a >phone without a service plan works. > >There have been studies which show tens of thousands of bad >calls with zero good ones. Nearly every authority I know >where the regulator has insisted on simless calling wants it >repealed. There is one counter example I know where the fact >that they got a couple, literally, of good calls among the >tens of thousands of bad calls was considered enough reason to >put up with the problem. > >Service providers give us information that may be useful: a >subscriber name and address for example, which is not >spoofable by the caller. They have ways to trace callers, >especially bad callers. They don't want their systems abused >any more than the emergency calling authorities do. > >This is a bad idea. A very bad idea. Please stop it. > >Someday, we may have better ways to prevent abuse. Until we >do, service providers are a good thing on an emergency call. >We don't want them cut out. > >Brian > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www.ietf.org/mailman/listinfo/geopriv > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From br@brianrosen.net Mon Oct 26 17:59:09 2009 Return-Path: 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 ACE4B3A67F7 for ; Mon, 26 Oct 2009 17:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.192 X-Spam-Level: X-Spam-Status: No, score=-2.192 tagged_above=-999 required=5 tests=[AWL=0.407, 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 pBxralSIuhPt for ; Mon, 26 Oct 2009 17:59:08 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 4CB553A6778 for ; Mon, 26 Oct 2009 17:59:08 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.216]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1N2aOv-0002wv-Fg; Mon, 26 Oct 2009 19:59:06 -0500 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 26 Oct 2009 20:59:06 -0400 From: Brian Rosen To: "Dawson, Martin" , Hannes Tschofenig , "ecrit@ietf.org" Message-ID: Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpWgLxkSiEL2R0NsU6jGpn0Z/MHbAAAcM9wAARjeVAAAyhOFA== In-Reply-To: <8B0A9FCBB9832F43971E38010638454F0F1EA6DC@SISPE7MB1.commscope.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Tue, 27 Oct 2009 00:59:09 -0000 First of all, I put it on the wrong email list, sorry about that. Then, we have carefully arranged it so that there is no identity coming from the access network provider, and because the location is coming from that provider, we really don't want to. But even if we did, we would need a really good identifier, and there isn't one. The problem we have with -direct is anonymous callers, and if they have any option, they would also be location-less. Until and unless we get rid of anonymity, we can't encourage service provider-less calls. The draft does not make any provision to provide any kind of identity. Many networks (think free wifi for example) would make providing good identity difficult. The fact is that there is a SERVICE provider in nearly all of the communications systems. The SERVICE provider is in a position to assist the emergency calling system when it needs more information. That's what a good SERVICE provider does. Cutting them out is not a great idea. Most of the attempts to provide real time communications between people have evolved to using service providers, even when there were alternatives. File transfer via something like Torrent is a counterexample (which isn't real time), but even there, you end up with service providers like The Pirate Bay (R.I.P) to provide introduction services. I don't think we're going to see changes that eliminate service providers, and in this case, they provide value to the emergency calling systems. All of the emergency professionals I know have issues with service providers, but they would react with horror if you suggested cutting them out. Ask them, please. So, I claim you have a solution in search of a problem. We have solved the "calling network isn't the access network" problem already. Service providers ARE in the path now, in nearly every case (in fact a counter example escapes me, although there probably are some). There is no movement I can detect which would change that any time soon; quite the opposite. We have a known killer problem without some kind of subscription to a service that provides a good identity, for which you provide no answers. We have experience with the killer problem: sim-less calling was supposed to provide a way to make an emergency call in exactly the kinds of circumstances you are describing. Our real world experience is that you create a huge problem that diverts resources from helping people to chasing scammers and flea-market sellers. Nothing is perfect: you can get a AIM screen name without a very good identity for example. However, the notion that we're going to provide direct access without a service provider deliberately, especially without really good identity from the access network is, in my opinion not only a no, it's a heck no. I'll line up as many emergency service professionals as you would like to tell you this is a harmful idea. On 10/26/09 7:56 PM, "Dawson, Martin" wrote: > I am glad this has come up. It's a debate that has to happen if we are to move > beyond a long standing legacy misconception. > > In the circuit service world - whether it was POTS or mobile, the access > network had full responsibility for delivering the emergency call. In that > world, routing an emergency call meant getting a circuit established to the > correct call center. In most parts of the world, this was done using the > regional part of the PSTN to switch the circuit to a call center on the PSTN. > In some jurisdictions, such as the US, it was done directly from the local > exchange carrier to the call center. Either way, there was no third party > involved. > > Now we have the Internet. We still have public access network providers. They > switch packets onto the Internet for their subscribers. They can similarly > ensure that packets reach the local emergency call centers. > > The fact is that there was no equivalent of a VSP in the traditional > environment. VoIP is a presence service, and it had no common equivalent in > the PSTN world. It could have, but the narrowband state of technology and the > common market use cases didn't support its development. By the time ISDN > arrived, the PSTN had already slipped into its palliative stage without > realizing it. > > It's an entrenched misconception that because the circuit service provided by > exchange carriers was most commonly used for "voice" (but, it should be noted, > also for fax, telex, tty, security system monitoring and, even, IP data) that > VSPs are somehow equivalent to exchange carriers. They are not. > > Indeed, involving VSPs in emergency calls is the Internet equivalent of > involving long distance providers in POTS emergency calls. They are neither > necessary nor particularly helpful; they can't be guaranteed to be within the > emergency jurisdiction; depending on them actually diminishes the efficacy of > emergency service access. It does not help the caller, the emergency service, > nor the third party to insist on the third party's involvement. > > It can't be helped if you have over sold the benefits of VSP involvement to > yourself and others Brian. It is time to have a reasoned debate. From my > perspective, the argument that there is no "subscription" involved is patently > false. There has to be a subscription of some description in order to get to > the Internet. Yes, there is free public Internet access (just as there are > free courtesy phones on the PSTN and free access to emergency services from > pay phones. All these services are still connected to the public Internet > infrastructure and they all represent an "operator" with some level of > information about the caller. > > With the over-emphasis on VSPs, what is missing from the ECRIT and i3 models > is the direct interface for querying the access network for subscriber data > (should it prove necessary). These models need to take the long view of how > emergency calling is done in the Internet age; they should not be protracting > an unnecessary reliance on VSPs. > > I have deleted the premature and prejudicial text from the subject heading. > And I'll leave this on ECRIT as the most appropriate WG. > > Cheers, > Martin > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Hannes Tschofenig > Sent: Tuesday, 27 October 2009 8:23 AM > To: ecrit@ietf.org > Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered harmful, > at least given our current experiences > > FYI: feedback from Brian regarding a recent ECRIT contribution. > >> -----Original Message----- >> From: geopriv-bounces@ietf.org >> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian >> Sent: 26 October, 2009 23:10 >> To: geopriv@ietf.org >> Subject: [Geopriv] Winterbottom-ecrit-direct considered >> harmful, at least given our current experiences >> >> The notion behind -direct is to not use a service provider to >> place an emergency call. Instead, the device registers with >> an Emergency Services Routing Proxy immediately before the >> call and the call is routed directly from the device to the ESRP. >> >> At least at the moment, this is an exceedingly bad idea. >> >> Emergency calling authorities like service providers, a lot. >> They like them because they can hold them accountable, and the >> service providers don't like theft of service, which is >> something the emergency call guys have an analog to. >> >> The facts are that where unaccountable access to emergency >> calling is allowed, huge numbers of false calls occur, with no >> way to stop them, and no way to tell the good ones from the >> bad ones. This has been seen multiple times where so called >> "simless" or "unauthenticated" calls are allowed. >> >> -direct precisely duplicates simless calling. The only >> "registration" is an emergency registration, only emergency >> calls are allowed, any device can make an emergency call if >> all it has is a (radio) connection to any network. >> We can predict, with a very high degree of certainty, that the >> feature will be horribly abused: for example to test that a >> phone without a service plan works. >> >> There have been studies which show tens of thousands of bad >> calls with zero good ones. Nearly every authority I know >> where the regulator has insisted on simless calling wants it >> repealed. There is one counter example I know where the fact >> that they got a couple, literally, of good calls among the >> tens of thousands of bad calls was considered enough reason to >> put up with the problem. >> >> Service providers give us information that may be useful: a >> subscriber name and address for example, which is not >> spoofable by the caller. They have ways to trace callers, >> especially bad callers. They don't want their systems abused >> any more than the emergency calling authorities do. >> >> This is a bad idea. A very bad idea. Please stop it. >> >> Someday, we may have better ways to prevent abuse. Until we >> do, service providers are a good thing on an emergency call. >> We don't want them cut out. >> >> Brian >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www.ietf.org/mailman/listinfo/geopriv >> > > _______________________________________________ > 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 Martin.Thomson@andrew.com Mon Oct 26 18:06:32 2009 Return-Path: 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 784D63A67F7 for ; Mon, 26 Oct 2009 18:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 SEbp5paaZiRA for ; Mon, 26 Oct 2009 18:06:31 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.243]) by core3.amsl.com (Postfix) with ESMTP id C25AE3A6778 for ; Mon, 26 Oct 2009 18:06:30 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:62311 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S4800139AbZJ0BGo (ORCPT ); Mon, 26 Oct 2009 20:06:44 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.393.1; Mon, 26 Oct 2009 20:06:44 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 27 Oct 2009 09:06:41 +0800 From: "Thomson, Martin" To: Brian Rosen , "Dawson, Martin" , Hannes Tschofenig , "ecrit@ietf.org" Date: Tue, 27 Oct 2009 09:07:07 +0800 Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpWgLxkSiEL2R0NsU6jGpn0Z/MHbAAAcM9wAARjeVAAAyhOFAAAFvaQ Message-ID: <8B0A9FCBB9832F43971E38010638454F0F1EA71B@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F0F1EA6DC@SISPE7MB1.commscope.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Tue, 27 Oct 2009 01:06:32 -0000 VGhlIG9ubHkgU0VSVklDRSBuZWNlc3NhcnkgaW4gdGhpcyBjYXNlIGlzIGludGVybmV0IGFjY2Vz cy4NCg0KSWYgY2FsbGVyIGlkZW50aXR5IGlzIHlvdXIgc29sdXRpb24gdG8gdGhlIHByb2JsZW0s IHRoZW4geW91J3JlIGpvaW5pbmcgaWxsdXN0cmlvdXMgY29tcGFueSBbMV0uICBJdCBjZXJ0YWlu bHkgd291bGQgc29sdmUgYSBsb3Qgb2YgcHJvYmxlbXMuLi4NCg0KSSB0aGluayB0aGF0IGp1bXBp bmcgdG8gY29uY2x1c2lvbnMgaGVyZSBkb2Vzbid0IGRvIHVzIGFueSBmYXZvdXJzLiAgUGVyaGFw cyB3ZSBuZWVkIHRvIGRvIGFzIHdhcyBzdWdnZXN0ZWQgYnkgQmVybmFyZCBpbiBTdG9ja2hvbG0g WzJdIGFuZCBzdGFydCB0byBsb29rIGF0IHRoZSBzZWN1cml0eSBvZiB0aGUgZW50aXJlIHN5c3Rl bS4NCg0KLS1NYXJ0aW4NCg0KWzFdICA8aHR0cDovL3d3dy50aGVyZWdpc3Rlci5jby51ay8yMDA5 LzEwLzE2L2thc3BlcnNreV9yZWJ1a2VzX25ldF9hbm9ueW1pdHkvPg0KWzJdICA8aHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdHNjaG9mZW5pZy1lY3JpdC10cnVzdHdvcnRoeS1sb2Nh dGlvbj4NCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGVjcml0LWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYN Cj4gT2YgQnJpYW4gUm9zZW4NCj4gU2VudDogVHVlc2RheSwgMjcgT2N0b2JlciAyMDA5IDExOjU5 IEFNDQo+IFRvOiBEYXdzb24sIE1hcnRpbjsgSGFubmVzIFRzY2hvZmVuaWc7IGVjcml0QGlldGYu b3JnDQo+IFN1YmplY3Q6IFJlOiBbRWNyaXRdIEZXOiBbR2VvcHJpdl0gV2ludGVyYm90dG9tLWVj cml0LWRpcmVjdCBjb25zaWRlcmVkDQo+IA0KPiBGaXJzdCBvZiBhbGwsIEkgcHV0IGl0IG9uIHRo ZSB3cm9uZyBlbWFpbCBsaXN0LCBzb3JyeSBhYm91dCB0aGF0Lg0KPiANCj4gVGhlbiwgd2UgaGF2 ZSBjYXJlZnVsbHkgYXJyYW5nZWQgaXQgc28gdGhhdCB0aGVyZSBpcyBubyBpZGVudGl0eSBjb21p bmcNCj4gZnJvbQ0KPiB0aGUgYWNjZXNzIG5ldHdvcmsgcHJvdmlkZXIsIGFuZCBiZWNhdXNlIHRo ZSBsb2NhdGlvbiBpcyBjb21pbmcgZnJvbQ0KPiB0aGF0DQo+IHByb3ZpZGVyLCB3ZSByZWFsbHkg ZG9uJ3Qgd2FudCB0by4gIEJ1dCBldmVuIGlmIHdlIGRpZCwgd2Ugd291bGQgbmVlZCBhDQo+IHJl YWxseSBnb29kIGlkZW50aWZpZXIsIGFuZCB0aGVyZSBpc24ndCBvbmUuDQo+IA0KPiBUaGUgcHJv YmxlbSB3ZSBoYXZlIHdpdGggLWRpcmVjdCBpcyBhbm9ueW1vdXMgY2FsbGVycywgYW5kIGlmIHRo ZXkgaGF2ZQ0KPiBhbnkNCj4gb3B0aW9uLCB0aGV5IHdvdWxkIGFsc28gYmUgbG9jYXRpb24tbGVz cy4gIFVudGlsIGFuZCB1bmxlc3Mgd2UgZ2V0IHJpZA0KPiBvZg0KPiBhbm9ueW1pdHksIHdlIGNh bid0IGVuY291cmFnZSBzZXJ2aWNlIHByb3ZpZGVyLWxlc3MgY2FsbHMuICBUaGUgZHJhZnQNCj4g ZG9lcw0KPiBub3QgbWFrZSBhbnkgcHJvdmlzaW9uIHRvIHByb3ZpZGUgYW55IGtpbmQgb2YgaWRl bnRpdHkuICBNYW55IG5ldHdvcmtzDQo+ICh0aGluayBmcmVlIHdpZmkgZm9yIGV4YW1wbGUpIHdv dWxkIG1ha2UgcHJvdmlkaW5nIGdvb2QgaWRlbnRpdHkNCj4gZGlmZmljdWx0Lg0KPiANCj4gVGhl IGZhY3QgaXMgdGhhdCB0aGVyZSBpcyBhIFNFUlZJQ0UgcHJvdmlkZXIgaW4gbmVhcmx5IGFsbCBv ZiB0aGUNCj4gY29tbXVuaWNhdGlvbnMgc3lzdGVtcy4gICBUaGUgU0VSVklDRSBwcm92aWRlciBp cyBpbiBhIHBvc2l0aW9uIHRvDQo+IGFzc2lzdA0KPiB0aGUgZW1lcmdlbmN5IGNhbGxpbmcgc3lz dGVtIHdoZW4gaXQgbmVlZHMgbW9yZSBpbmZvcm1hdGlvbi4gIFRoYXQncw0KPiB3aGF0IGENCj4g Z29vZCBTRVJWSUNFIHByb3ZpZGVyIGRvZXMuICBDdXR0aW5nIHRoZW0gb3V0IGlzIG5vdCBhIGdy ZWF0IGlkZWEuDQo+IE1vc3Qgb2YNCj4gdGhlIGF0dGVtcHRzIHRvIHByb3ZpZGUgcmVhbCB0aW1l IGNvbW11bmljYXRpb25zIGJldHdlZW4gcGVvcGxlIGhhdmUNCj4gZXZvbHZlZA0KPiB0byB1c2lu ZyBzZXJ2aWNlIHByb3ZpZGVycywgZXZlbiB3aGVuIHRoZXJlIHdlcmUgYWx0ZXJuYXRpdmVzLiAg RmlsZQ0KPiB0cmFuc2ZlciB2aWEgc29tZXRoaW5nIGxpa2UgVG9ycmVudCBpcyBhIGNvdW50ZXJl eGFtcGxlICh3aGljaCBpc24ndA0KPiByZWFsDQo+IHRpbWUpLCBidXQgZXZlbiB0aGVyZSwgeW91 IGVuZCB1cCB3aXRoIHNlcnZpY2UgcHJvdmlkZXJzIGxpa2UgVGhlDQo+IFBpcmF0ZSBCYXkNCj4g KFIuSS5QKSB0byBwcm92aWRlIGludHJvZHVjdGlvbiBzZXJ2aWNlcy4gIEkgZG9uJ3QgdGhpbmsg d2UncmUgZ29pbmcgdG8NCj4gc2VlDQo+IGNoYW5nZXMgdGhhdCBlbGltaW5hdGUgc2VydmljZSBw cm92aWRlcnMsIGFuZCBpbiB0aGlzIGNhc2UsIHRoZXkNCj4gcHJvdmlkZQ0KPiB2YWx1ZSB0byB0 aGUgZW1lcmdlbmN5IGNhbGxpbmcgc3lzdGVtcy4gIEFsbCBvZiB0aGUgZW1lcmdlbmN5DQo+IHBy b2Zlc3Npb25hbHMNCj4gSSBrbm93IGhhdmUgaXNzdWVzIHdpdGggc2VydmljZSBwcm92aWRlcnMs IGJ1dCB0aGV5IHdvdWxkIHJlYWN0IHdpdGgNCj4gaG9ycm9yDQo+IGlmIHlvdSBzdWdnZXN0ZWQg Y3V0dGluZyB0aGVtIG91dC4gIEFzayB0aGVtLCBwbGVhc2UuDQo+IA0KPiBTbywgSSBjbGFpbSB5 b3UgaGF2ZSBhIHNvbHV0aW9uIGluIHNlYXJjaCBvZiBhIHByb2JsZW0uICBXZSBoYXZlIHNvbHZl ZA0KPiB0aGUNCj4gImNhbGxpbmcgbmV0d29yayBpc24ndCB0aGUgYWNjZXNzIG5ldHdvcmsiIHBy b2JsZW0gYWxyZWFkeS4gIFNlcnZpY2UNCj4gcHJvdmlkZXJzIEFSRSBpbiB0aGUgcGF0aCBub3cs IGluIG5lYXJseSBldmVyeSBjYXNlIChpbiBmYWN0IGEgY291bnRlcg0KPiBleGFtcGxlIGVzY2Fw ZXMgbWUsIGFsdGhvdWdoIHRoZXJlIHByb2JhYmx5IGFyZSBzb21lKS4gIFRoZXJlIGlzIG5vDQo+ IG1vdmVtZW50DQo+IEkgY2FuIGRldGVjdCB3aGljaCB3b3VsZCBjaGFuZ2UgdGhhdCBhbnkgdGlt ZSBzb29uOyBxdWl0ZSB0aGUgb3Bwb3NpdGUuDQo+IFdlDQo+IGhhdmUgYSBrbm93biBraWxsZXIg cHJvYmxlbSB3aXRob3V0IHNvbWUga2luZCBvZiBzdWJzY3JpcHRpb24gdG8gYQ0KPiBzZXJ2aWNl DQo+IHRoYXQgcHJvdmlkZXMgYSBnb29kIGlkZW50aXR5LCBmb3Igd2hpY2ggeW91IHByb3ZpZGUg bm8gYW5zd2Vycy4gIFdlDQo+IGhhdmUNCj4gZXhwZXJpZW5jZSB3aXRoIHRoZSBraWxsZXIgcHJv YmxlbTogc2ltLWxlc3MgY2FsbGluZyB3YXMgc3VwcG9zZWQgdG8NCj4gcHJvdmlkZQ0KPiBhIHdh eSB0byBtYWtlIGFuIGVtZXJnZW5jeSBjYWxsIGluIGV4YWN0bHkgdGhlIGtpbmRzIG9mIGNpcmN1 bXN0YW5jZXMNCj4geW91DQo+IGFyZSBkZXNjcmliaW5nLiAgT3VyIHJlYWwgd29ybGQgZXhwZXJp ZW5jZSBpcyB0aGF0IHlvdSBjcmVhdGUgYSBodWdlDQo+IHByb2JsZW0NCj4gdGhhdCBkaXZlcnRz IHJlc291cmNlcyBmcm9tIGhlbHBpbmcgcGVvcGxlIHRvIGNoYXNpbmcgc2NhbW1lcnMgYW5kDQo+ IGZsZWEtbWFya2V0IHNlbGxlcnMuDQo+IA0KPiBOb3RoaW5nIGlzIHBlcmZlY3Q6IHlvdSBjYW4g Z2V0IGEgQUlNIHNjcmVlbiBuYW1lIHdpdGhvdXQgYSB2ZXJ5IGdvb2QNCj4gaWRlbnRpdHkgZm9y IGV4YW1wbGUuICBIb3dldmVyLCB0aGUgbm90aW9uIHRoYXQgd2UncmUgZ29pbmcgdG8gcHJvdmlk ZQ0KPiBkaXJlY3QgYWNjZXNzIHdpdGhvdXQgYSBzZXJ2aWNlIHByb3ZpZGVyIGRlbGliZXJhdGVs eSwgZXNwZWNpYWxseQ0KPiB3aXRob3V0DQo+IHJlYWxseSBnb29kIGlkZW50aXR5IGZyb20gdGhl IGFjY2VzcyBuZXR3b3JrIGlzLCBpbiBteSBvcGluaW9uIG5vdCBvbmx5DQo+IGENCj4gbm8sIGl0 J3MgYSBoZWNrIG5vLiAgSSdsbCBsaW5lIHVwIGFzIG1hbnkgZW1lcmdlbmN5IHNlcnZpY2UNCj4g cHJvZmVzc2lvbmFscyBhcw0KPiB5b3Ugd291bGQgbGlrZSB0byB0ZWxsIHlvdSB0aGlzIGlzIGEg aGFybWZ1bCBpZGVhLg0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBPbiAxMC8yNi8wOSA3OjU2 IFBNLCAiRGF3c29uLCBNYXJ0aW4iIDxNYXJ0aW4uRGF3c29uQGFuZHJldy5jb20+IHdyb3RlOg0K PiANCj4gPiBJIGFtIGdsYWQgdGhpcyBoYXMgY29tZSB1cC4gSXQncyBhIGRlYmF0ZSB0aGF0IGhh cyB0byBoYXBwZW4gaWYgd2UNCj4gYXJlIHRvIG1vdmUNCj4gPiBiZXlvbmQgYSBsb25nIHN0YW5k aW5nIGxlZ2FjeSBtaXNjb25jZXB0aW9uLg0KPiA+DQo+ID4gSW4gdGhlIGNpcmN1aXQgc2Vydmlj ZSB3b3JsZCAtIHdoZXRoZXIgaXQgd2FzIFBPVFMgb3IgbW9iaWxlLCB0aGUNCj4gYWNjZXNzDQo+ ID4gbmV0d29yayBoYWQgZnVsbCByZXNwb25zaWJpbGl0eSBmb3IgZGVsaXZlcmluZyB0aGUgZW1l cmdlbmN5IGNhbGwuIEluDQo+IHRoYXQNCj4gPiB3b3JsZCwgcm91dGluZyBhbiBlbWVyZ2VuY3kg Y2FsbCBtZWFudCBnZXR0aW5nIGEgY2lyY3VpdCBlc3RhYmxpc2hlZA0KPiB0byB0aGUNCj4gPiBj b3JyZWN0IGNhbGwgY2VudGVyLiBJbiBtb3N0IHBhcnRzIG9mIHRoZSB3b3JsZCwgdGhpcyB3YXMg ZG9uZSB1c2luZw0KPiB0aGUNCj4gPiByZWdpb25hbCBwYXJ0IG9mIHRoZSBQU1ROIHRvIHN3aXRj aCB0aGUgY2lyY3VpdCB0byBhIGNhbGwgY2VudGVyIG9uDQo+IHRoZSBQU1ROLg0KPiA+IEluIHNv bWUganVyaXNkaWN0aW9ucywgc3VjaCBhcyB0aGUgVVMsIGl0IHdhcyBkb25lIGRpcmVjdGx5IGZy b20gdGhlDQo+IGxvY2FsDQo+ID4gZXhjaGFuZ2UgY2FycmllciB0byB0aGUgY2FsbCBjZW50ZXIu IEVpdGhlciB3YXksIHRoZXJlIHdhcyBubyB0aGlyZA0KPiBwYXJ0eQ0KPiA+IGludm9sdmVkLg0K PiA+DQo+ID4gTm93IHdlIGhhdmUgdGhlIEludGVybmV0LiBXZSBzdGlsbCBoYXZlIHB1YmxpYyBh Y2Nlc3MgbmV0d29yaw0KPiBwcm92aWRlcnMuIFRoZXkNCj4gPiBzd2l0Y2ggcGFja2V0cyBvbnRv IHRoZSBJbnRlcm5ldCBmb3IgdGhlaXIgc3Vic2NyaWJlcnMuIFRoZXkgY2FuDQo+IHNpbWlsYXJs eQ0KPiA+IGVuc3VyZSB0aGF0IHBhY2tldHMgcmVhY2ggdGhlIGxvY2FsIGVtZXJnZW5jeSBjYWxs IGNlbnRlcnMuDQo+ID4NCj4gPiBUaGUgZmFjdCBpcyB0aGF0IHRoZXJlIHdhcyBubyBlcXVpdmFs ZW50IG9mIGEgVlNQIGluIHRoZSB0cmFkaXRpb25hbA0KPiA+IGVudmlyb25tZW50LiBWb0lQIGlz IGEgcHJlc2VuY2Ugc2VydmljZSwgYW5kIGl0IGhhZCBubyBjb21tb24NCj4gZXF1aXZhbGVudCBp bg0KPiA+IHRoZSBQU1ROIHdvcmxkLiBJdCBjb3VsZCBoYXZlLCBidXQgdGhlIG5hcnJvd2JhbmQg c3RhdGUgb2YgdGVjaG5vbG9neQ0KPiBhbmQgdGhlDQo+ID4gY29tbW9uIG1hcmtldCB1c2UgY2Fz ZXMgZGlkbid0IHN1cHBvcnQgaXRzIGRldmVsb3BtZW50LiBCeSB0aGUgdGltZQ0KPiBJU0RODQo+ ID4gYXJyaXZlZCwgdGhlIFBTVE4gaGFkIGFscmVhZHkgc2xpcHBlZCBpbnRvIGl0cyBwYWxsaWF0 aXZlIHN0YWdlDQo+IHdpdGhvdXQNCj4gPiByZWFsaXppbmcgaXQuDQo+ID4NCj4gPiBJdCdzIGFu IGVudHJlbmNoZWQgbWlzY29uY2VwdGlvbiB0aGF0IGJlY2F1c2UgdGhlIGNpcmN1aXQgc2Vydmlj ZQ0KPiBwcm92aWRlZCBieQ0KPiA+IGV4Y2hhbmdlIGNhcnJpZXJzIHdhcyBtb3N0IGNvbW1vbmx5 IHVzZWQgZm9yICJ2b2ljZSIgKGJ1dCwgaXQgc2hvdWxkDQo+IGJlIG5vdGVkLA0KPiA+IGFsc28g Zm9yIGZheCwgdGVsZXgsIHR0eSwgc2VjdXJpdHkgc3lzdGVtIG1vbml0b3JpbmcgYW5kLCBldmVu LCBJUA0KPiBkYXRhKSB0aGF0DQo+ID4gVlNQcyBhcmUgc29tZWhvdyBlcXVpdmFsZW50IHRvIGV4 Y2hhbmdlIGNhcnJpZXJzLiBUaGV5IGFyZSBub3QuDQo+ID4NCj4gPiBJbmRlZWQsIGludm9sdmlu ZyBWU1BzIGluIGVtZXJnZW5jeSBjYWxscyBpcyB0aGUgSW50ZXJuZXQgZXF1aXZhbGVudA0KPiBv Zg0KPiA+IGludm9sdmluZyBsb25nIGRpc3RhbmNlIHByb3ZpZGVycyBpbiBQT1RTIGVtZXJnZW5j eSBjYWxscy4gVGhleSBhcmUNCj4gbmVpdGhlcg0KPiA+IG5lY2Vzc2FyeSBub3IgcGFydGljdWxh cmx5IGhlbHBmdWw7IHRoZXkgY2FuJ3QgYmUgZ3VhcmFudGVlZCB0byBiZQ0KPiB3aXRoaW4gdGhl DQo+ID4gZW1lcmdlbmN5IGp1cmlzZGljdGlvbjsgZGVwZW5kaW5nIG9uIHRoZW0gYWN0dWFsbHkg ZGltaW5pc2hlcyB0aGUNCj4gZWZmaWNhY3kgb2YNCj4gPiBlbWVyZ2VuY3kgc2VydmljZSBhY2Nl c3MuIEl0IGRvZXMgbm90IGhlbHAgdGhlIGNhbGxlciwgdGhlIGVtZXJnZW5jeQ0KPiBzZXJ2aWNl LA0KPiA+IG5vciB0aGUgdGhpcmQgcGFydHkgdG8gaW5zaXN0IG9uIHRoZSB0aGlyZCBwYXJ0eSdz IGludm9sdmVtZW50Lg0KPiA+DQo+ID4gSXQgY2FuJ3QgYmUgaGVscGVkIGlmIHlvdSBoYXZlIG92 ZXIgc29sZCB0aGUgYmVuZWZpdHMgb2YgVlNQDQo+IGludm9sdmVtZW50IHRvDQo+ID4geW91cnNl bGYgYW5kIG90aGVycyBCcmlhbi4gSXQgaXMgdGltZSB0byBoYXZlIGEgcmVhc29uZWQgZGViYXRl LiBGcm9tDQo+IG15DQo+ID4gcGVyc3BlY3RpdmUsIHRoZSBhcmd1bWVudCB0aGF0IHRoZXJlIGlz IG5vICJzdWJzY3JpcHRpb24iIGludm9sdmVkIGlzDQo+IHBhdGVudGx5DQo+ID4gZmFsc2UuIFRo ZXJlIGhhcyB0byBiZSBhIHN1YnNjcmlwdGlvbiBvZiBzb21lIGRlc2NyaXB0aW9uIGluIG9yZGVy IHRvDQo+IGdldCB0bw0KPiA+IHRoZSBJbnRlcm5ldC4gWWVzLCB0aGVyZSBpcyBmcmVlIHB1Ymxp YyBJbnRlcm5ldCBhY2Nlc3MgKGp1c3QgYXMNCj4gdGhlcmUgYXJlDQo+ID4gZnJlZSBjb3VydGVz eSBwaG9uZXMgb24gdGhlIFBTVE4gYW5kIGZyZWUgYWNjZXNzIHRvIGVtZXJnZW5jeQ0KPiBzZXJ2 aWNlcyBmcm9tDQo+ID4gcGF5IHBob25lcy4gQWxsIHRoZXNlIHNlcnZpY2VzIGFyZSBzdGlsbCBj b25uZWN0ZWQgdG8gdGhlIHB1YmxpYw0KPiBJbnRlcm5ldA0KPiA+IGluZnJhc3RydWN0dXJlIGFu ZCB0aGV5IGFsbCByZXByZXNlbnQgYW4gIm9wZXJhdG9yIiB3aXRoIHNvbWUgbGV2ZWwNCj4gb2YN Cj4gPiBpbmZvcm1hdGlvbiBhYm91dCB0aGUgY2FsbGVyLg0KPiA+DQo+ID4gV2l0aCB0aGUgb3Zl ci1lbXBoYXNpcyBvbiBWU1BzLCB3aGF0IGlzIG1pc3NpbmcgZnJvbSB0aGUgRUNSSVQgYW5kIGkz DQo+IG1vZGVscw0KPiA+IGlzIHRoZSBkaXJlY3QgaW50ZXJmYWNlIGZvciBxdWVyeWluZyB0aGUg YWNjZXNzIG5ldHdvcmsgZm9yDQo+IHN1YnNjcmliZXIgZGF0YQ0KPiA+IChzaG91bGQgaXQgcHJv dmUgbmVjZXNzYXJ5KS4gVGhlc2UgbW9kZWxzIG5lZWQgdG8gdGFrZSB0aGUgbG9uZyB2aWV3DQo+ IG9mIGhvdw0KPiA+IGVtZXJnZW5jeSBjYWxsaW5nIGlzIGRvbmUgaW4gdGhlIEludGVybmV0IGFn ZTsgdGhleSBzaG91bGQgbm90IGJlDQo+IHByb3RyYWN0aW5nDQo+ID4gYW4gdW5uZWNlc3Nhcnkg cmVsaWFuY2Ugb24gVlNQcy4NCj4gPg0KPiA+IEkgaGF2ZSBkZWxldGVkIHRoZSBwcmVtYXR1cmUg YW5kIHByZWp1ZGljaWFsIHRleHQgZnJvbSB0aGUgc3ViamVjdA0KPiBoZWFkaW5nLg0KPiA+IEFu ZCBJJ2xsIGxlYXZlIHRoaXMgb24gRUNSSVQgYXMgdGhlIG1vc3QgYXBwcm9wcmlhdGUgV0cuDQo+ ID4NCj4gPiBDaGVlcnMsDQo+ID4gTWFydGluDQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiA+IEZyb206IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzplY3JpdC1i b3VuY2VzQGlldGYub3JnXSBPbg0KPiBCZWhhbGYgT2YNCj4gPiBIYW5uZXMgVHNjaG9mZW5pZw0K PiA+IFNlbnQ6IFR1ZXNkYXksIDI3IE9jdG9iZXIgMjAwOSA4OjIzIEFNDQo+ID4gVG86IGVjcml0 QGlldGYub3JnDQo+ID4gU3ViamVjdDogW0Vjcml0XSBGVzogW0dlb3ByaXZdIFdpbnRlcmJvdHRv bS1lY3JpdC1kaXJlY3QgY29uc2lkZXJlZA0KPiBoYXJtZnVsLA0KPiA+IGF0IGxlYXN0IGdpdmVu IG91ciBjdXJyZW50IGV4cGVyaWVuY2VzDQo+ID4NCj4gPiBGWUk6IGZlZWRiYWNrIGZyb20gQnJp YW4gcmVnYXJkaW5nIGEgcmVjZW50IEVDUklUIGNvbnRyaWJ1dGlvbi4NCj4gPg0KPiA+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBnZW9wcml2LWJvdW5jZXNAaWV0Zi5v cmcNCj4gPj4gW21haWx0bzpnZW9wcml2LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBS b3NlbiwgQnJpYW4NCj4gPj4gU2VudDogMjYgT2N0b2JlciwgMjAwOSAyMzoxMA0KPiA+PiBUbzog Z2VvcHJpdkBpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBbR2VvcHJpdl0gV2ludGVyYm90dG9tLWVj cml0LWRpcmVjdCBjb25zaWRlcmVkDQo+ID4+IGhhcm1mdWwsIGF0IGxlYXN0IGdpdmVuIG91ciBj dXJyZW50IGV4cGVyaWVuY2VzDQo+ID4+DQo+ID4+IFRoZSBub3Rpb24gYmVoaW5kIC1kaXJlY3Qg aXMgdG8gbm90IHVzZSBhIHNlcnZpY2UgcHJvdmlkZXIgdG8NCj4gPj4gcGxhY2UgYW4gZW1lcmdl bmN5IGNhbGwuICBJbnN0ZWFkLCB0aGUgZGV2aWNlIHJlZ2lzdGVycyB3aXRoDQo+ID4+IGFuIEVt ZXJnZW5jeSBTZXJ2aWNlcyBSb3V0aW5nIFByb3h5IGltbWVkaWF0ZWx5IGJlZm9yZSB0aGUNCj4g Pj4gY2FsbCBhbmQgdGhlIGNhbGwgaXMgcm91dGVkIGRpcmVjdGx5IGZyb20gdGhlIGRldmljZSB0 byB0aGUgRVNSUC4NCj4gPj4NCj4gPj4gQXQgbGVhc3QgYXQgdGhlIG1vbWVudCwgdGhpcyBpcyBh biBleGNlZWRpbmdseSBiYWQgaWRlYS4NCj4gPj4NCj4gPj4gRW1lcmdlbmN5IGNhbGxpbmcgYXV0 aG9yaXRpZXMgbGlrZSBzZXJ2aWNlIHByb3ZpZGVycywgYSBsb3QuDQo+ID4+IFRoZXkgbGlrZSB0 aGVtIGJlY2F1c2UgdGhleSBjYW4gaG9sZCB0aGVtIGFjY291bnRhYmxlLCBhbmQgdGhlDQo+ID4+ IHNlcnZpY2UgcHJvdmlkZXJzIGRvbid0IGxpa2UgdGhlZnQgb2Ygc2VydmljZSwgd2hpY2ggaXMN Cj4gPj4gc29tZXRoaW5nIHRoZSBlbWVyZ2VuY3kgY2FsbCBndXlzIGhhdmUgYW4gYW5hbG9nIHRv Lg0KPiA+Pg0KPiA+PiBUaGUgZmFjdHMgYXJlIHRoYXQgd2hlcmUgdW5hY2NvdW50YWJsZSBhY2Nl c3MgdG8gZW1lcmdlbmN5DQo+ID4+IGNhbGxpbmcgaXMgYWxsb3dlZCwgaHVnZSBudW1iZXJzIG9m IGZhbHNlIGNhbGxzIG9jY3VyLCB3aXRoIG5vDQo+ID4+IHdheSB0byBzdG9wIHRoZW0sIGFuZCBu byB3YXkgdG8gdGVsbCB0aGUgZ29vZCBvbmVzIGZyb20gdGhlDQo+ID4+IGJhZCBvbmVzLiAgVGhp cyBoYXMgYmVlbiBzZWVuIG11bHRpcGxlIHRpbWVzIHdoZXJlIHNvIGNhbGxlZA0KPiA+PiAic2lt bGVzcyIgb3IgInVuYXV0aGVudGljYXRlZCIgY2FsbHMgYXJlIGFsbG93ZWQuDQo+ID4+DQo+ID4+ IC1kaXJlY3QgcHJlY2lzZWx5IGR1cGxpY2F0ZXMgc2ltbGVzcyBjYWxsaW5nLiAgVGhlIG9ubHkN Cj4gPj4gInJlZ2lzdHJhdGlvbiIgaXMgYW4gZW1lcmdlbmN5IHJlZ2lzdHJhdGlvbiwgb25seSBl bWVyZ2VuY3kNCj4gPj4gY2FsbHMgYXJlIGFsbG93ZWQsIGFueSBkZXZpY2UgY2FuIG1ha2UgYW4g ZW1lcmdlbmN5IGNhbGwgaWYNCj4gPj4gYWxsIGl0IGhhcyBpcyBhIChyYWRpbykgY29ubmVjdGlv biB0byBhbnkgbmV0d29yay4NCj4gPj4gV2UgY2FuIHByZWRpY3QsIHdpdGggYSB2ZXJ5IGhpZ2gg ZGVncmVlIG9mIGNlcnRhaW50eSwgdGhhdCB0aGUNCj4gPj4gZmVhdHVyZSB3aWxsIGJlIGhvcnJp Ymx5IGFidXNlZDogZm9yIGV4YW1wbGUgdG8gdGVzdCB0aGF0IGENCj4gPj4gcGhvbmUgd2l0aG91 dCBhIHNlcnZpY2UgcGxhbiB3b3Jrcy4NCj4gPj4NCj4gPj4gVGhlcmUgaGF2ZSBiZWVuIHN0dWRp ZXMgd2hpY2ggc2hvdyB0ZW5zIG9mIHRob3VzYW5kcyBvZiBiYWQNCj4gPj4gY2FsbHMgd2l0aCB6 ZXJvIGdvb2Qgb25lcy4gIE5lYXJseSBldmVyeSBhdXRob3JpdHkgSSBrbm93DQo+ID4+IHdoZXJl IHRoZSByZWd1bGF0b3IgaGFzIGluc2lzdGVkIG9uIHNpbWxlc3MgY2FsbGluZyB3YW50cyBpdA0K PiA+PiByZXBlYWxlZC4gIFRoZXJlIGlzIG9uZSBjb3VudGVyIGV4YW1wbGUgSSBrbm93IHdoZXJl IHRoZSBmYWN0DQo+ID4+IHRoYXQgdGhleSBnb3QgYSBjb3VwbGUsIGxpdGVyYWxseSwgb2YgZ29v ZCBjYWxscyBhbW9uZyB0aGUNCj4gPj4gdGVucyBvZiB0aG91c2FuZHMgb2YgYmFkIGNhbGxzIHdh cyBjb25zaWRlcmVkIGVub3VnaCByZWFzb24gdG8NCj4gPj4gcHV0IHVwIHdpdGggdGhlIHByb2Js ZW0uDQo+ID4+DQo+ID4+IFNlcnZpY2UgcHJvdmlkZXJzIGdpdmUgdXMgaW5mb3JtYXRpb24gdGhh dCBtYXkgYmUgdXNlZnVsOiBhDQo+ID4+IHN1YnNjcmliZXIgbmFtZSBhbmQgYWRkcmVzcyBmb3Ig ZXhhbXBsZSwgd2hpY2ggaXMgbm90DQo+ID4+IHNwb29mYWJsZSBieSB0aGUgY2FsbGVyLiAgVGhl eSBoYXZlIHdheXMgdG8gdHJhY2UgY2FsbGVycywNCj4gPj4gZXNwZWNpYWxseSBiYWQgY2FsbGVy cy4gIFRoZXkgZG9uJ3Qgd2FudCB0aGVpciBzeXN0ZW1zIGFidXNlZA0KPiA+PiBhbnkgbW9yZSB0 aGFuIHRoZSBlbWVyZ2VuY3kgY2FsbGluZyBhdXRob3JpdGllcyBkby4NCj4gPj4NCj4gPj4gVGhp cyBpcyBhIGJhZCBpZGVhLiAgQSB2ZXJ5IGJhZCBpZGVhLiAgUGxlYXNlIHN0b3AgaXQuDQo+ID4+ DQo+ID4+IFNvbWVkYXksIHdlIG1heSBoYXZlIGJldHRlciB3YXlzIHRvIHByZXZlbnQgYWJ1c2Uu IFVudGlsIHdlDQo+ID4+IGRvLCBzZXJ2aWNlIHByb3ZpZGVycyBhcmUgYSBnb29kIHRoaW5nIG9u IGFuIGVtZXJnZW5jeSBjYWxsLg0KPiA+PiBXZSBkb24ndCB3YW50IHRoZW0gY3V0IG91dC4NCj4g Pj4NCj4gPj4gQnJpYW4NCj4gPj4NCj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPj4gR2VvcHJpdiBtYWlsaW5nIGxpc3QNCj4gPj4gR2VvcHJp dkBpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2dl b3ByaXYNCj4gPj4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+ID4gRWNyaXQgbWFpbGluZyBsaXN0DQo+ID4gRWNyaXRAaWV0Zi5vcmcN Cj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+ID4NCj4g PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IEVj cml0IG1haWxpbmcgbGlzdA0KPiA+IEVjcml0QGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEVjcml0IG1haWxpbmcgbGlzdA0KPiBF Y3JpdEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vj cml0DQoNCg== From hgs@cs.columbia.edu Mon Oct 26 19:08:04 2009 Return-Path: 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 040CE3A6947 for ; Mon, 26 Oct 2009 19:08:04 -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 QZ+dxmJbiFOn for ; Mon, 26 Oct 2009 19:08:03 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 255FB3A6824 for ; Mon, 26 Oct 2009 19:08:03 -0700 (PDT) Received: from new-host.home (pool-71-187-38-54.nwrknj.fios.verizon.net [71.187.38.54]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id n9R28Ce1012665 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 26 Oct 2009 22:08:13 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Henning Schulzrinne In-Reply-To: <8B0A9FCBB9832F43971E38010638454F0F1EA6DC@SISPE7MB1.commscope.com> Date: Mon, 26 Oct 2009 22:08:11 -0400 Content-Transfer-Encoding: 7bit Message-Id: <6FC91F89-D84D-432C-A9B1-CC5D04C10C29@cs.columbia.edu> References: <087901ca5682$93adf970$03ffa8c0@nsnintra.net> <8B0A9FCBB9832F43971E38010638454F0F1EA6DC@SISPE7MB1.commscope.com> To: "Dawson, Martin" X-Mailer: Apple Mail (2.1076) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.6 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Tue, 27 Oct 2009 02:08:04 -0000 On Oct 26, 2009, at 7:56 PM, Dawson, Martin wrote: > > It can't be helped if you have over sold the benefits of VSP > involvement to yourself and others Brian. It is time to have a > reasoned debate. From my perspective, the argument that there is no > "subscription" involved is patently false. There has to be a > subscription of some description in order to get to the Internet. > Yes, there is free public Internet access (just as there are free > courtesy phones on the PSTN and free access to emergency services > from pay phones. All these services are still connected to the > public Internet infrastructure and they all represent an "operator" > with some level of information about the caller. Without weighing in on the rest of the discussion, that level can be pretty minimal. Columbia University allows anybody to use the 802.11 service, without authentication, as does Panera Bread and any number of non-chain cafes. Thus, we should be careful to distinguish knowledge of the caller's location from that of his or her identity. As noted, this is essentially like a pay phone. Henning From Martin.Dawson@andrew.com Mon Oct 26 19:12:50 2009 Return-Path: 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 6536F3A6947 for ; Mon, 26 Oct 2009 19:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 3mQZ7-K+YQN8 for ; Mon, 26 Oct 2009 19:12:49 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.243]) by core3.amsl.com (Postfix) with ESMTP id 830DF3A6824 for ; Mon, 26 Oct 2009 19:12:49 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:59728 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S4801000AbZJ0CND convert rfc822-to-8bit (ORCPT ); Mon, 26 Oct 2009 21:13:03 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Mon, 26 Oct 2009 21:13:03 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Tue, 27 Oct 2009 10:12:12 +0800 From: "Dawson, Martin" To: Henning Schulzrinne Date: Tue, 27 Oct 2009 10:12:11 +0800 Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpWqllXfGmy+N5URC+UlkQLxexdMQAAGv3Q Message-ID: <8B0A9FCBB9832F43971E38010638454F0F1EA753@SISPE7MB1.commscope.com> References: <087901ca5682$93adf970$03ffa8c0@nsnintra.net> <8B0A9FCBB9832F43971E38010638454F0F1EA6DC@SISPE7MB1.commscope.com> <6FC91F89-D84D-432C-A9B1-CC5D04C10C29@cs.columbia.edu> In-Reply-To: <6FC91F89-D84D-432C-A9B1-CC5D04C10C29@cs.columbia.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Dawson@andrew.com Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Tue, 27 Oct 2009 02:12:50 -0000 And - of course - anybody can make a 9-1-1 call from a phone on the campus. Nothing changes just because it's IP as opposed to circuits. Cheers, Martin -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Tuesday, 27 October 2009 1:08 PM To: Dawson, Martin Cc: Hannes Tschofenig; ecrit@ietf.org Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered On Oct 26, 2009, at 7:56 PM, Dawson, Martin wrote: > > It can't be helped if you have over sold the benefits of VSP > involvement to yourself and others Brian. It is time to have a > reasoned debate. From my perspective, the argument that there is no > "subscription" involved is patently false. There has to be a > subscription of some description in order to get to the Internet. > Yes, there is free public Internet access (just as there are free > courtesy phones on the PSTN and free access to emergency services > from pay phones. All these services are still connected to the > public Internet infrastructure and they all represent an "operator" > with some level of information about the caller. Without weighing in on the rest of the discussion, that level can be pretty minimal. Columbia University allows anybody to use the 802.11 service, without authentication, as does Panera Bread and any number of non-chain cafes. Thus, we should be careful to distinguish knowledge of the caller's location from that of his or her identity. As noted, this is essentially like a pay phone. Henning From mlinsner@cisco.com Tue Oct 27 06:02:36 2009 Return-Path: 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 540D13A6864 for ; Tue, 27 Oct 2009 06:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.424 X-Spam-Level: X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 LmjkCdoZoA+R for ; Tue, 27 Oct 2009 06:02:34 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 8530D3A6828 for ; Tue, 27 Oct 2009 06:02:34 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGSM5kpAZnwN/2dsb2JhbADAY5g2gjoGgX8Ei2E X-IronPort-AV: E=Sophos;i="4.44,633,1249257600"; d="scan'208";a="65118843" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 27 Oct 2009 13:02:48 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9RD2m63029790; Tue, 27 Oct 2009 13:02:48 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 09:02:48 -0400 Received: from [10.116.195.121] ([10.116.195.121]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 09:02:46 -0400 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 27 Oct 2009 09:02:44 -0400 From: Marc Linsner To: Brian Rosen , "ecrit@ietf.org" Message-ID: Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpWgLxkSiEL2R0NsU6jGpn0Z/MHbAAAcM9wAARjeVAAAyhOFAAZRcrD In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 27 Oct 2009 13:02:46.0987 (UTC) FILETIME=[C7ABF9B0:01CA5705] Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Tue, 27 Oct 2009 13:02:36 -0000 Brian, I'm a little confused. I don't remember you objecting to requirement RE1 from RFC5012 and I remember your use case about a Sierra Leone VSP. Are you implying that *all* VSPs will have a trust relationships with *all* PSAPs? What is the difference between a call coming from a private/individual domain (as in not a commercial VSP) and a VSP on the other side of the world (outside the jurisdiction)? I'm trying to figure out whether you're objecting to anonymous calls to the PSAP or the mechanisms proposed in this draft? [Don't take this as my endorsement of the draft, as I'm not sure I agree with UAs registering with the ESRP.] -Marc- On 10/26/09 8:59 PM, "Brian Rosen" wrote: > First of all, I put it on the wrong email list, sorry about that. > > Then, we have carefully arranged it so that there is no identity coming from > the access network provider, and because the location is coming from that > provider, we really don't want to. But even if we did, we would need a > really good identifier, and there isn't one. > > The problem we have with -direct is anonymous callers, and if they have any > option, they would also be location-less. Until and unless we get rid of > anonymity, we can't encourage service provider-less calls. The draft does > not make any provision to provide any kind of identity. Many networks > (think free wifi for example) would make providing good identity difficult. > > The fact is that there is a SERVICE provider in nearly all of the > communications systems. The SERVICE provider is in a position to assist > the emergency calling system when it needs more information. That's what a > good SERVICE provider does. Cutting them out is not a great idea. Most of > the attempts to provide real time communications between people have evolved > to using service providers, even when there were alternatives. File > transfer via something like Torrent is a counterexample (which isn't real > time), but even there, you end up with service providers like The Pirate Bay > (R.I.P) to provide introduction services. I don't think we're going to see > changes that eliminate service providers, and in this case, they provide > value to the emergency calling systems. All of the emergency professionals > I know have issues with service providers, but they would react with horror > if you suggested cutting them out. Ask them, please. > > So, I claim you have a solution in search of a problem. We have solved the > "calling network isn't the access network" problem already. Service > providers ARE in the path now, in nearly every case (in fact a counter > example escapes me, although there probably are some). There is no movement > I can detect which would change that any time soon; quite the opposite. We > have a known killer problem without some kind of subscription to a service > that provides a good identity, for which you provide no answers. We have > experience with the killer problem: sim-less calling was supposed to provide > a way to make an emergency call in exactly the kinds of circumstances you > are describing. Our real world experience is that you create a huge problem > that diverts resources from helping people to chasing scammers and > flea-market sellers. > > Nothing is perfect: you can get a AIM screen name without a very good > identity for example. However, the notion that we're going to provide > direct access without a service provider deliberately, especially without > really good identity from the access network is, in my opinion not only a > no, it's a heck no. I'll line up as many emergency service professionals as > you would like to tell you this is a harmful idea. > > > > > > > On 10/26/09 7:56 PM, "Dawson, Martin" wrote: > >> I am glad this has come up. It's a debate that has to happen if we are to >> move >> beyond a long standing legacy misconception. >> >> In the circuit service world - whether it was POTS or mobile, the access >> network had full responsibility for delivering the emergency call. In that >> world, routing an emergency call meant getting a circuit established to the >> correct call center. In most parts of the world, this was done using the >> regional part of the PSTN to switch the circuit to a call center on the PSTN. >> In some jurisdictions, such as the US, it was done directly from the local >> exchange carrier to the call center. Either way, there was no third party >> involved. >> >> Now we have the Internet. We still have public access network providers. They >> switch packets onto the Internet for their subscribers. They can similarly >> ensure that packets reach the local emergency call centers. >> >> The fact is that there was no equivalent of a VSP in the traditional >> environment. VoIP is a presence service, and it had no common equivalent in >> the PSTN world. It could have, but the narrowband state of technology and the >> common market use cases didn't support its development. By the time ISDN >> arrived, the PSTN had already slipped into its palliative stage without >> realizing it. >> >> It's an entrenched misconception that because the circuit service provided by >> exchange carriers was most commonly used for "voice" (but, it should be >> noted, >> also for fax, telex, tty, security system monitoring and, even, IP data) that >> VSPs are somehow equivalent to exchange carriers. They are not. >> >> Indeed, involving VSPs in emergency calls is the Internet equivalent of >> involving long distance providers in POTS emergency calls. They are neither >> necessary nor particularly helpful; they can't be guaranteed to be within the >> emergency jurisdiction; depending on them actually diminishes the efficacy of >> emergency service access. It does not help the caller, the emergency service, >> nor the third party to insist on the third party's involvement. >> >> It can't be helped if you have over sold the benefits of VSP involvement to >> yourself and others Brian. It is time to have a reasoned debate. From my >> perspective, the argument that there is no "subscription" involved is >> patently >> false. There has to be a subscription of some description in order to get to >> the Internet. Yes, there is free public Internet access (just as there are >> free courtesy phones on the PSTN and free access to emergency services from >> pay phones. All these services are still connected to the public Internet >> infrastructure and they all represent an "operator" with some level of >> information about the caller. >> >> With the over-emphasis on VSPs, what is missing from the ECRIT and i3 models >> is the direct interface for querying the access network for subscriber data >> (should it prove necessary). These models need to take the long view of how >> emergency calling is done in the Internet age; they should not be protracting >> an unnecessary reliance on VSPs. >> >> I have deleted the premature and prejudicial text from the subject heading. >> And I'll leave this on ECRIT as the most appropriate WG. >> >> Cheers, >> Martin >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >> Hannes Tschofenig >> Sent: Tuesday, 27 October 2009 8:23 AM >> To: ecrit@ietf.org >> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered harmful, >> at least given our current experiences >> >> FYI: feedback from Brian regarding a recent ECRIT contribution. >> >>> -----Original Message----- >>> From: geopriv-bounces@ietf.org >>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian >>> Sent: 26 October, 2009 23:10 >>> To: geopriv@ietf.org >>> Subject: [Geopriv] Winterbottom-ecrit-direct considered >>> harmful, at least given our current experiences >>> >>> The notion behind -direct is to not use a service provider to >>> place an emergency call. Instead, the device registers with >>> an Emergency Services Routing Proxy immediately before the >>> call and the call is routed directly from the device to the ESRP. >>> >>> At least at the moment, this is an exceedingly bad idea. >>> >>> Emergency calling authorities like service providers, a lot. >>> They like them because they can hold them accountable, and the >>> service providers don't like theft of service, which is >>> something the emergency call guys have an analog to. >>> >>> The facts are that where unaccountable access to emergency >>> calling is allowed, huge numbers of false calls occur, with no >>> way to stop them, and no way to tell the good ones from the >>> bad ones. This has been seen multiple times where so called >>> "simless" or "unauthenticated" calls are allowed. >>> >>> -direct precisely duplicates simless calling. The only >>> "registration" is an emergency registration, only emergency >>> calls are allowed, any device can make an emergency call if >>> all it has is a (radio) connection to any network. >>> We can predict, with a very high degree of certainty, that the >>> feature will be horribly abused: for example to test that a >>> phone without a service plan works. >>> >>> There have been studies which show tens of thousands of bad >>> calls with zero good ones. Nearly every authority I know >>> where the regulator has insisted on simless calling wants it >>> repealed. There is one counter example I know where the fact >>> that they got a couple, literally, of good calls among the >>> tens of thousands of bad calls was considered enough reason to >>> put up with the problem. >>> >>> Service providers give us information that may be useful: a >>> subscriber name and address for example, which is not >>> spoofable by the caller. They have ways to trace callers, >>> especially bad callers. They don't want their systems abused >>> any more than the emergency calling authorities do. >>> >>> This is a bad idea. A very bad idea. Please stop it. >>> >>> Someday, we may have better ways to prevent abuse. Until we >>> do, service providers are a good thing on an emergency call. >>> We don't want them cut out. >>> >>> Brian >>> >>> _______________________________________________ >>> Geopriv mailing list >>> Geopriv@ietf.org >>> https://www.ietf.org/mailman/listinfo/geopriv >>> >> >> _______________________________________________ >> 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 br@brianrosen.net Tue Oct 27 07:31:57 2009 Return-Path: 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 CD1CA3A6859 for ; Tue, 27 Oct 2009 07:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=0.362, 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 jRcfN4281vBa for ; Tue, 27 Oct 2009 07:31:56 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id CA9D33A6A16 for ; Tue, 27 Oct 2009 07:31:50 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.216]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1N2n5Z-0000dt-9A; Tue, 27 Oct 2009 09:31:57 -0500 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 27 Oct 2009 10:31:57 -0400 From: Brian Rosen To: Marc Linsner , "ecrit@ietf.org" Message-ID: Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpWgLxkSiEL2R0NsU6jGpn0Z/MHbAAAcM9wAARjeVAAAyhOFAAZRcrDAAMdqDA= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Tue, 27 Oct 2009 14:31:57 -0000 Of course not all VSPs will have trust relationships with all PSAPs. One can hope that long term, we can evolve to transitive trust relationships that work pretty well cross border. The emergency guys are actually terrified of private/individual domains sending them calls, and we're telling them we expect that to be possible, but rare, and we're giving them mechanisms that will effectively allow them to turn off calls selectively, based on factors including what domain the call comes from. They expect that such calls will be one of the loopholes where they get equivalents to sim-less calls, which drive them nuts. They don't want ANY calls that don't come from service providers, although they seem to be okay with the notion that the SP may not have great identity (AOL being a poster child). So, while indeed they understand, and have concerns about having to take calls from Sierra Leone VoIP services Pty, they would much rather have a call that went through them then a call that went through no service provider at all. I'm not trying to make calls direct from devices or private domains impossible, but I think the notion that we're promoting them is a very bad idea until we have effective mechanisms to prevent abuse. Brian On 10/27/09 9:02 AM, "Marc Linsner" wrote: > Brian, > > I'm a little confused. I don't remember you objecting to requirement RE1 > from RFC5012 and I remember your use case about a Sierra Leone VSP. > > Are you implying that *all* VSPs will have a trust relationships with *all* > PSAPs? > > What is the difference between a call coming from a private/individual > domain (as in not a commercial VSP) and a VSP on the other side of the world > (outside the jurisdiction)? > > I'm trying to figure out whether you're objecting to anonymous calls to the > PSAP or the mechanisms proposed in this draft? > > [Don't take this as my endorsement of the draft, as I'm not sure I agree > with UAs registering with the ESRP.] > > -Marc- > > > On 10/26/09 8:59 PM, "Brian Rosen" wrote: > >> First of all, I put it on the wrong email list, sorry about that. >> >> Then, we have carefully arranged it so that there is no identity coming from >> the access network provider, and because the location is coming from that >> provider, we really don't want to. But even if we did, we would need a >> really good identifier, and there isn't one. >> >> The problem we have with -direct is anonymous callers, and if they have any >> option, they would also be location-less. Until and unless we get rid of >> anonymity, we can't encourage service provider-less calls. The draft does >> not make any provision to provide any kind of identity. Many networks >> (think free wifi for example) would make providing good identity difficult. >> >> The fact is that there is a SERVICE provider in nearly all of the >> communications systems. The SERVICE provider is in a position to assist >> the emergency calling system when it needs more information. That's what a >> good SERVICE provider does. Cutting them out is not a great idea. Most of >> the attempts to provide real time communications between people have evolved >> to using service providers, even when there were alternatives. File >> transfer via something like Torrent is a counterexample (which isn't real >> time), but even there, you end up with service providers like The Pirate Bay >> (R.I.P) to provide introduction services. I don't think we're going to see >> changes that eliminate service providers, and in this case, they provide >> value to the emergency calling systems. All of the emergency professionals >> I know have issues with service providers, but they would react with horror >> if you suggested cutting them out. Ask them, please. >> >> So, I claim you have a solution in search of a problem. We have solved the >> "calling network isn't the access network" problem already. Service >> providers ARE in the path now, in nearly every case (in fact a counter >> example escapes me, although there probably are some). There is no movement >> I can detect which would change that any time soon; quite the opposite. We >> have a known killer problem without some kind of subscription to a service >> that provides a good identity, for which you provide no answers. We have >> experience with the killer problem: sim-less calling was supposed to provide >> a way to make an emergency call in exactly the kinds of circumstances you >> are describing. Our real world experience is that you create a huge problem >> that diverts resources from helping people to chasing scammers and >> flea-market sellers. >> >> Nothing is perfect: you can get a AIM screen name without a very good >> identity for example. However, the notion that we're going to provide >> direct access without a service provider deliberately, especially without >> really good identity from the access network is, in my opinion not only a >> no, it's a heck no. I'll line up as many emergency service professionals as >> you would like to tell you this is a harmful idea. >> >> >> >> >> >> >> On 10/26/09 7:56 PM, "Dawson, Martin" wrote: >> >>> I am glad this has come up. It's a debate that has to happen if we are to >>> move >>> beyond a long standing legacy misconception. >>> >>> In the circuit service world - whether it was POTS or mobile, the access >>> network had full responsibility for delivering the emergency call. In that >>> world, routing an emergency call meant getting a circuit established to the >>> correct call center. In most parts of the world, this was done using the >>> regional part of the PSTN to switch the circuit to a call center on the >>> PSTN. >>> In some jurisdictions, such as the US, it was done directly from the local >>> exchange carrier to the call center. Either way, there was no third party >>> involved. >>> >>> Now we have the Internet. We still have public access network providers. >>> They >>> switch packets onto the Internet for their subscribers. They can similarly >>> ensure that packets reach the local emergency call centers. >>> >>> The fact is that there was no equivalent of a VSP in the traditional >>> environment. VoIP is a presence service, and it had no common equivalent in >>> the PSTN world. It could have, but the narrowband state of technology and >>> the >>> common market use cases didn't support its development. By the time ISDN >>> arrived, the PSTN had already slipped into its palliative stage without >>> realizing it. >>> >>> It's an entrenched misconception that because the circuit service provided >>> by >>> exchange carriers was most commonly used for "voice" (but, it should be >>> noted, >>> also for fax, telex, tty, security system monitoring and, even, IP data) >>> that >>> VSPs are somehow equivalent to exchange carriers. They are not. >>> >>> Indeed, involving VSPs in emergency calls is the Internet equivalent of >>> involving long distance providers in POTS emergency calls. They are neither >>> necessary nor particularly helpful; they can't be guaranteed to be within >>> the >>> emergency jurisdiction; depending on them actually diminishes the efficacy >>> of >>> emergency service access. It does not help the caller, the emergency >>> service, >>> nor the third party to insist on the third party's involvement. >>> >>> It can't be helped if you have over sold the benefits of VSP involvement to >>> yourself and others Brian. It is time to have a reasoned debate. From my >>> perspective, the argument that there is no "subscription" involved is >>> patently >>> false. There has to be a subscription of some description in order to get to >>> the Internet. Yes, there is free public Internet access (just as there are >>> free courtesy phones on the PSTN and free access to emergency services from >>> pay phones. All these services are still connected to the public Internet >>> infrastructure and they all represent an "operator" with some level of >>> information about the caller. >>> >>> With the over-emphasis on VSPs, what is missing from the ECRIT and i3 models >>> is the direct interface for querying the access network for subscriber data >>> (should it prove necessary). These models need to take the long view of how >>> emergency calling is done in the Internet age; they should not be >>> protracting >>> an unnecessary reliance on VSPs. >>> >>> I have deleted the premature and prejudicial text from the subject heading. >>> And I'll leave this on ECRIT as the most appropriate WG. >>> >>> Cheers, >>> Martin >>> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >>> Hannes Tschofenig >>> Sent: Tuesday, 27 October 2009 8:23 AM >>> To: ecrit@ietf.org >>> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered harmful, >>> at least given our current experiences >>> >>> FYI: feedback from Brian regarding a recent ECRIT contribution. >>> >>>> -----Original Message----- >>>> From: geopriv-bounces@ietf.org >>>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian >>>> Sent: 26 October, 2009 23:10 >>>> To: geopriv@ietf.org >>>> Subject: [Geopriv] Winterbottom-ecrit-direct considered >>>> harmful, at least given our current experiences >>>> >>>> The notion behind -direct is to not use a service provider to >>>> place an emergency call. Instead, the device registers with >>>> an Emergency Services Routing Proxy immediately before the >>>> call and the call is routed directly from the device to the ESRP. >>>> >>>> At least at the moment, this is an exceedingly bad idea. >>>> >>>> Emergency calling authorities like service providers, a lot. >>>> They like them because they can hold them accountable, and the >>>> service providers don't like theft of service, which is >>>> something the emergency call guys have an analog to. >>>> >>>> The facts are that where unaccountable access to emergency >>>> calling is allowed, huge numbers of false calls occur, with no >>>> way to stop them, and no way to tell the good ones from the >>>> bad ones. This has been seen multiple times where so called >>>> "simless" or "unauthenticated" calls are allowed. >>>> >>>> -direct precisely duplicates simless calling. The only >>>> "registration" is an emergency registration, only emergency >>>> calls are allowed, any device can make an emergency call if >>>> all it has is a (radio) connection to any network. >>>> We can predict, with a very high degree of certainty, that the >>>> feature will be horribly abused: for example to test that a >>>> phone without a service plan works. >>>> >>>> There have been studies which show tens of thousands of bad >>>> calls with zero good ones. Nearly every authority I know >>>> where the regulator has insisted on simless calling wants it >>>> repealed. There is one counter example I know where the fact >>>> that they got a couple, literally, of good calls among the >>>> tens of thousands of bad calls was considered enough reason to >>>> put up with the problem. >>>> >>>> Service providers give us information that may be useful: a >>>> subscriber name and address for example, which is not >>>> spoofable by the caller. They have ways to trace callers, >>>> especially bad callers. They don't want their systems abused >>>> any more than the emergency calling authorities do. >>>> >>>> This is a bad idea. A very bad idea. Please stop it. >>>> >>>> Someday, we may have better ways to prevent abuse. Until we >>>> do, service providers are a good thing on an emergency call. >>>> We don't want them cut out. >>>> >>>> Brian >>>> >>>> _______________________________________________ >>>> Geopriv mailing list >>>> Geopriv@ietf.org >>>> https://www.ietf.org/mailman/listinfo/geopriv >>>> >>> >>> _______________________________________________ >>> 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 rbarnes@bbn.com Tue Oct 27 07:39:20 2009 Return-Path: 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 4FBD628C1EE for ; Tue, 27 Oct 2009 07:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 4Xf18pDrglB5 for ; Tue, 27 Oct 2009 07:39:18 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 5A0B528C0D6 for ; Tue, 27 Oct 2009 07:39:18 -0700 (PDT) Received: from [128.89.255.96] (helo=[77.42.251.146]) by mx3.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1N2nCs-0002Aw-Ct; Tue, 27 Oct 2009 10:39:31 -0400 Message-Id: <273B7AE8-679E-482F-9802-48668CB24552@bbn.com> From: Richard Barnes To: Brian Rosen In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 27 Oct 2009 16:39:28 +0200 References: X-Mailer: Apple Mail (2.936) Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Tue, 27 Oct 2009 14:39:20 -0000 Brian, Is the security goal here more access control (i.e., controlling who can send calls to a PSAP) or attribution/identification for post-hoc action. If it's the latter, then ISTM that the problem can largely be reduced to having a certificate infrastructure that binds authenticated identities to real-world entities. The "extended validation" certificates that current commercial CAs issue seem to largely satisfy this requirement. --Richard On Oct 27, 2009, at 4:31 PM, Brian Rosen wrote: > Of course not all VSPs will have trust relationships with all > PSAPs. One > can hope that long term, we can evolve to transitive trust > relationships > that work pretty well cross border. > > The emergency guys are actually terrified of private/individual > domains > sending them calls, and we're telling them we expect that to be > possible, > but rare, and we're giving them mechanisms that will effectively > allow them > to turn off calls selectively, based on factors including what > domain the > call comes from. They expect that such calls will be one of the > loopholes > where they get equivalents to sim-less calls, which drive them > nuts. They > don't want ANY calls that don't come from service providers, > although they > seem to be okay with the notion that the SP may not have great > identity (AOL > being a poster child). So, while indeed they understand, and have > concerns > about having to take calls from Sierra Leone VoIP services Pty, they > would > much rather have a call that went through them then a call that went > through > no service provider at all. > > I'm not trying to make calls direct from devices or private domains > impossible, but I think the notion that we're promoting them is a > very bad > idea until we have effective mechanisms to prevent abuse. > > Brian > > > > > On 10/27/09 9:02 AM, "Marc Linsner" wrote: > >> Brian, >> >> I'm a little confused. I don't remember you objecting to >> requirement RE1 >> from RFC5012 and I remember your use case about a Sierra Leone VSP. >> >> Are you implying that *all* VSPs will have a trust relationships >> with *all* >> PSAPs? >> >> What is the difference between a call coming from a private/ >> individual >> domain (as in not a commercial VSP) and a VSP on the other side of >> the world >> (outside the jurisdiction)? >> >> I'm trying to figure out whether you're objecting to anonymous >> calls to the >> PSAP or the mechanisms proposed in this draft? >> >> [Don't take this as my endorsement of the draft, as I'm not sure I >> agree >> with UAs registering with the ESRP.] >> >> -Marc- >> >> >> On 10/26/09 8:59 PM, "Brian Rosen" wrote: >> >>> First of all, I put it on the wrong email list, sorry about that. >>> >>> Then, we have carefully arranged it so that there is no identity >>> coming from >>> the access network provider, and because the location is coming >>> from that >>> provider, we really don't want to. But even if we did, we would >>> need a >>> really good identifier, and there isn't one. >>> >>> The problem we have with -direct is anonymous callers, and if they >>> have any >>> option, they would also be location-less. Until and unless we get >>> rid of >>> anonymity, we can't encourage service provider-less calls. The >>> draft does >>> not make any provision to provide any kind of identity. Many >>> networks >>> (think free wifi for example) would make providing good identity >>> difficult. >>> >>> The fact is that there is a SERVICE provider in nearly all of the >>> communications systems. The SERVICE provider is in a position to >>> assist >>> the emergency calling system when it needs more information. >>> That's what a >>> good SERVICE provider does. Cutting them out is not a great >>> idea. Most of >>> the attempts to provide real time communications between people >>> have evolved >>> to using service providers, even when there were alternatives. File >>> transfer via something like Torrent is a counterexample (which >>> isn't real >>> time), but even there, you end up with service providers like The >>> Pirate Bay >>> (R.I.P) to provide introduction services. I don't think we're >>> going to see >>> changes that eliminate service providers, and in this case, they >>> provide >>> value to the emergency calling systems. All of the emergency >>> professionals >>> I know have issues with service providers, but they would react >>> with horror >>> if you suggested cutting them out. Ask them, please. >>> >>> So, I claim you have a solution in search of a problem. We have >>> solved the >>> "calling network isn't the access network" problem already. Service >>> providers ARE in the path now, in nearly every case (in fact a >>> counter >>> example escapes me, although there probably are some). There is >>> no movement >>> I can detect which would change that any time soon; quite the >>> opposite. We >>> have a known killer problem without some kind of subscription to a >>> service >>> that provides a good identity, for which you provide no answers. >>> We have >>> experience with the killer problem: sim-less calling was supposed >>> to provide >>> a way to make an emergency call in exactly the kinds of >>> circumstances you >>> are describing. Our real world experience is that you create a >>> huge problem >>> that diverts resources from helping people to chasing scammers and >>> flea-market sellers. >>> >>> Nothing is perfect: you can get a AIM screen name without a very >>> good >>> identity for example. However, the notion that we're going to >>> provide >>> direct access without a service provider deliberately, especially >>> without >>> really good identity from the access network is, in my opinion not >>> only a >>> no, it's a heck no. I'll line up as many emergency service >>> professionals as >>> you would like to tell you this is a harmful idea. >>> >>> >>> >>> >>> >>> >>> On 10/26/09 7:56 PM, "Dawson, Martin" >>> wrote: >>> >>>> I am glad this has come up. It's a debate that has to happen if >>>> we are to >>>> move >>>> beyond a long standing legacy misconception. >>>> >>>> In the circuit service world - whether it was POTS or mobile, the >>>> access >>>> network had full responsibility for delivering the emergency >>>> call. In that >>>> world, routing an emergency call meant getting a circuit >>>> established to the >>>> correct call center. In most parts of the world, this was done >>>> using the >>>> regional part of the PSTN to switch the circuit to a call center >>>> on the >>>> PSTN. >>>> In some jurisdictions, such as the US, it was done directly from >>>> the local >>>> exchange carrier to the call center. Either way, there was no >>>> third party >>>> involved. >>>> >>>> Now we have the Internet. We still have public access network >>>> providers. >>>> They >>>> switch packets onto the Internet for their subscribers. They can >>>> similarly >>>> ensure that packets reach the local emergency call centers. >>>> >>>> The fact is that there was no equivalent of a VSP in the >>>> traditional >>>> environment. VoIP is a presence service, and it had no common >>>> equivalent in >>>> the PSTN world. It could have, but the narrowband state of >>>> technology and >>>> the >>>> common market use cases didn't support its development. By the >>>> time ISDN >>>> arrived, the PSTN had already slipped into its palliative stage >>>> without >>>> realizing it. >>>> >>>> It's an entrenched misconception that because the circuit service >>>> provided >>>> by >>>> exchange carriers was most commonly used for "voice" (but, it >>>> should be >>>> noted, >>>> also for fax, telex, tty, security system monitoring and, even, >>>> IP data) >>>> that >>>> VSPs are somehow equivalent to exchange carriers. They are not. >>>> >>>> Indeed, involving VSPs in emergency calls is the Internet >>>> equivalent of >>>> involving long distance providers in POTS emergency calls. They >>>> are neither >>>> necessary nor particularly helpful; they can't be guaranteed to >>>> be within >>>> the >>>> emergency jurisdiction; depending on them actually diminishes the >>>> efficacy >>>> of >>>> emergency service access. It does not help the caller, the >>>> emergency >>>> service, >>>> nor the third party to insist on the third party's involvement. >>>> >>>> It can't be helped if you have over sold the benefits of VSP >>>> involvement to >>>> yourself and others Brian. It is time to have a reasoned debate. >>>> From my >>>> perspective, the argument that there is no "subscription" >>>> involved is >>>> patently >>>> false. There has to be a subscription of some description in >>>> order to get to >>>> the Internet. Yes, there is free public Internet access (just as >>>> there are >>>> free courtesy phones on the PSTN and free access to emergency >>>> services from >>>> pay phones. All these services are still connected to the public >>>> Internet >>>> infrastructure and they all represent an "operator" with some >>>> level of >>>> information about the caller. >>>> >>>> With the over-emphasis on VSPs, what is missing from the ECRIT >>>> and i3 models >>>> is the direct interface for querying the access network for >>>> subscriber data >>>> (should it prove necessary). These models need to take the long >>>> view of how >>>> emergency calling is done in the Internet age; they should not be >>>> protracting >>>> an unnecessary reliance on VSPs. >>>> >>>> I have deleted the premature and prejudicial text from the >>>> subject heading. >>>> And I'll leave this on ECRIT as the most appropriate WG. >>>> >>>> Cheers, >>>> Martin >>>> >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>> Behalf Of >>>> Hannes Tschofenig >>>> Sent: Tuesday, 27 October 2009 8:23 AM >>>> To: ecrit@ietf.org >>>> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>> considered harmful, >>>> at least given our current experiences >>>> >>>> FYI: feedback from Brian regarding a recent ECRIT contribution. >>>> >>>>> -----Original Message----- >>>>> From: geopriv-bounces@ietf.org >>>>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian >>>>> Sent: 26 October, 2009 23:10 >>>>> To: geopriv@ietf.org >>>>> Subject: [Geopriv] Winterbottom-ecrit-direct considered >>>>> harmful, at least given our current experiences >>>>> >>>>> The notion behind -direct is to not use a service provider to >>>>> place an emergency call. Instead, the device registers with >>>>> an Emergency Services Routing Proxy immediately before the >>>>> call and the call is routed directly from the device to the ESRP. >>>>> >>>>> At least at the moment, this is an exceedingly bad idea. >>>>> >>>>> Emergency calling authorities like service providers, a lot. >>>>> They like them because they can hold them accountable, and the >>>>> service providers don't like theft of service, which is >>>>> something the emergency call guys have an analog to. >>>>> >>>>> The facts are that where unaccountable access to emergency >>>>> calling is allowed, huge numbers of false calls occur, with no >>>>> way to stop them, and no way to tell the good ones from the >>>>> bad ones. This has been seen multiple times where so called >>>>> "simless" or "unauthenticated" calls are allowed. >>>>> >>>>> -direct precisely duplicates simless calling. The only >>>>> "registration" is an emergency registration, only emergency >>>>> calls are allowed, any device can make an emergency call if >>>>> all it has is a (radio) connection to any network. >>>>> We can predict, with a very high degree of certainty, that the >>>>> feature will be horribly abused: for example to test that a >>>>> phone without a service plan works. >>>>> >>>>> There have been studies which show tens of thousands of bad >>>>> calls with zero good ones. Nearly every authority I know >>>>> where the regulator has insisted on simless calling wants it >>>>> repealed. There is one counter example I know where the fact >>>>> that they got a couple, literally, of good calls among the >>>>> tens of thousands of bad calls was considered enough reason to >>>>> put up with the problem. >>>>> >>>>> Service providers give us information that may be useful: a >>>>> subscriber name and address for example, which is not >>>>> spoofable by the caller. They have ways to trace callers, >>>>> especially bad callers. They don't want their systems abused >>>>> any more than the emergency calling authorities do. >>>>> >>>>> This is a bad idea. A very bad idea. Please stop it. >>>>> >>>>> Someday, we may have better ways to prevent abuse. Until we >>>>> do, service providers are a good thing on an emergency call. >>>>> We don't want them cut out. >>>>> >>>>> Brian >>>>> >>>>> _______________________________________________ >>>>> Geopriv mailing list >>>>> Geopriv@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/geopriv >>>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From br@brianrosen.net Tue Oct 27 08:00:26 2009 Return-Path: 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 8C31A28C0EA for ; Tue, 27 Oct 2009 08:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=0.271, 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 sG5wP-8RnXsx for ; Tue, 27 Oct 2009 08:00:24 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id BD64C3A6986 for ; Tue, 27 Oct 2009 08:00:24 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.216]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1N2nXC-0002MY-2B; Tue, 27 Oct 2009 10:00:30 -0500 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 27 Oct 2009 11:00:24 -0400 From: Brian Rosen To: Richard Barnes Message-ID: Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmw== In-Reply-To: <273B7AE8-679E-482F-9802-48668CB24552@bbn.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Tue, 27 Oct 2009 15:00:26 -0000 The first goal is to prevent bad calls. The second goal is to indentify the source of the bad calls. I'm starting with the first goal. I don't want you to be able to take a device out of a box, plug it into a network, and have the only call you can make be an emergency call. I want the device to actually "work" (as in be able to place calls to all the entities that it was intended to) first, and then be able to place emergency calls. Please spend some time in a PSAP while a kid with a simless phone has "fun" with it. Imagine how much fun the test mechanism is as opposed to placing real calls. If we somehow get a bad call, we need to send the cops. That means we need an identity (and a location). I think a good cert could be the basis of a good identity, if we could get one. I don't see how we do that. Brian On 10/27/09 10:39 AM, "Richard Barnes" wrote: > Brian, > > Is the security goal here more access control (i.e., controlling who > can send calls to a PSAP) or attribution/identification for post-hoc > action. > > If it's the latter, then ISTM that the problem can largely be reduced > to having a certificate infrastructure that binds authenticated > identities to real-world entities. The "extended validation" > certificates that current commercial CAs issue seem to largely satisfy > this requirement. > > --Richard > > > On Oct 27, 2009, at 4:31 PM, Brian Rosen wrote: > >> Of course not all VSPs will have trust relationships with all >> PSAPs. One >> can hope that long term, we can evolve to transitive trust >> relationships >> that work pretty well cross border. >> >> The emergency guys are actually terrified of private/individual >> domains >> sending them calls, and we're telling them we expect that to be >> possible, >> but rare, and we're giving them mechanisms that will effectively >> allow them >> to turn off calls selectively, based on factors including what >> domain the >> call comes from. They expect that such calls will be one of the >> loopholes >> where they get equivalents to sim-less calls, which drive them >> nuts. They >> don't want ANY calls that don't come from service providers, >> although they >> seem to be okay with the notion that the SP may not have great >> identity (AOL >> being a poster child). So, while indeed they understand, and have >> concerns >> about having to take calls from Sierra Leone VoIP services Pty, they >> would >> much rather have a call that went through them then a call that went >> through >> no service provider at all. >> >> I'm not trying to make calls direct from devices or private domains >> impossible, but I think the notion that we're promoting them is a >> very bad >> idea until we have effective mechanisms to prevent abuse. >> >> Brian >> >> >> >> >> On 10/27/09 9:02 AM, "Marc Linsner" wrote: >> >>> Brian, >>> >>> I'm a little confused. I don't remember you objecting to >>> requirement RE1 >>> from RFC5012 and I remember your use case about a Sierra Leone VSP. >>> >>> Are you implying that *all* VSPs will have a trust relationships >>> with *all* >>> PSAPs? >>> >>> What is the difference between a call coming from a private/ >>> individual >>> domain (as in not a commercial VSP) and a VSP on the other side of >>> the world >>> (outside the jurisdiction)? >>> >>> I'm trying to figure out whether you're objecting to anonymous >>> calls to the >>> PSAP or the mechanisms proposed in this draft? >>> >>> [Don't take this as my endorsement of the draft, as I'm not sure I >>> agree >>> with UAs registering with the ESRP.] >>> >>> -Marc- >>> >>> >>> On 10/26/09 8:59 PM, "Brian Rosen" wrote: >>> >>>> First of all, I put it on the wrong email list, sorry about that. >>>> >>>> Then, we have carefully arranged it so that there is no identity >>>> coming from >>>> the access network provider, and because the location is coming >>>> from that >>>> provider, we really don't want to. But even if we did, we would >>>> need a >>>> really good identifier, and there isn't one. >>>> >>>> The problem we have with -direct is anonymous callers, and if they >>>> have any >>>> option, they would also be location-less. Until and unless we get >>>> rid of >>>> anonymity, we can't encourage service provider-less calls. The >>>> draft does >>>> not make any provision to provide any kind of identity. Many >>>> networks >>>> (think free wifi for example) would make providing good identity >>>> difficult. >>>> >>>> The fact is that there is a SERVICE provider in nearly all of the >>>> communications systems. The SERVICE provider is in a position to >>>> assist >>>> the emergency calling system when it needs more information. >>>> That's what a >>>> good SERVICE provider does. Cutting them out is not a great >>>> idea. Most of >>>> the attempts to provide real time communications between people >>>> have evolved >>>> to using service providers, even when there were alternatives. File >>>> transfer via something like Torrent is a counterexample (which >>>> isn't real >>>> time), but even there, you end up with service providers like The >>>> Pirate Bay >>>> (R.I.P) to provide introduction services. I don't think we're >>>> going to see >>>> changes that eliminate service providers, and in this case, they >>>> provide >>>> value to the emergency calling systems. All of the emergency >>>> professionals >>>> I know have issues with service providers, but they would react >>>> with horror >>>> if you suggested cutting them out. Ask them, please. >>>> >>>> So, I claim you have a solution in search of a problem. We have >>>> solved the >>>> "calling network isn't the access network" problem already. Service >>>> providers ARE in the path now, in nearly every case (in fact a >>>> counter >>>> example escapes me, although there probably are some). There is >>>> no movement >>>> I can detect which would change that any time soon; quite the >>>> opposite. We >>>> have a known killer problem without some kind of subscription to a >>>> service >>>> that provides a good identity, for which you provide no answers. >>>> We have >>>> experience with the killer problem: sim-less calling was supposed >>>> to provide >>>> a way to make an emergency call in exactly the kinds of >>>> circumstances you >>>> are describing. Our real world experience is that you create a >>>> huge problem >>>> that diverts resources from helping people to chasing scammers and >>>> flea-market sellers. >>>> >>>> Nothing is perfect: you can get a AIM screen name without a very >>>> good >>>> identity for example. However, the notion that we're going to >>>> provide >>>> direct access without a service provider deliberately, especially >>>> without >>>> really good identity from the access network is, in my opinion not >>>> only a >>>> no, it's a heck no. I'll line up as many emergency service >>>> professionals as >>>> you would like to tell you this is a harmful idea. >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 10/26/09 7:56 PM, "Dawson, Martin" >>>> wrote: >>>> >>>>> I am glad this has come up. It's a debate that has to happen if >>>>> we are to >>>>> move >>>>> beyond a long standing legacy misconception. >>>>> >>>>> In the circuit service world - whether it was POTS or mobile, the >>>>> access >>>>> network had full responsibility for delivering the emergency >>>>> call. In that >>>>> world, routing an emergency call meant getting a circuit >>>>> established to the >>>>> correct call center. In most parts of the world, this was done >>>>> using the >>>>> regional part of the PSTN to switch the circuit to a call center >>>>> on the >>>>> PSTN. >>>>> In some jurisdictions, such as the US, it was done directly from >>>>> the local >>>>> exchange carrier to the call center. Either way, there was no >>>>> third party >>>>> involved. >>>>> >>>>> Now we have the Internet. We still have public access network >>>>> providers. >>>>> They >>>>> switch packets onto the Internet for their subscribers. They can >>>>> similarly >>>>> ensure that packets reach the local emergency call centers. >>>>> >>>>> The fact is that there was no equivalent of a VSP in the >>>>> traditional >>>>> environment. VoIP is a presence service, and it had no common >>>>> equivalent in >>>>> the PSTN world. It could have, but the narrowband state of >>>>> technology and >>>>> the >>>>> common market use cases didn't support its development. By the >>>>> time ISDN >>>>> arrived, the PSTN had already slipped into its palliative stage >>>>> without >>>>> realizing it. >>>>> >>>>> It's an entrenched misconception that because the circuit service >>>>> provided >>>>> by >>>>> exchange carriers was most commonly used for "voice" (but, it >>>>> should be >>>>> noted, >>>>> also for fax, telex, tty, security system monitoring and, even, >>>>> IP data) >>>>> that >>>>> VSPs are somehow equivalent to exchange carriers. They are not. >>>>> >>>>> Indeed, involving VSPs in emergency calls is the Internet >>>>> equivalent of >>>>> involving long distance providers in POTS emergency calls. They >>>>> are neither >>>>> necessary nor particularly helpful; they can't be guaranteed to >>>>> be within >>>>> the >>>>> emergency jurisdiction; depending on them actually diminishes the >>>>> efficacy >>>>> of >>>>> emergency service access. It does not help the caller, the >>>>> emergency >>>>> service, >>>>> nor the third party to insist on the third party's involvement. >>>>> >>>>> It can't be helped if you have over sold the benefits of VSP >>>>> involvement to >>>>> yourself and others Brian. It is time to have a reasoned debate. >>>>> From my >>>>> perspective, the argument that there is no "subscription" >>>>> involved is >>>>> patently >>>>> false. There has to be a subscription of some description in >>>>> order to get to >>>>> the Internet. Yes, there is free public Internet access (just as >>>>> there are >>>>> free courtesy phones on the PSTN and free access to emergency >>>>> services from >>>>> pay phones. All these services are still connected to the public >>>>> Internet >>>>> infrastructure and they all represent an "operator" with some >>>>> level of >>>>> information about the caller. >>>>> >>>>> With the over-emphasis on VSPs, what is missing from the ECRIT >>>>> and i3 models >>>>> is the direct interface for querying the access network for >>>>> subscriber data >>>>> (should it prove necessary). These models need to take the long >>>>> view of how >>>>> emergency calling is done in the Internet age; they should not be >>>>> protracting >>>>> an unnecessary reliance on VSPs. >>>>> >>>>> I have deleted the premature and prejudicial text from the >>>>> subject heading. >>>>> And I'll leave this on ECRIT as the most appropriate WG. >>>>> >>>>> Cheers, >>>>> Martin >>>>> >>>>> -----Original Message----- >>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>>> Behalf Of >>>>> Hannes Tschofenig >>>>> Sent: Tuesday, 27 October 2009 8:23 AM >>>>> To: ecrit@ietf.org >>>>> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>>> considered harmful, >>>>> at least given our current experiences >>>>> >>>>> FYI: feedback from Brian regarding a recent ECRIT contribution. >>>>> >>>>>> -----Original Message----- >>>>>> From: geopriv-bounces@ietf.org >>>>>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian >>>>>> Sent: 26 October, 2009 23:10 >>>>>> To: geopriv@ietf.org >>>>>> Subject: [Geopriv] Winterbottom-ecrit-direct considered >>>>>> harmful, at least given our current experiences >>>>>> >>>>>> The notion behind -direct is to not use a service provider to >>>>>> place an emergency call. Instead, the device registers with >>>>>> an Emergency Services Routing Proxy immediately before the >>>>>> call and the call is routed directly from the device to the ESRP. >>>>>> >>>>>> At least at the moment, this is an exceedingly bad idea. >>>>>> >>>>>> Emergency calling authorities like service providers, a lot. >>>>>> They like them because they can hold them accountable, and the >>>>>> service providers don't like theft of service, which is >>>>>> something the emergency call guys have an analog to. >>>>>> >>>>>> The facts are that where unaccountable access to emergency >>>>>> calling is allowed, huge numbers of false calls occur, with no >>>>>> way to stop them, and no way to tell the good ones from the >>>>>> bad ones. This has been seen multiple times where so called >>>>>> "simless" or "unauthenticated" calls are allowed. >>>>>> >>>>>> -direct precisely duplicates simless calling. The only >>>>>> "registration" is an emergency registration, only emergency >>>>>> calls are allowed, any device can make an emergency call if >>>>>> all it has is a (radio) connection to any network. >>>>>> We can predict, with a very high degree of certainty, that the >>>>>> feature will be horribly abused: for example to test that a >>>>>> phone without a service plan works. >>>>>> >>>>>> There have been studies which show tens of thousands of bad >>>>>> calls with zero good ones. Nearly every authority I know >>>>>> where the regulator has insisted on simless calling wants it >>>>>> repealed. There is one counter example I know where the fact >>>>>> that they got a couple, literally, of good calls among the >>>>>> tens of thousands of bad calls was considered enough reason to >>>>>> put up with the problem. >>>>>> >>>>>> Service providers give us information that may be useful: a >>>>>> subscriber name and address for example, which is not >>>>>> spoofable by the caller. They have ways to trace callers, >>>>>> especially bad callers. They don't want their systems abused >>>>>> any more than the emergency calling authorities do. >>>>>> >>>>>> This is a bad idea. A very bad idea. Please stop it. >>>>>> >>>>>> Someday, we may have better ways to prevent abuse. Until we >>>>>> do, service providers are a good thing on an emergency call. >>>>>> We don't want them cut out. >>>>>> >>>>>> Brian >>>>>> >>>>>> _______________________________________________ >>>>>> Geopriv mailing list >>>>>> Geopriv@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/geopriv >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > From bernard_aboba@hotmail.com Tue Oct 27 09:07:33 2009 Return-Path: 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 9D84D3A6A2B for ; Tue, 27 Oct 2009 09:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.165 X-Spam-Level: X-Spam-Status: No, score=-1.165 tagged_above=-999 required=5 tests=[AWL=1.434, 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 LdTAZ-tU6Fk5 for ; Tue, 27 Oct 2009 09:07:31 -0700 (PDT) Received: from blu0-omc1-s3.blu0.hotmail.com (blu0-omc1-s3.blu0.hotmail.com [65.55.116.14]) by core3.amsl.com (Postfix) with ESMTP id 91C673A6A0C for ; Tue, 27 Oct 2009 09:07:31 -0700 (PDT) Received: from BLU137-DS7 ([65.55.116.8]) by blu0-omc1-s3.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 09:07:46 -0700 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Richard Barnes'" , "'Brian Rosen'" References: <273B7AE8-679E-482F-9802-48668CB24552@bbn.com> In-Reply-To: <273B7AE8-679E-482F-9802-48668CB24552@bbn.com> Date: Tue, 27 Oct 2009 09:07:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpXE1qhkjHXSSGWScecsHQuqHKOLAACeCoQ Content-Language: en-us X-OriginalArrivalTime: 27 Oct 2009 16:07:46.0116 (UTC) FILETIME=[9F44A840:01CA571F] Cc: ecrit@ietf.org Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Tue, 27 Oct 2009 16:07:33 -0000 In the case of an emergency call, what is "transitive trust" is based on, exactly? Is it an understanding that a VSP allowed to contact the PSAP will only interconnect with other carriers that it deems sufficiently trustworthy and that demonstrate an ability/willingness to trace/investigate/prevent prank calls? If so, what happens if an individual attempts to make an emergency call from a VSP that does not satisfy those conditions (e.g. a provider that, say, enables emergency calls to be made from the IP-equivalent of a Trac phone)? Or are all VSPs somehow "inherently trustworthy" as are all potential transitive trust paths? Issues of "transitive trust" and expectations of customer facing providers also arise at lower layers. This isn't just about authentication, it's also about tracing and audit, as SAVI WG demonstrates. In these kind of discussions, it can be quite helpful to attempt to write down exactly what security properties are desired and under what conditions/assumptions they can be delivered. This may not lead to any conclusions, but at least we'll have a clear understanding of what the key assumptions are and when they can be expected to be valid. -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Richard Barnes Sent: Tuesday, October 27, 2009 7:39 AM To: Brian Rosen Cc: ecrit@ietf.org Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Brian, Is the security goal here more access control (i.e., controlling who can send calls to a PSAP) or attribution/identification for post-hoc action. If it's the latter, then ISTM that the problem can largely be reduced to having a certificate infrastructure that binds authenticated identities to real-world entities. The "extended validation" certificates that current commercial CAs issue seem to largely satisfy this requirement. --Richard On Oct 27, 2009, at 4:31 PM, Brian Rosen wrote: > Of course not all VSPs will have trust relationships with all > PSAPs. One > can hope that long term, we can evolve to transitive trust > relationships > that work pretty well cross border. > > The emergency guys are actually terrified of private/individual > domains > sending them calls, and we're telling them we expect that to be > possible, > but rare, and we're giving them mechanisms that will effectively > allow them > to turn off calls selectively, based on factors including what > domain the > call comes from. They expect that such calls will be one of the > loopholes > where they get equivalents to sim-less calls, which drive them > nuts. They > don't want ANY calls that don't come from service providers, > although they > seem to be okay with the notion that the SP may not have great > identity (AOL > being a poster child). So, while indeed they understand, and have > concerns > about having to take calls from Sierra Leone VoIP services Pty, they > would > much rather have a call that went through them then a call that went > through > no service provider at all. > > I'm not trying to make calls direct from devices or private domains > impossible, but I think the notion that we're promoting them is a > very bad > idea until we have effective mechanisms to prevent abuse. > > Brian > > > > > On 10/27/09 9:02 AM, "Marc Linsner" wrote: > >> Brian, >> >> I'm a little confused. I don't remember you objecting to >> requirement RE1 >> from RFC5012 and I remember your use case about a Sierra Leone VSP. >> >> Are you implying that *all* VSPs will have a trust relationships >> with *all* >> PSAPs? >> >> What is the difference between a call coming from a private/ >> individual >> domain (as in not a commercial VSP) and a VSP on the other side of >> the world >> (outside the jurisdiction)? >> >> I'm trying to figure out whether you're objecting to anonymous >> calls to the >> PSAP or the mechanisms proposed in this draft? >> >> [Don't take this as my endorsement of the draft, as I'm not sure I >> agree >> with UAs registering with the ESRP.] >> >> -Marc- >> >> >> On 10/26/09 8:59 PM, "Brian Rosen" wrote: >> >>> First of all, I put it on the wrong email list, sorry about that. >>> >>> Then, we have carefully arranged it so that there is no identity >>> coming from >>> the access network provider, and because the location is coming >>> from that >>> provider, we really don't want to. But even if we did, we would >>> need a >>> really good identifier, and there isn't one. >>> >>> The problem we have with -direct is anonymous callers, and if they >>> have any >>> option, they would also be location-less. Until and unless we get >>> rid of >>> anonymity, we can't encourage service provider-less calls. The >>> draft does >>> not make any provision to provide any kind of identity. Many >>> networks >>> (think free wifi for example) would make providing good identity >>> difficult. >>> >>> The fact is that there is a SERVICE provider in nearly all of the >>> communications systems. The SERVICE provider is in a position to >>> assist >>> the emergency calling system when it needs more information. >>> That's what a >>> good SERVICE provider does. Cutting them out is not a great >>> idea. Most of >>> the attempts to provide real time communications between people >>> have evolved >>> to using service providers, even when there were alternatives. File >>> transfer via something like Torrent is a counterexample (which >>> isn't real >>> time), but even there, you end up with service providers like The >>> Pirate Bay >>> (R.I.P) to provide introduction services. I don't think we're >>> going to see >>> changes that eliminate service providers, and in this case, they >>> provide >>> value to the emergency calling systems. All of the emergency >>> professionals >>> I know have issues with service providers, but they would react >>> with horror >>> if you suggested cutting them out. Ask them, please. >>> >>> So, I claim you have a solution in search of a problem. We have >>> solved the >>> "calling network isn't the access network" problem already. Service >>> providers ARE in the path now, in nearly every case (in fact a >>> counter >>> example escapes me, although there probably are some). There is >>> no movement >>> I can detect which would change that any time soon; quite the >>> opposite. We >>> have a known killer problem without some kind of subscription to a >>> service >>> that provides a good identity, for which you provide no answers. >>> We have >>> experience with the killer problem: sim-less calling was supposed >>> to provide >>> a way to make an emergency call in exactly the kinds of >>> circumstances you >>> are describing. Our real world experience is that you create a >>> huge problem >>> that diverts resources from helping people to chasing scammers and >>> flea-market sellers. >>> >>> Nothing is perfect: you can get a AIM screen name without a very >>> good >>> identity for example. However, the notion that we're going to >>> provide >>> direct access without a service provider deliberately, especially >>> without >>> really good identity from the access network is, in my opinion not >>> only a >>> no, it's a heck no. I'll line up as many emergency service >>> professionals as >>> you would like to tell you this is a harmful idea. >>> >>> >>> >>> >>> >>> >>> On 10/26/09 7:56 PM, "Dawson, Martin" >>> wrote: >>> >>>> I am glad this has come up. It's a debate that has to happen if >>>> we are to >>>> move >>>> beyond a long standing legacy misconception. >>>> >>>> In the circuit service world - whether it was POTS or mobile, the >>>> access >>>> network had full responsibility for delivering the emergency >>>> call. In that >>>> world, routing an emergency call meant getting a circuit >>>> established to the >>>> correct call center. In most parts of the world, this was done >>>> using the >>>> regional part of the PSTN to switch the circuit to a call center >>>> on the >>>> PSTN. >>>> In some jurisdictions, such as the US, it was done directly from >>>> the local >>>> exchange carrier to the call center. Either way, there was no >>>> third party >>>> involved. >>>> >>>> Now we have the Internet. We still have public access network >>>> providers. >>>> They >>>> switch packets onto the Internet for their subscribers. They can >>>> similarly >>>> ensure that packets reach the local emergency call centers. >>>> >>>> The fact is that there was no equivalent of a VSP in the >>>> traditional >>>> environment. VoIP is a presence service, and it had no common >>>> equivalent in >>>> the PSTN world. It could have, but the narrowband state of >>>> technology and >>>> the >>>> common market use cases didn't support its development. By the >>>> time ISDN >>>> arrived, the PSTN had already slipped into its palliative stage >>>> without >>>> realizing it. >>>> >>>> It's an entrenched misconception that because the circuit service >>>> provided >>>> by >>>> exchange carriers was most commonly used for "voice" (but, it >>>> should be >>>> noted, >>>> also for fax, telex, tty, security system monitoring and, even, >>>> IP data) >>>> that >>>> VSPs are somehow equivalent to exchange carriers. They are not. >>>> >>>> Indeed, involving VSPs in emergency calls is the Internet >>>> equivalent of >>>> involving long distance providers in POTS emergency calls. They >>>> are neither >>>> necessary nor particularly helpful; they can't be guaranteed to >>>> be within >>>> the >>>> emergency jurisdiction; depending on them actually diminishes the >>>> efficacy >>>> of >>>> emergency service access. It does not help the caller, the >>>> emergency >>>> service, >>>> nor the third party to insist on the third party's involvement. >>>> >>>> It can't be helped if you have over sold the benefits of VSP >>>> involvement to >>>> yourself and others Brian. It is time to have a reasoned debate. >>>> From my >>>> perspective, the argument that there is no "subscription" >>>> involved is >>>> patently >>>> false. There has to be a subscription of some description in >>>> order to get to >>>> the Internet. Yes, there is free public Internet access (just as >>>> there are >>>> free courtesy phones on the PSTN and free access to emergency >>>> services from >>>> pay phones. All these services are still connected to the public >>>> Internet >>>> infrastructure and they all represent an "operator" with some >>>> level of >>>> information about the caller. >>>> >>>> With the over-emphasis on VSPs, what is missing from the ECRIT >>>> and i3 models >>>> is the direct interface for querying the access network for >>>> subscriber data >>>> (should it prove necessary). These models need to take the long >>>> view of how >>>> emergency calling is done in the Internet age; they should not be >>>> protracting >>>> an unnecessary reliance on VSPs. >>>> >>>> I have deleted the premature and prejudicial text from the >>>> subject heading. >>>> And I'll leave this on ECRIT as the most appropriate WG. >>>> >>>> Cheers, >>>> Martin >>>> >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>> Behalf Of >>>> Hannes Tschofenig >>>> Sent: Tuesday, 27 October 2009 8:23 AM >>>> To: ecrit@ietf.org >>>> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>> considered harmful, >>>> at least given our current experiences >>>> >>>> FYI: feedback from Brian regarding a recent ECRIT contribution. >>>> >>>>> -----Original Message----- >>>>> From: geopriv-bounces@ietf.org >>>>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian >>>>> Sent: 26 October, 2009 23:10 >>>>> To: geopriv@ietf.org >>>>> Subject: [Geopriv] Winterbottom-ecrit-direct considered >>>>> harmful, at least given our current experiences >>>>> >>>>> The notion behind -direct is to not use a service provider to >>>>> place an emergency call. Instead, the device registers with >>>>> an Emergency Services Routing Proxy immediately before the >>>>> call and the call is routed directly from the device to the ESRP. >>>>> >>>>> At least at the moment, this is an exceedingly bad idea. >>>>> >>>>> Emergency calling authorities like service providers, a lot. >>>>> They like them because they can hold them accountable, and the >>>>> service providers don't like theft of service, which is >>>>> something the emergency call guys have an analog to. >>>>> >>>>> The facts are that where unaccountable access to emergency >>>>> calling is allowed, huge numbers of false calls occur, with no >>>>> way to stop them, and no way to tell the good ones from the >>>>> bad ones. This has been seen multiple times where so called >>>>> "simless" or "unauthenticated" calls are allowed. >>>>> >>>>> -direct precisely duplicates simless calling. The only >>>>> "registration" is an emergency registration, only emergency >>>>> calls are allowed, any device can make an emergency call if >>>>> all it has is a (radio) connection to any network. >>>>> We can predict, with a very high degree of certainty, that the >>>>> feature will be horribly abused: for example to test that a >>>>> phone without a service plan works. >>>>> >>>>> There have been studies which show tens of thousands of bad >>>>> calls with zero good ones. Nearly every authority I know >>>>> where the regulator has insisted on simless calling wants it >>>>> repealed. There is one counter example I know where the fact >>>>> that they got a couple, literally, of good calls among the >>>>> tens of thousands of bad calls was considered enough reason to >>>>> put up with the problem. >>>>> >>>>> Service providers give us information that may be useful: a >>>>> subscriber name and address for example, which is not >>>>> spoofable by the caller. They have ways to trace callers, >>>>> especially bad callers. They don't want their systems abused >>>>> any more than the emergency calling authorities do. >>>>> >>>>> This is a bad idea. A very bad idea. Please stop it. >>>>> >>>>> Someday, we may have better ways to prevent abuse. Until we >>>>> do, service providers are a good thing on an emergency call. >>>>> We don't want them cut out. >>>>> >>>>> Brian >>>>> >>>>> _______________________________________________ >>>>> Geopriv mailing list >>>>> Geopriv@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/geopriv >>>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> > > > _______________________________________________ > 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 br@brianrosen.net Tue Oct 27 09:34:50 2009 Return-Path: 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 565003A68DD for ; Tue, 27 Oct 2009 09:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 84oc2+QZhad9 for ; Tue, 27 Oct 2009 09:34:48 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id C4E423A6A56 for ; Tue, 27 Oct 2009 09:34:26 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.216]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1N2p0B-000836-HX; Tue, 27 Oct 2009 11:34:31 -0500 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 27 Oct 2009 12:34:32 -0400 From: Brian Rosen To: Bernard Aboba , Richard Barnes Message-ID: Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXE1qhkjHXSSGWScecsHQuqHKOLAACeCoQAAGIShU= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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: Cc: ecrit@ietf.org Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Tue, 27 Oct 2009 16:34:50 -0000 In this case, I'm imagining that national emergency services people will trust their local providers, and we can arrange transitive trust relationships between such national entities. As an example, the U.S. Emergency authority's CA could sign a cert for a carrier in the U.S. A caller who nomaded to the U.K. may place an emergency call via the U.S. Carrier and it may be reasonable for the UK PSAP to have access to the US CA's cert. One of the things you learn about the emergency service guys is that they have all of these rules. You say "okay, I understand the rules, but what happens if a call arrives that doesn't follow the rules?". They bluster a lot about how you HAVE to follow the rules, but then they say "we'll take the call". That is, as long as they have a call taker available. So, two points: we try to build as good of a system as we can, and we try up front to get as many calls to follow the rules. We'll let calls that don't through. However, if the call center is stressed, especially if it is deliberately attacked, the systems will react by prioritizing which calls are answered first. One of the inputs is where is the call coming from. If a call comes from someone the PSAP knows, and it is overloaded, it's more likely such calls will be answered then if it comes from someone it doesn't know. "simless" calls, or things that look like simless calls, go to the bottom of the queue. Brian On 10/27/09 12:07 PM, "Bernard Aboba" wrote: > In the case of an emergency call, what is "transitive trust" is based on, > exactly? Is it an understanding that a VSP allowed to contact the PSAP will > only > interconnect with other carriers that it deems sufficiently trustworthy and > that > demonstrate an ability/willingness to trace/investigate/prevent prank calls? > > If so, what happens if an individual attempts to make an emergency call from > a > VSP that does not satisfy those conditions (e.g. a provider that, say, > enables > emergency calls to be made from the IP-equivalent of a Trac phone)? Or are > all VSPs somehow "inherently trustworthy" as are all potential transitive > trust > paths? > > Issues of "transitive trust" and expectations of customer facing providers > also > arise at lower layers. This isn't just about authentication, it's also > about > tracing and audit, as SAVI WG demonstrates. > > In these kind of discussions, it can be quite helpful to attempt to write > down > exactly what security properties are desired and under what > conditions/assumptions > they can be delivered. This may not lead to any conclusions, but at least > we'll > have a clear understanding of what the key assumptions are and when they can > be > expected to be valid. > > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Richard Barnes > Sent: Tuesday, October 27, 2009 7:39 AM > To: Brian Rosen > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered > > Brian, > > Is the security goal here more access control (i.e., controlling who > can send calls to a PSAP) or attribution/identification for post-hoc > action. > > If it's the latter, then ISTM that the problem can largely be reduced > to having a certificate infrastructure that binds authenticated > identities to real-world entities. The "extended validation" > certificates that current commercial CAs issue seem to largely satisfy > this requirement. > > --Richard > > > On Oct 27, 2009, at 4:31 PM, Brian Rosen wrote: > >> Of course not all VSPs will have trust relationships with all >> PSAPs. One >> can hope that long term, we can evolve to transitive trust >> relationships >> that work pretty well cross border. >> >> The emergency guys are actually terrified of private/individual >> domains >> sending them calls, and we're telling them we expect that to be >> possible, >> but rare, and we're giving them mechanisms that will effectively >> allow them >> to turn off calls selectively, based on factors including what >> domain the >> call comes from. They expect that such calls will be one of the >> loopholes >> where they get equivalents to sim-less calls, which drive them >> nuts. They >> don't want ANY calls that don't come from service providers, >> although they >> seem to be okay with the notion that the SP may not have great >> identity (AOL >> being a poster child). So, while indeed they understand, and have >> concerns >> about having to take calls from Sierra Leone VoIP services Pty, they >> would >> much rather have a call that went through them then a call that went >> through >> no service provider at all. >> >> I'm not trying to make calls direct from devices or private domains >> impossible, but I think the notion that we're promoting them is a >> very bad >> idea until we have effective mechanisms to prevent abuse. >> >> Brian >> >> >> >> >> On 10/27/09 9:02 AM, "Marc Linsner" wrote: >> >>> Brian, >>> >>> I'm a little confused. I don't remember you objecting to >>> requirement RE1 >>> from RFC5012 and I remember your use case about a Sierra Leone VSP. >>> >>> Are you implying that *all* VSPs will have a trust relationships >>> with *all* >>> PSAPs? >>> >>> What is the difference between a call coming from a private/ >>> individual >>> domain (as in not a commercial VSP) and a VSP on the other side of >>> the world >>> (outside the jurisdiction)? >>> >>> I'm trying to figure out whether you're objecting to anonymous >>> calls to the >>> PSAP or the mechanisms proposed in this draft? >>> >>> [Don't take this as my endorsement of the draft, as I'm not sure I >>> agree >>> with UAs registering with the ESRP.] >>> >>> -Marc- >>> >>> >>> On 10/26/09 8:59 PM, "Brian Rosen" wrote: >>> >>>> First of all, I put it on the wrong email list, sorry about that. >>>> >>>> Then, we have carefully arranged it so that there is no identity >>>> coming from >>>> the access network provider, and because the location is coming >>>> from that >>>> provider, we really don't want to. But even if we did, we would >>>> need a >>>> really good identifier, and there isn't one. >>>> >>>> The problem we have with -direct is anonymous callers, and if they >>>> have any >>>> option, they would also be location-less. Until and unless we get >>>> rid of >>>> anonymity, we can't encourage service provider-less calls. The >>>> draft does >>>> not make any provision to provide any kind of identity. Many >>>> networks >>>> (think free wifi for example) would make providing good identity >>>> difficult. >>>> >>>> The fact is that there is a SERVICE provider in nearly all of the >>>> communications systems. The SERVICE provider is in a position to >>>> assist >>>> the emergency calling system when it needs more information. >>>> That's what a >>>> good SERVICE provider does. Cutting them out is not a great >>>> idea. Most of >>>> the attempts to provide real time communications between people >>>> have evolved >>>> to using service providers, even when there were alternatives. File >>>> transfer via something like Torrent is a counterexample (which >>>> isn't real >>>> time), but even there, you end up with service providers like The >>>> Pirate Bay >>>> (R.I.P) to provide introduction services. I don't think we're >>>> going to see >>>> changes that eliminate service providers, and in this case, they >>>> provide >>>> value to the emergency calling systems. All of the emergency >>>> professionals >>>> I know have issues with service providers, but they would react >>>> with horror >>>> if you suggested cutting them out. Ask them, please. >>>> >>>> So, I claim you have a solution in search of a problem. We have >>>> solved the >>>> "calling network isn't the access network" problem already. Service >>>> providers ARE in the path now, in nearly every case (in fact a >>>> counter >>>> example escapes me, although there probably are some). There is >>>> no movement >>>> I can detect which would change that any time soon; quite the >>>> opposite. We >>>> have a known killer problem without some kind of subscription to a >>>> service >>>> that provides a good identity, for which you provide no answers. >>>> We have >>>> experience with the killer problem: sim-less calling was supposed >>>> to provide >>>> a way to make an emergency call in exactly the kinds of >>>> circumstances you >>>> are describing. Our real world experience is that you create a >>>> huge problem >>>> that diverts resources from helping people to chasing scammers and >>>> flea-market sellers. >>>> >>>> Nothing is perfect: you can get a AIM screen name without a very >>>> good >>>> identity for example. However, the notion that we're going to >>>> provide >>>> direct access without a service provider deliberately, especially >>>> without >>>> really good identity from the access network is, in my opinion not >>>> only a >>>> no, it's a heck no. I'll line up as many emergency service >>>> professionals as >>>> you would like to tell you this is a harmful idea. >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 10/26/09 7:56 PM, "Dawson, Martin" >>>> wrote: >>>> >>>>> I am glad this has come up. It's a debate that has to happen if >>>>> we are to >>>>> move >>>>> beyond a long standing legacy misconception. >>>>> >>>>> In the circuit service world - whether it was POTS or mobile, the >>>>> access >>>>> network had full responsibility for delivering the emergency >>>>> call. In that >>>>> world, routing an emergency call meant getting a circuit >>>>> established to the >>>>> correct call center. In most parts of the world, this was done >>>>> using the >>>>> regional part of the PSTN to switch the circuit to a call center >>>>> on the >>>>> PSTN. >>>>> In some jurisdictions, such as the US, it was done directly from >>>>> the local >>>>> exchange carrier to the call center. Either way, there was no >>>>> third party >>>>> involved. >>>>> >>>>> Now we have the Internet. We still have public access network >>>>> providers. >>>>> They >>>>> switch packets onto the Internet for their subscribers. They can >>>>> similarly >>>>> ensure that packets reach the local emergency call centers. >>>>> >>>>> The fact is that there was no equivalent of a VSP in the >>>>> traditional >>>>> environment. VoIP is a presence service, and it had no common >>>>> equivalent in >>>>> the PSTN world. It could have, but the narrowband state of >>>>> technology and >>>>> the >>>>> common market use cases didn't support its development. By the >>>>> time ISDN >>>>> arrived, the PSTN had already slipped into its palliative stage >>>>> without >>>>> realizing it. >>>>> >>>>> It's an entrenched misconception that because the circuit service >>>>> provided >>>>> by >>>>> exchange carriers was most commonly used for "voice" (but, it >>>>> should be >>>>> noted, >>>>> also for fax, telex, tty, security system monitoring and, even, >>>>> IP data) >>>>> that >>>>> VSPs are somehow equivalent to exchange carriers. They are not. >>>>> >>>>> Indeed, involving VSPs in emergency calls is the Internet >>>>> equivalent of >>>>> involving long distance providers in POTS emergency calls. They >>>>> are neither >>>>> necessary nor particularly helpful; they can't be guaranteed to >>>>> be within >>>>> the >>>>> emergency jurisdiction; depending on them actually diminishes the >>>>> efficacy >>>>> of >>>>> emergency service access. It does not help the caller, the >>>>> emergency >>>>> service, >>>>> nor the third party to insist on the third party's involvement. >>>>> >>>>> It can't be helped if you have over sold the benefits of VSP >>>>> involvement to >>>>> yourself and others Brian. It is time to have a reasoned debate. >>>>> From my >>>>> perspective, the argument that there is no "subscription" >>>>> involved is >>>>> patently >>>>> false. There has to be a subscription of some description in >>>>> order to get to >>>>> the Internet. Yes, there is free public Internet access (just as >>>>> there are >>>>> free courtesy phones on the PSTN and free access to emergency >>>>> services from >>>>> pay phones. All these services are still connected to the public >>>>> Internet >>>>> infrastructure and they all represent an "operator" with some >>>>> level of >>>>> information about the caller. >>>>> >>>>> With the over-emphasis on VSPs, what is missing from the ECRIT >>>>> and i3 models >>>>> is the direct interface for querying the access network for >>>>> subscriber data >>>>> (should it prove necessary). These models need to take the long >>>>> view of how >>>>> emergency calling is done in the Internet age; they should not be >>>>> protracting >>>>> an unnecessary reliance on VSPs. >>>>> >>>>> I have deleted the premature and prejudicial text from the >>>>> subject heading. >>>>> And I'll leave this on ECRIT as the most appropriate WG. >>>>> >>>>> Cheers, >>>>> Martin >>>>> >>>>> -----Original Message----- >>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>>> Behalf Of >>>>> Hannes Tschofenig >>>>> Sent: Tuesday, 27 October 2009 8:23 AM >>>>> To: ecrit@ietf.org >>>>> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>>> considered harmful, >>>>> at least given our current experiences >>>>> >>>>> FYI: feedback from Brian regarding a recent ECRIT contribution. >>>>> >>>>>> -----Original Message----- >>>>>> From: geopriv-bounces@ietf.org >>>>>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian >>>>>> Sent: 26 October, 2009 23:10 >>>>>> To: geopriv@ietf.org >>>>>> Subject: [Geopriv] Winterbottom-ecrit-direct considered >>>>>> harmful, at least given our current experiences >>>>>> >>>>>> The notion behind -direct is to not use a service provider to >>>>>> place an emergency call. Instead, the device registers with >>>>>> an Emergency Services Routing Proxy immediately before the >>>>>> call and the call is routed directly from the device to the ESRP. >>>>>> >>>>>> At least at the moment, this is an exceedingly bad idea. >>>>>> >>>>>> Emergency calling authorities like service providers, a lot. >>>>>> They like them because they can hold them accountable, and the >>>>>> service providers don't like theft of service, which is >>>>>> something the emergency call guys have an analog to. >>>>>> >>>>>> The facts are that where unaccountable access to emergency >>>>>> calling is allowed, huge numbers of false calls occur, with no >>>>>> way to stop them, and no way to tell the good ones from the >>>>>> bad ones. This has been seen multiple times where so called >>>>>> "simless" or "unauthenticated" calls are allowed. >>>>>> >>>>>> -direct precisely duplicates simless calling. The only >>>>>> "registration" is an emergency registration, only emergency >>>>>> calls are allowed, any device can make an emergency call if >>>>>> all it has is a (radio) connection to any network. >>>>>> We can predict, with a very high degree of certainty, that the >>>>>> feature will be horribly abused: for example to test that a >>>>>> phone without a service plan works. >>>>>> >>>>>> There have been studies which show tens of thousands of bad >>>>>> calls with zero good ones. Nearly every authority I know >>>>>> where the regulator has insisted on simless calling wants it >>>>>> repealed. There is one counter example I know where the fact >>>>>> that they got a couple, literally, of good calls among the >>>>>> tens of thousands of bad calls was considered enough reason to >>>>>> put up with the problem. >>>>>> >>>>>> Service providers give us information that may be useful: a >>>>>> subscriber name and address for example, which is not >>>>>> spoofable by the caller. They have ways to trace callers, >>>>>> especially bad callers. They don't want their systems abused >>>>>> any more than the emergency calling authorities do. >>>>>> >>>>>> This is a bad idea. A very bad idea. Please stop it. >>>>>> >>>>>> Someday, we may have better ways to prevent abuse. Until we >>>>>> do, service providers are a good thing on an emergency call. >>>>>> We don't want them cut out. >>>>>> >>>>>> Brian >>>>>> >>>>>> _______________________________________________ >>>>>> Geopriv mailing list >>>>>> Geopriv@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/geopriv >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> >> >> >> _______________________________________________ >> 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 jmpolk@cisco.com Tue Oct 27 10:48:40 2009 Return-Path: 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 6BD313A6A6F for ; Tue, 27 Oct 2009 10:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.511 X-Spam-Level: X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 RtnDW7S9Ot6N for ; Tue, 27 Oct 2009 10:48:38 -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 E71443A6A46 for ; Tue, 27 Oct 2009 10:48:38 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgEAPPO5kqrR7Hu/2dsb2JhbACIG7kimFWCOgaBfwSLYQ X-IronPort-AV: E=Sophos;i="4.44,634,1249257600"; d="scan'208";a="262237086" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 27 Oct 2009 17:48:52 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9RHmqh9021607; Tue, 27 Oct 2009 17:48:52 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 10:48:52 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.11.171]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 10:48:51 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 27 Oct 2009 12:48:50 -0500 To: "Winterbottom, James" From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 27 Oct 2009 17:48:51.0792 (UTC) FILETIME=[BEB15D00:01CA572D] Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Tue, 27 Oct 2009 17:48:40 -0000 James I'd like to focus on this point below. At what point did an ESRP become a SIP registrar (for unauthenticated UAs to register to when they don't register to any other registrar in any domain in the ... universe)? James At 08:02 AM 10/27/2009, Marc Linsner wrote: > > >[Don't take this as my endorsement of the draft, as I'm not sure I agree >with UAs registering with the ESRP.] > >-Marc- > > >On 10/26/09 8:59 PM, "Brian Rosen" wrote: > > > First of all, I put it on the wrong email list, sorry about that. > > > > Then, we have carefully arranged it so that there is no identity > coming from > > the access network provider, and because the location is coming from that > > provider, we really don't want to. But even if we did, we would need a > > really good identifier, and there isn't one. > > > > The problem we have with -direct is anonymous callers, and if they have any > > option, they would also be location-less. Until and unless we get rid of > > anonymity, we can't encourage service provider-less calls. The draft does > > not make any provision to provide any kind of identity. Many networks > > (think free wifi for example) would make providing good identity difficult. > > > > The fact is that there is a SERVICE provider in nearly all of the > > communications systems. The SERVICE provider is in a position to assist > > the emergency calling system when it needs more information. That's what a > > good SERVICE provider does. Cutting them out is not a great idea. Most of > > the attempts to provide real time communications between people > have evolved > > to using service providers, even when there were alternatives. File > > transfer via something like Torrent is a counterexample (which isn't real > > time), but even there, you end up with service providers like The > Pirate Bay > > (R.I.P) to provide introduction services. I don't think we're going to see > > changes that eliminate service providers, and in this case, they provide > > value to the emergency calling systems. All of the emergency professionals > > I know have issues with service providers, but they would react with horror > > if you suggested cutting them out. Ask them, please. > > > > So, I claim you have a solution in search of a problem. We have solved the > > "calling network isn't the access network" problem already. Service > > providers ARE in the path now, in nearly every case (in fact a counter > > example escapes me, although there probably are some). There is > no movement > > I can detect which would change that any time soon; quite the opposite. We > > have a known killer problem without some kind of subscription to a service > > that provides a good identity, for which you provide no answers. We have > > experience with the killer problem: sim-less calling was supposed > to provide > > a way to make an emergency call in exactly the kinds of circumstances you > > are describing. Our real world experience is that you create a > huge problem > > that diverts resources from helping people to chasing scammers and > > flea-market sellers. > > > > Nothing is perfect: you can get a AIM screen name without a very good > > identity for example. However, the notion that we're going to provide > > direct access without a service provider deliberately, especially without > > really good identity from the access network is, in my opinion not only a > > no, it's a heck no. I'll line up as many emergency service > professionals as > > you would like to tell you this is a harmful idea. > > > > > > > > > > > > > > On 10/26/09 7:56 PM, "Dawson, Martin" wrote: > > > >> I am glad this has come up. It's a debate that has to happen if we are to > >> move > >> beyond a long standing legacy misconception. > >> > >> In the circuit service world - whether it was POTS or mobile, the access > >> network had full responsibility for delivering the emergency call. In that > >> world, routing an emergency call meant getting a circuit > established to the > >> correct call center. In most parts of the world, this was done using the > >> regional part of the PSTN to switch the circuit to a call center > on the PSTN. > >> In some jurisdictions, such as the US, it was done directly from the local > >> exchange carrier to the call center. Either way, there was no third party > >> involved. > >> > >> Now we have the Internet. We still have public access network > providers. They > >> switch packets onto the Internet for their subscribers. They can similarly > >> ensure that packets reach the local emergency call centers. > >> > >> The fact is that there was no equivalent of a VSP in the traditional > >> environment. VoIP is a presence service, and it had no common > equivalent in > >> the PSTN world. It could have, but the narrowband state of > technology and the > >> common market use cases didn't support its development. By the time ISDN > >> arrived, the PSTN had already slipped into its palliative stage without > >> realizing it. > >> > >> It's an entrenched misconception that because the circuit > service provided by > >> exchange carriers was most commonly used for "voice" (but, it should be > >> noted, > >> also for fax, telex, tty, security system monitoring and, even, > IP data) that > >> VSPs are somehow equivalent to exchange carriers. They are not. > >> > >> Indeed, involving VSPs in emergency calls is the Internet equivalent of > >> involving long distance providers in POTS emergency calls. They > are neither > >> necessary nor particularly helpful; they can't be guaranteed to > be within the > >> emergency jurisdiction; depending on them actually diminishes > the efficacy of > >> emergency service access. It does not help the caller, the > emergency service, > >> nor the third party to insist on the third party's involvement. > >> > >> It can't be helped if you have over sold the benefits of VSP > involvement to > >> yourself and others Brian. It is time to have a reasoned debate. From my > >> perspective, the argument that there is no "subscription" involved is > >> patently > >> false. There has to be a subscription of some description in > order to get to > >> the Internet. Yes, there is free public Internet access (just as there are > >> free courtesy phones on the PSTN and free access to emergency > services from > >> pay phones. All these services are still connected to the public Internet > >> infrastructure and they all represent an "operator" with some level of > >> information about the caller. > >> > >> With the over-emphasis on VSPs, what is missing from the ECRIT > and i3 models > >> is the direct interface for querying the access network for > subscriber data > >> (should it prove necessary). These models need to take the long > view of how > >> emergency calling is done in the Internet age; they should not > be protracting > >> an unnecessary reliance on VSPs. > >> > >> I have deleted the premature and prejudicial text from the > subject heading. > >> And I'll leave this on ECRIT as the most appropriate WG. > >> > >> Cheers, > >> Martin > >> > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > >> Hannes Tschofenig > >> Sent: Tuesday, 27 October 2009 8:23 AM > >> To: ecrit@ietf.org > >> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct > considered harmful, > >> at least given our current experiences > >> > >> FYI: feedback from Brian regarding a recent ECRIT contribution. > >> > >>> -----Original Message----- > >>> From: geopriv-bounces@ietf.org > >>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian > >>> Sent: 26 October, 2009 23:10 > >>> To: geopriv@ietf.org > >>> Subject: [Geopriv] Winterbottom-ecrit-direct considered > >>> harmful, at least given our current experiences > >>> > >>> The notion behind -direct is to not use a service provider to > >>> place an emergency call. Instead, the device registers with > >>> an Emergency Services Routing Proxy immediately before the > >>> call and the call is routed directly from the device to the ESRP. > >>> > >>> At least at the moment, this is an exceedingly bad idea. > >>> > >>> Emergency calling authorities like service providers, a lot. > >>> They like them because they can hold them accountable, and the > >>> service providers don't like theft of service, which is > >>> something the emergency call guys have an analog to. > >>> > >>> The facts are that where unaccountable access to emergency > >>> calling is allowed, huge numbers of false calls occur, with no > >>> way to stop them, and no way to tell the good ones from the > >>> bad ones. This has been seen multiple times where so called > >>> "simless" or "unauthenticated" calls are allowed. > >>> > >>> -direct precisely duplicates simless calling. The only > >>> "registration" is an emergency registration, only emergency > >>> calls are allowed, any device can make an emergency call if > >>> all it has is a (radio) connection to any network. > >>> We can predict, with a very high degree of certainty, that the > >>> feature will be horribly abused: for example to test that a > >>> phone without a service plan works. > >>> > >>> There have been studies which show tens of thousands of bad > >>> calls with zero good ones. Nearly every authority I know > >>> where the regulator has insisted on simless calling wants it > >>> repealed. There is one counter example I know where the fact > >>> that they got a couple, literally, of good calls among the > >>> tens of thousands of bad calls was considered enough reason to > >>> put up with the problem. > >>> > >>> Service providers give us information that may be useful: a > >>> subscriber name and address for example, which is not > >>> spoofable by the caller. They have ways to trace callers, > >>> especially bad callers. They don't want their systems abused > >>> any more than the emergency calling authorities do. > >>> > >>> This is a bad idea. A very bad idea. Please stop it. > >>> > >>> Someday, we may have better ways to prevent abuse. Until we > >>> do, service providers are a good thing on an emergency call. > >>> We don't want them cut out. > >>> > >>> Brian > >>> > >>> _______________________________________________ > >>> Geopriv mailing list > >>> Geopriv@ietf.org > >>> https://www.ietf.org/mailman/listinfo/geopriv > >>> > >> > >> _______________________________________________ > >> 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 > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From James.Winterbottom@andrew.com Tue Oct 27 12:51:01 2009 Return-Path: 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 A8B6528C132 for ; Tue, 27 Oct 2009 12:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[AWL=0.849, 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 wC8ywLq3xPg0 for ; Tue, 27 Oct 2009 12:51:00 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 97FC93A68A6 for ; Tue, 27 Oct 2009 12:50:59 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:57279 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S67042AbZJ0TvN convert rfc822-to-8bit (ORCPT ); Tue, 27 Oct 2009 14:51:13 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 27 Oct 2009 14:51:12 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 28 Oct 2009 03:51:10 +0800 From: "Winterbottom, James" To: Brian Rosen , Marc Linsner , "ecrit@ietf.org" Date: Wed, 28 Oct 2009 03:51:06 +0800 Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpWgLxkSiEL2R0NsU6jGpn0Z/MHbAAAcM9wAARjeVAAAyhOFAAZRcrDAAMdqDAACsX5wA== Message-ID: <5A55A45AE77F5941B18E5457ECAC8188011EB8DA21B0@SISPE7MB1.commscope.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Tue, 27 Oct 2009 19:51:01 -0000 I think that this response highlights the misunderstanding that is being propagated about this draft. The domain is not totally private blah blah blah. It is an access network, ISP if you will, that will direct the flow to the ESRP. The ISP has foot print in the PSAP jurisdiction, it can be followed up with and forced to comply with things in exactly the same way that LEC can today. This is the same model as happened to today, the local access provider directs the calls to the PSAP. Why do we need a long distance provider involved or even more alarmingly, as Brian suggests, a chain of long distance providers? When things fail or run amok in this scenario, who is responsible and how on Earth, or in heaven for that matter, do you unravel the mess? You will need an international court to decide the real cause. The emergency providers are terrified, Brian, because real alternatives are not being put on the table. The emergency providers I talk to are just as terrified of end-points providing location and them having to just believe what it says, with no form of validation being available. The proposal on the table here provides mechanisms for these checks to take place, as well as keeping the traffic local rather than trunking it out of the local jurisdiction. I will stress again that this solution is being totally misrepresented as if you are comparing it SIMless because it is not, the device must have a legitimate connection to the Internet. Cheers James > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Brian Rosen > Sent: Wednesday, 28 October 2009 1:32 AM > To: Marc Linsner; ecrit@ietf.org > Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered > > Of course not all VSPs will have trust relationships with all PSAPs. One > can hope that long term, we can evolve to transitive trust relationships > that work pretty well cross border. > > The emergency guys are actually terrified of private/individual domains > sending them calls, and we're telling them we expect that to be possible, > but rare, and we're giving them mechanisms that will effectively allow > them > to turn off calls selectively, based on factors including what domain the > call comes from. They expect that such calls will be one of the loopholes > where they get equivalents to sim-less calls, which drive them nuts. They > don't want ANY calls that don't come from service providers, although they > seem to be okay with the notion that the SP may not have great identity > (AOL > being a poster child). So, while indeed they understand, and have > concerns > about having to take calls from Sierra Leone VoIP services Pty, they would > much rather have a call that went through them then a call that went > through > no service provider at all. > > I'm not trying to make calls direct from devices or private domains > impossible, but I think the notion that we're promoting them is a very bad > idea until we have effective mechanisms to prevent abuse. > > Brian > > > > > On 10/27/09 9:02 AM, "Marc Linsner" wrote: > > > Brian, > > > > I'm a little confused. I don't remember you objecting to requirement > RE1 > > from RFC5012 and I remember your use case about a Sierra Leone VSP. > > > > Are you implying that *all* VSPs will have a trust relationships with > *all* > > PSAPs? > > > > What is the difference between a call coming from a private/individual > > domain (as in not a commercial VSP) and a VSP on the other side of the > world > > (outside the jurisdiction)? > > > > I'm trying to figure out whether you're objecting to anonymous calls to > the > > PSAP or the mechanisms proposed in this draft? > > > > [Don't take this as my endorsement of the draft, as I'm not sure I agree > > with UAs registering with the ESRP.] > > > > -Marc- > > > > > > On 10/26/09 8:59 PM, "Brian Rosen" wrote: > > > >> First of all, I put it on the wrong email list, sorry about that. > >> > >> Then, we have carefully arranged it so that there is no identity coming > from > >> the access network provider, and because the location is coming from > that > >> provider, we really don't want to. But even if we did, we would need a > >> really good identifier, and there isn't one. > >> > >> The problem we have with -direct is anonymous callers, and if they have > any > >> option, they would also be location-less. Until and unless we get rid > of > >> anonymity, we can't encourage service provider-less calls. The draft > does > >> not make any provision to provide any kind of identity. Many networks > >> (think free wifi for example) would make providing good identity > difficult. > >> > >> The fact is that there is a SERVICE provider in nearly all of the > >> communications systems. The SERVICE provider is in a position to > assist > >> the emergency calling system when it needs more information. That's > what a > >> good SERVICE provider does. Cutting them out is not a great idea. > Most of > >> the attempts to provide real time communications between people have > evolved > >> to using service providers, even when there were alternatives. File > >> transfer via something like Torrent is a counterexample (which isn't > real > >> time), but even there, you end up with service providers like The > Pirate Bay > >> (R.I.P) to provide introduction services. I don't think we're going to > see > >> changes that eliminate service providers, and in this case, they > provide > >> value to the emergency calling systems. All of the emergency > professionals > >> I know have issues with service providers, but they would react with > horror > >> if you suggested cutting them out. Ask them, please. > >> > >> So, I claim you have a solution in search of a problem. We have solved > the > >> "calling network isn't the access network" problem already. Service > >> providers ARE in the path now, in nearly every case (in fact a counter > >> example escapes me, although there probably are some). There is no > movement > >> I can detect which would change that any time soon; quite the opposite. > We > >> have a known killer problem without some kind of subscription to a > service > >> that provides a good identity, for which you provide no answers. We > have > >> experience with the killer problem: sim-less calling was supposed to > provide > >> a way to make an emergency call in exactly the kinds of circumstances > you > >> are describing. Our real world experience is that you create a huge > problem > >> that diverts resources from helping people to chasing scammers and > >> flea-market sellers. > >> > >> Nothing is perfect: you can get a AIM screen name without a very good > >> identity for example. However, the notion that we're going to provide > >> direct access without a service provider deliberately, especially > without > >> really good identity from the access network is, in my opinion not only > a > >> no, it's a heck no. I'll line up as many emergency service > professionals as > >> you would like to tell you this is a harmful idea. > >> > >> > >> > >> > >> > >> > >> On 10/26/09 7:56 PM, "Dawson, Martin" wrote: > >> > >>> I am glad this has come up. It's a debate that has to happen if we are > to > >>> move > >>> beyond a long standing legacy misconception. > >>> > >>> In the circuit service world - whether it was POTS or mobile, the > access > >>> network had full responsibility for delivering the emergency call. In > that > >>> world, routing an emergency call meant getting a circuit established > to the > >>> correct call center. In most parts of the world, this was done using > the > >>> regional part of the PSTN to switch the circuit to a call center on > the > >>> PSTN. > >>> In some jurisdictions, such as the US, it was done directly from the > local > >>> exchange carrier to the call center. Either way, there was no third > party > >>> involved. > >>> > >>> Now we have the Internet. We still have public access network > providers. > >>> They > >>> switch packets onto the Internet for their subscribers. They can > similarly > >>> ensure that packets reach the local emergency call centers. > >>> > >>> The fact is that there was no equivalent of a VSP in the traditional > >>> environment. VoIP is a presence service, and it had no common > equivalent in > >>> the PSTN world. It could have, but the narrowband state of technology > and > >>> the > >>> common market use cases didn't support its development. By the time > ISDN > >>> arrived, the PSTN had already slipped into its palliative stage > without > >>> realizing it. > >>> > >>> It's an entrenched misconception that because the circuit service > provided > >>> by > >>> exchange carriers was most commonly used for "voice" (but, it should > be > >>> noted, > >>> also for fax, telex, tty, security system monitoring and, even, IP > data) > >>> that > >>> VSPs are somehow equivalent to exchange carriers. They are not. > >>> > >>> Indeed, involving VSPs in emergency calls is the Internet equivalent > of > >>> involving long distance providers in POTS emergency calls. They are > neither > >>> necessary nor particularly helpful; they can't be guaranteed to be > within > >>> the > >>> emergency jurisdiction; depending on them actually diminishes the > efficacy > >>> of > >>> emergency service access. It does not help the caller, the emergency > >>> service, > >>> nor the third party to insist on the third party's involvement. > >>> > >>> It can't be helped if you have over sold the benefits of VSP > involvement to > >>> yourself and others Brian. It is time to have a reasoned debate. From > my > >>> perspective, the argument that there is no "subscription" involved is > >>> patently > >>> false. There has to be a subscription of some description in order to > get to > >>> the Internet. Yes, there is free public Internet access (just as there > are > >>> free courtesy phones on the PSTN and free access to emergency services > from > >>> pay phones. All these services are still connected to the public > Internet > >>> infrastructure and they all represent an "operator" with some level of > >>> information about the caller. > >>> > >>> With the over-emphasis on VSPs, what is missing from the ECRIT and i3 > models > >>> is the direct interface for querying the access network for subscriber > data > >>> (should it prove necessary). These models need to take the long view > of how > >>> emergency calling is done in the Internet age; they should not be > >>> protracting > >>> an unnecessary reliance on VSPs. > >>> > >>> I have deleted the premature and prejudicial text from the subject > heading. > >>> And I'll leave this on ECRIT as the most appropriate WG. > >>> > >>> Cheers, > >>> Martin > >>> > >>> -----Original Message----- > >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of > >>> Hannes Tschofenig > >>> Sent: Tuesday, 27 October 2009 8:23 AM > >>> To: ecrit@ietf.org > >>> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered > harmful, > >>> at least given our current experiences > >>> > >>> FYI: feedback from Brian regarding a recent ECRIT contribution. > >>> > >>>> -----Original Message----- > >>>> From: geopriv-bounces@ietf.org > >>>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian > >>>> Sent: 26 October, 2009 23:10 > >>>> To: geopriv@ietf.org > >>>> Subject: [Geopriv] Winterbottom-ecrit-direct considered > >>>> harmful, at least given our current experiences > >>>> > >>>> The notion behind -direct is to not use a service provider to > >>>> place an emergency call. Instead, the device registers with > >>>> an Emergency Services Routing Proxy immediately before the > >>>> call and the call is routed directly from the device to the ESRP. > >>>> > >>>> At least at the moment, this is an exceedingly bad idea. > >>>> > >>>> Emergency calling authorities like service providers, a lot. > >>>> They like them because they can hold them accountable, and the > >>>> service providers don't like theft of service, which is > >>>> something the emergency call guys have an analog to. > >>>> > >>>> The facts are that where unaccountable access to emergency > >>>> calling is allowed, huge numbers of false calls occur, with no > >>>> way to stop them, and no way to tell the good ones from the > >>>> bad ones. This has been seen multiple times where so called > >>>> "simless" or "unauthenticated" calls are allowed. > >>>> > >>>> -direct precisely duplicates simless calling. The only > >>>> "registration" is an emergency registration, only emergency > >>>> calls are allowed, any device can make an emergency call if > >>>> all it has is a (radio) connection to any network. > >>>> We can predict, with a very high degree of certainty, that the > >>>> feature will be horribly abused: for example to test that a > >>>> phone without a service plan works. > >>>> > >>>> There have been studies which show tens of thousands of bad > >>>> calls with zero good ones. Nearly every authority I know > >>>> where the regulator has insisted on simless calling wants it > >>>> repealed. There is one counter example I know where the fact > >>>> that they got a couple, literally, of good calls among the > >>>> tens of thousands of bad calls was considered enough reason to > >>>> put up with the problem. > >>>> > >>>> Service providers give us information that may be useful: a > >>>> subscriber name and address for example, which is not > >>>> spoofable by the caller. They have ways to trace callers, > >>>> especially bad callers. They don't want their systems abused > >>>> any more than the emergency calling authorities do. > >>>> > >>>> This is a bad idea. A very bad idea. Please stop it. > >>>> > >>>> Someday, we may have better ways to prevent abuse. Until we > >>>> do, service providers are a good thing on an emergency call. > >>>> We don't want them cut out. > >>>> > >>>> Brian > >>>> > >>>> _______________________________________________ > >>>> Geopriv mailing list > >>>> Geopriv@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/geopriv > >>>> > >>> > >>> _______________________________________________ > >>> 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 > > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From James.Winterbottom@andrew.com Tue Oct 27 12:53:42 2009 Return-Path: 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 9105F28C104 for ; Tue, 27 Oct 2009 12:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=0.679, 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 nW2NHiPmt2yS for ; Tue, 27 Oct 2009 12:53:41 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.243]) by core3.amsl.com (Postfix) with ESMTP id E93523A68A6 for ; Tue, 27 Oct 2009 12:53:40 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:31208 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S4827784AbZJ0Txx convert rfc822-to-8bit (ORCPT ); Tue, 27 Oct 2009 14:53:53 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 27 Oct 2009 14:53:52 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 28 Oct 2009 03:53:48 +0800 From: "Winterbottom, James" To: "James M. Polk" Date: Wed, 28 Oct 2009 03:53:44 +0800 Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXLcQuLKe3iUH6R8GOPxhCYPrSHQADgY3Q Message-ID: <5A55A45AE77F5941B18E5457ECAC8188011EB8DA21B2@SISPE7MB1.commscope.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Tue, 27 Oct 2009 19:53:42 -0000 Hi James, It is not unauthenticated, the device must have access to an Internet feed, and that feed is always registered or authenticated in some fashion. One of the key proposals of this draft is that the calling device, and please do not think phone, think computing device (which might be a game console) does register with the ESRP. This relatively short-term registration is the way in which call-back is attained. The registration can also be used by the ESRP to check that the caller is in fact in the calling domain of the PSAP or at a minimum where the point of presence in the access network is. So in short answer to your question James, in the expanding Universe of NG Emergency Service solutions. Cheers James > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Wednesday, 28 October 2009 4:49 AM > To: Winterbottom, James > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered > > James > > I'd like to focus on this point below. > > At what point did an ESRP become a SIP registrar (for unauthenticated > UAs to register to when they don't register to any other registrar in > any domain in the ... universe)? > > James > > At 08:02 AM 10/27/2009, Marc Linsner wrote: > > > > > >[Don't take this as my endorsement of the draft, as I'm not sure I agree > >with UAs registering with the ESRP.] > > > >-Marc- > > > > > >On 10/26/09 8:59 PM, "Brian Rosen" wrote: > > > > > First of all, I put it on the wrong email list, sorry about that. > > > > > > Then, we have carefully arranged it so that there is no identity > > coming from > > > the access network provider, and because the location is coming from > that > > > provider, we really don't want to. But even if we did, we would need > a > > > really good identifier, and there isn't one. > > > > > > The problem we have with -direct is anonymous callers, and if they > have any > > > option, they would also be location-less. Until and unless we get rid > of > > > anonymity, we can't encourage service provider-less calls. The draft > does > > > not make any provision to provide any kind of identity. Many networks > > > (think free wifi for example) would make providing good identity > difficult. > > > > > > The fact is that there is a SERVICE provider in nearly all of the > > > communications systems. The SERVICE provider is in a position to > assist > > > the emergency calling system when it needs more information. That's > what a > > > good SERVICE provider does. Cutting them out is not a great idea. > Most of > > > the attempts to provide real time communications between people > > have evolved > > > to using service providers, even when there were alternatives. File > > > transfer via something like Torrent is a counterexample (which isn't > real > > > time), but even there, you end up with service providers like The > > Pirate Bay > > > (R.I.P) to provide introduction services. I don't think we're going > to see > > > changes that eliminate service providers, and in this case, they > provide > > > value to the emergency calling systems. All of the emergency > professionals > > > I know have issues with service providers, but they would react with > horror > > > if you suggested cutting them out. Ask them, please. > > > > > > So, I claim you have a solution in search of a problem. We have > solved the > > > "calling network isn't the access network" problem already. Service > > > providers ARE in the path now, in nearly every case (in fact a counter > > > example escapes me, although there probably are some). There is > > no movement > > > I can detect which would change that any time soon; quite the > opposite. We > > > have a known killer problem without some kind of subscription to a > service > > > that provides a good identity, for which you provide no answers. We > have > > > experience with the killer problem: sim-less calling was supposed > > to provide > > > a way to make an emergency call in exactly the kinds of circumstances > you > > > are describing. Our real world experience is that you create a > > huge problem > > > that diverts resources from helping people to chasing scammers and > > > flea-market sellers. > > > > > > Nothing is perfect: you can get a AIM screen name without a very good > > > identity for example. However, the notion that we're going to provide > > > direct access without a service provider deliberately, especially > without > > > really good identity from the access network is, in my opinion not > only a > > > no, it's a heck no. I'll line up as many emergency service > > professionals as > > > you would like to tell you this is a harmful idea. > > > > > > > > > > > > > > > > > > > > > On 10/26/09 7:56 PM, "Dawson, Martin" > wrote: > > > > > >> I am glad this has come up. It's a debate that has to happen if we > are to > > >> move > > >> beyond a long standing legacy misconception. > > >> > > >> In the circuit service world - whether it was POTS or mobile, the > access > > >> network had full responsibility for delivering the emergency call. In > that > > >> world, routing an emergency call meant getting a circuit > > established to the > > >> correct call center. In most parts of the world, this was done using > the > > >> regional part of the PSTN to switch the circuit to a call center > > on the PSTN. > > >> In some jurisdictions, such as the US, it was done directly from the > local > > >> exchange carrier to the call center. Either way, there was no third > party > > >> involved. > > >> > > >> Now we have the Internet. We still have public access network > > providers. They > > >> switch packets onto the Internet for their subscribers. They can > similarly > > >> ensure that packets reach the local emergency call centers. > > >> > > >> The fact is that there was no equivalent of a VSP in the traditional > > >> environment. VoIP is a presence service, and it had no common > > equivalent in > > >> the PSTN world. It could have, but the narrowband state of > > technology and the > > >> common market use cases didn't support its development. By the time > ISDN > > >> arrived, the PSTN had already slipped into its palliative stage > without > > >> realizing it. > > >> > > >> It's an entrenched misconception that because the circuit > > service provided by > > >> exchange carriers was most commonly used for "voice" (but, it should > be > > >> noted, > > >> also for fax, telex, tty, security system monitoring and, even, > > IP data) that > > >> VSPs are somehow equivalent to exchange carriers. They are not. > > >> > > >> Indeed, involving VSPs in emergency calls is the Internet equivalent > of > > >> involving long distance providers in POTS emergency calls. They > > are neither > > >> necessary nor particularly helpful; they can't be guaranteed to > > be within the > > >> emergency jurisdiction; depending on them actually diminishes > > the efficacy of > > >> emergency service access. It does not help the caller, the > > emergency service, > > >> nor the third party to insist on the third party's involvement. > > >> > > >> It can't be helped if you have over sold the benefits of VSP > > involvement to > > >> yourself and others Brian. It is time to have a reasoned debate. From > my > > >> perspective, the argument that there is no "subscription" involved is > > >> patently > > >> false. There has to be a subscription of some description in > > order to get to > > >> the Internet. Yes, there is free public Internet access (just as > there are > > >> free courtesy phones on the PSTN and free access to emergency > > services from > > >> pay phones. All these services are still connected to the public > Internet > > >> infrastructure and they all represent an "operator" with some level > of > > >> information about the caller. > > >> > > >> With the over-emphasis on VSPs, what is missing from the ECRIT > > and i3 models > > >> is the direct interface for querying the access network for > > subscriber data > > >> (should it prove necessary). These models need to take the long > > view of how > > >> emergency calling is done in the Internet age; they should not > > be protracting > > >> an unnecessary reliance on VSPs. > > >> > > >> I have deleted the premature and prejudicial text from the > > subject heading. > > >> And I'll leave this on ECRIT as the most appropriate WG. > > >> > > >> Cheers, > > >> Martin > > >> > > >> -----Original Message----- > > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf Of > > >> Hannes Tschofenig > > >> Sent: Tuesday, 27 October 2009 8:23 AM > > >> To: ecrit@ietf.org > > >> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct > > considered harmful, > > >> at least given our current experiences > > >> > > >> FYI: feedback from Brian regarding a recent ECRIT contribution. > > >> > > >>> -----Original Message----- > > >>> From: geopriv-bounces@ietf.org > > >>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian > > >>> Sent: 26 October, 2009 23:10 > > >>> To: geopriv@ietf.org > > >>> Subject: [Geopriv] Winterbottom-ecrit-direct considered > > >>> harmful, at least given our current experiences > > >>> > > >>> The notion behind -direct is to not use a service provider to > > >>> place an emergency call. Instead, the device registers with > > >>> an Emergency Services Routing Proxy immediately before the > > >>> call and the call is routed directly from the device to the ESRP. > > >>> > > >>> At least at the moment, this is an exceedingly bad idea. > > >>> > > >>> Emergency calling authorities like service providers, a lot. > > >>> They like them because they can hold them accountable, and the > > >>> service providers don't like theft of service, which is > > >>> something the emergency call guys have an analog to. > > >>> > > >>> The facts are that where unaccountable access to emergency > > >>> calling is allowed, huge numbers of false calls occur, with no > > >>> way to stop them, and no way to tell the good ones from the > > >>> bad ones. This has been seen multiple times where so called > > >>> "simless" or "unauthenticated" calls are allowed. > > >>> > > >>> -direct precisely duplicates simless calling. The only > > >>> "registration" is an emergency registration, only emergency > > >>> calls are allowed, any device can make an emergency call if > > >>> all it has is a (radio) connection to any network. > > >>> We can predict, with a very high degree of certainty, that the > > >>> feature will be horribly abused: for example to test that a > > >>> phone without a service plan works. > > >>> > > >>> There have been studies which show tens of thousands of bad > > >>> calls with zero good ones. Nearly every authority I know > > >>> where the regulator has insisted on simless calling wants it > > >>> repealed. There is one counter example I know where the fact > > >>> that they got a couple, literally, of good calls among the > > >>> tens of thousands of bad calls was considered enough reason to > > >>> put up with the problem. > > >>> > > >>> Service providers give us information that may be useful: a > > >>> subscriber name and address for example, which is not > > >>> spoofable by the caller. They have ways to trace callers, > > >>> especially bad callers. They don't want their systems abused > > >>> any more than the emergency calling authorities do. > > >>> > > >>> This is a bad idea. A very bad idea. Please stop it. > > >>> > > >>> Someday, we may have better ways to prevent abuse. Until we > > >>> do, service providers are a good thing on an emergency call. > > >>> We don't want them cut out. > > >>> > > >>> Brian > > >>> > > >>> _______________________________________________ > > >>> Geopriv mailing list > > >>> Geopriv@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/geopriv > > >>> > > >> > > >> _______________________________________________ > > >> 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 > > > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit > From hgs@cs.columbia.edu Tue Oct 27 13:07:28 2009 Return-Path: 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 B102C3A686D for ; Tue, 27 Oct 2009 13:07:28 -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 WWLJ4vBswRib for ; Tue, 27 Oct 2009 13:07:28 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 28D9628C111 for ; Tue, 27 Oct 2009 13:07:26 -0700 (PDT) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id n9RK75Av004266 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 27 Oct 2009 16:07:07 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Henning Schulzrinne In-Reply-To: <5A55A45AE77F5941B18E5457ECAC8188011EB8DA21B2@SISPE7MB1.commscope.com> Date: Tue, 27 Oct 2009 16:07:05 -0400 Content-Transfer-Encoding: 7bit Message-Id: <14CDFE68-E417-4C0F-84D6-9EA8B3ECE827@cs.columbia.edu> References: <5A55A45AE77F5941B18E5457ECAC8188011EB8DA21B2@SISPE7MB1.commscope.com> To: "Winterbottom, James" X-Mailer: Apple Mail (2.1076) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.6 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Tue, 27 Oct 2009 20:07:28 -0000 On Oct 27, 2009, at 3:53 PM, Winterbottom, James wrote: > Hi James, > > It is not unauthenticated, the device must have access to an > Internet feed, and that feed is always registered or authenticated > in some fashion. The "feed" might be, but the mobile user of the "feed" may not be. See earlier examples. > > One of the key proposals of this draft is that the calling device, > and please do not think phone, think computing device (which might > be a game console) does register with the ESRP. This relatively > short-term registration is the way in which call-back is attained. > The registration can also be used by the ESRP to check that the > caller is in fact in the calling domain of the PSAP or at a minimum > where the point of presence in the access network is. From jf.mule@cablelabs.com Tue Oct 27 13:33:00 2009 Return-Path: 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 3DC223A6A42 for ; Tue, 27 Oct 2009 13:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 nQDGWm3BPJSt for ; Tue, 27 Oct 2009 13:32:59 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 7EC123A69C2 for ; Tue, 27 Oct 2009 13:32:59 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with SMTP id n9RKXBpx017771; Tue, 27 Oct 2009 14:33:11 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 27 Oct 2009 14:33:11 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Oct 2009 14:32:52 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C6024FF311@srvxchg3.cablelabs.com> In-Reply-To: <04c501ca53ed$01030490$03ffa8c0@nsnintra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Regulatory Requirments for Callback Thread-Index: AcpT6xrEyw1oycZlS32UxbvbCvFlkQDWISfw References: <04c501ca53ed$01030490$03ffa8c0@nsnintra.net> From: "Jean-Francois Mule" To: "Hannes Tschofenig" X-Approved: ondar Cc: ecrit@ietf.org Subject: Re: [Ecrit] Regulatory Requirments for Callback 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: , X-List-Received-Date: Tue, 27 Oct 2009 20:33:00 -0000 Hi Hannes, The following reference from the CRTC (Canadian Radio-television and = Telecommunications Commission) may be close to what you're looking for: CRTC Telecom Circular CRTC 2008-2 "Emergency service obligations of nomadic local VoIP service providers = related to determining the location of a 9-1-1 caller [...] 10. In summary, the following main emergency service obligations flow = from Telecom Decision 2005-21 in relation to determining the location of = a 9-1-1 caller using nomadic local VoIP service: b) if a 9-1-1 call is disconnected before the operator can verbally = determine a caller's location, the operator must attempt to call back in = order to determine the caller's location; and" Disclaimer -- I'm not Canadian and I'm not a lawyer so I'm not sure = whether a "Telecom Cicular" or the "Telecom Decision 2005-21" constitute = "regulatory requirements". Jean-Fran=E7ois > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf Of Hannes Tschofenig > Sent: Friday, October 23, 2009 8:28 AM > To: ecrit@ietf.org > Subject: [Ecrit] Regulatory Requirments for Callback >=20 > Hi all, >=20 > I am looking for some references to regulatory requirements for > PSAP > callbacks. I would like to see what is required from a regulatory > point of > view as input for the PSAP callback document. >=20 > So, if someone has some documents please let me know. >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From jf.mule@cablelabs.com Tue Oct 27 13:36:31 2009 Return-Path: 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 183943A6901 for ; Tue, 27 Oct 2009 13:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 bxi89+n5khb7 for ; Tue, 27 Oct 2009 13:36:30 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 22FA73A68C3 for ; Tue, 27 Oct 2009 13:36:30 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with SMTP id n9RKagdX018127; Tue, 27 Oct 2009 14:36:43 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 27 Oct 2009 14:36:42 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Oct 2009 14:36:23 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C6024FF313@srvxchg3.cablelabs.com> In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C6024FF311@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Regulatory Requirments for Callback Thread-Index: AcpT6xrEyw1oycZlS32UxbvbCvFlkQDWISfwAABLa6A= References: <04c501ca53ed$01030490$03ffa8c0@nsnintra.net> <9AAEDF491EF7CA48AB587781B8F5D7C6024FF311@srvxchg3.cablelabs.com> From: "Jean-Francois Mule" To: "Hannes Tschofenig" X-Approved: ondar Cc: ecrit@ietf.org Subject: Re: [Ecrit] Regulatory Requirments for Callback 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: , X-List-Received-Date: Tue, 27 Oct 2009 20:36:31 -0000 How can one provide a reference without a URL? ... http://www.crtc.gc.ca/eng/archive/2008/ct2008-2.htm > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf Of Jean-Francois Mule > Sent: Tuesday, October 27, 2009 2:33 PM > To: Hannes Tschofenig > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Regulatory Requirments for Callback >=20 > Hi Hannes, >=20 > The following reference from the CRTC (Canadian Radio-television > and Telecommunications Commission) may be close to what you're > looking for: >=20 > CRTC Telecom Circular CRTC 2008-2 > "Emergency service obligations of nomadic local VoIP service > providers related to determining the location of a 9-1-1 caller > [...] > 10. In summary, the following main emergency service obligations > flow from Telecom Decision 2005-21 in relation to determining the > location of a 9-1-1 caller using nomadic local VoIP service: >=20 > b) if a 9-1-1 call is disconnected before the operator can verbally > determine a caller's location, the operator must attempt to call > back in order to determine the caller's location; and" >=20 > Disclaimer -- I'm not Canadian and I'm not a lawyer so I'm not sure > whether a "Telecom Cicular" or the "Telecom Decision 2005-21" > constitute "regulatory requirements". >=20 > Jean-Fran=E7ois >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > > Behalf Of Hannes Tschofenig > > Sent: Friday, October 23, 2009 8:28 AM > > To: ecrit@ietf.org > > Subject: [Ecrit] Regulatory Requirments for Callback > > > > Hi all, > > > > I am looking for some references to regulatory requirements for > > PSAP > > callbacks. I would like to see what is required from a regulatory > > point of > > view as input for the PSAP callback document. > > > > So, if someone has some documents please let me know. > > > > Ciao > > Hannes > > > > > > _______________________________________________ > > 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 mlinsner@cisco.com Tue Oct 27 14:18:22 2009 Return-Path: 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 443053A6800 for ; Tue, 27 Oct 2009 14:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.459 X-Spam-Level: X-Spam-Status: No, score=-6.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 DZ7JgVIfMDDt for ; Tue, 27 Oct 2009 14:18:21 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 5BB4C3A680F for ; Tue, 27 Oct 2009 14:18:21 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGgA50pAZnwN/2dsb2JhbADBeZhPhD8E X-IronPort-AV: E=Sophos;i="4.44,635,1249257600"; d="scan'208";a="65209186" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 27 Oct 2009 21:18:35 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9RLIZmf007393; Tue, 27 Oct 2009 21:18:35 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 17:18:35 -0400 Received: from [10.116.195.121] ([10.116.195.121]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 17:18:34 -0400 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 27 Oct 2009 17:18:32 -0400 From: Marc Linsner To: "Winterbottom, James" Message-ID: Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXLcQuLKe3iUH6R8GOPxhCYPrSHQADgY3QAAPPrMs= In-Reply-To: <5A55A45AE77F5941B18E5457ECAC8188011EB8DA21B2@SISPE7MB1.commscope.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 27 Oct 2009 21:18:34.0561 (UTC) FILETIME=[0A9B8B10:01CA574B] Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Tue, 27 Oct 2009 21:18:22 -0000 James W., On 10/27/09 3:53 PM, "Winterbottom, James" wrote: > Hi James, > > It is not unauthenticated, the device must have access to an Internet feed, > and that feed is always registered or authenticated in some fashion. > > One of the key proposals of this draft is that the calling device, and please > do not think phone, think computing device (which might be a game console) > does register with the ESRP. This relatively short-term registration is the > way in which call-back is attained. The registration can also be used by the > ESRP to check that the caller is in fact in the calling domain of the PSAP or > at a minimum where the point of presence in the access network is. > What is different in the registration process that allows "the ESRP to check that the caller is in fact in the calling domain of the PSAP" that can't happen via a SIP invite (with no registration)? Thanks, -Marc- From James.Winterbottom@andrew.com Tue Oct 27 16:18:32 2009 Return-Path: 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 618A128C0F8 for ; Tue, 27 Oct 2009 16:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.033 X-Spam-Level: X-Spam-Status: No, score=-2.033 tagged_above=-999 required=5 tests=[AWL=0.566, 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 TWy1AQqfF4-O for ; Tue, 27 Oct 2009 16:18:31 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.243]) by core3.amsl.com (Postfix) with ESMTP id 88DDB3A693B for ; Tue, 27 Oct 2009 16:18:31 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:48929 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S4832128AbZJ0XSp convert rfc822-to-8bit (ORCPT ); Tue, 27 Oct 2009 18:18:45 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 27 Oct 2009 18:18:46 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 28 Oct 2009 07:18:41 +0800 From: "Winterbottom, James" To: Marc Linsner Date: Wed, 28 Oct 2009 07:18:39 +0800 Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXLcQuLKe3iUH6R8GOPxhCYPrSHQADgY3QAAPPrMsABCVhIA== Message-ID: <5A55A45AE77F5941B18E5457ECAC8188011EB8DA2220@SISPE7MB1.commscope.com> References: <5A55A45AE77F5941B18E5457ECAC8188011EB8DA21B2@SISPE7MB1.commscope.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Tue, 27 Oct 2009 23:18:32 -0000 I guess nothing, but it can be done in the registration. The primary advantage of the registration is to support call-back. Cheers James > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Wednesday, 28 October 2009 8:19 AM > To: Winterbottom, James > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered > > James W., > > On 10/27/09 3:53 PM, "Winterbottom, James" > wrote: > > > Hi James, > > > > It is not unauthenticated, the device must have access to an Internet > feed, > > and that feed is always registered or authenticated in some fashion. > > > > One of the key proposals of this draft is that the calling device, and > please > > do not think phone, think computing device (which might be a game > console) > > does register with the ESRP. This relatively short-term registration is > the > > way in which call-back is attained. The registration can also be used by > the > > ESRP to check that the caller is in fact in the calling domain of the > PSAP or > > at a minimum where the point of presence in the access network is. > > > > What is different in the registration process that allows "the ESRP to > check > that the caller is in fact in the calling domain of the PSAP" that can't > happen via a SIP invite (with no registration)? > > Thanks, > > -Marc- > > From Martin.Thomson@andrew.com Tue Oct 27 17:01:58 2009 Return-Path: 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 D62E53A680A for ; Tue, 27 Oct 2009 17:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 jM1UvBpUijHX for ; Tue, 27 Oct 2009 17:01:58 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 04FFE3A67A2 for ; Tue, 27 Oct 2009 17:01:58 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:5414 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S70156AbZJ1ACM (ORCPT ); Tue, 27 Oct 2009 19:02:12 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 27 Oct 2009 19:02:12 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 28 Oct 2009 08:02:08 +0800 From: "Thomson, Martin" To: "Winterbottom, James" , Marc Linsner Date: Wed, 28 Oct 2009 08:02:34 +0800 Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXLcQuLKe3iUH6R8GOPxhCYPrSHQADgY3QAAPPrMsABCVhIAABewdg Message-ID: <8B0A9FCBB9832F43971E38010638454F0F251544@SISPE7MB1.commscope.com> References: <5A55A45AE77F5941B18E5457ECAC8188011EB8DA21B2@SISPE7MB1.commscope.com> <5A55A45AE77F5941B18E5457ECAC8188011EB8DA2220@SISPE7MB1.commscope.com> In-Reply-To: <5A55A45AE77F5941B18E5457ECAC8188011EB8DA2220@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Wed, 28 Oct 2009 00:01:58 -0000 U0lQIG91dGJvdW5kIChSRkMgNTYyNiBub3cpIHdvcmtzIHdoaWxlIHRoZSBkaWFsb2cgZm9yIHRo ZSBjYWxsIGlzIG9wZW4gd2l0aG91dCBhIHJlZ2lzdHJhdGlvbi4gIEhvd2V2ZXIsIHRvIHRha2Ug YWR2YW50YWdlIG9mIGFuIGV4aXN0aW5nIGZsb3csIHRoZSBzdWJzZXF1ZW50IGNhbGwgYmFjayBu ZWVkcyBhIHNlc3Npb24uICBBIHJlZ2lzdHJhdGlvbiBzZWVtZWQgdGhlIGVhc2llc3Qgd2F5IHRv IGVuc3VyZSB0aGF0IHRoaXMgZmxvdyBpcyBtYWludGFpbmVkLg0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzplY3Jp dC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gT2YgV2ludGVyYm90dG9tLCBKYW1lcw0K PiBTZW50OiBXZWRuZXNkYXksIDI4IE9jdG9iZXIgMjAwOSAxMDoxOSBBTQ0KPiBUbzogTWFyYyBM aW5zbmVyDQo+IENjOiBlY3JpdEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0Vjcml0XSBGVzog W0dlb3ByaXZdIFdpbnRlcmJvdHRvbS1lY3JpdC1kaXJlY3QgY29uc2lkZXJlZA0KPiANCj4gSSBn dWVzcyBub3RoaW5nLCBidXQgaXQgY2FuIGJlIGRvbmUgaW4gdGhlIHJlZ2lzdHJhdGlvbi4gVGhl IHByaW1hcnkNCj4gYWR2YW50YWdlIG9mIHRoZSByZWdpc3RyYXRpb24gaXMgdG8gc3VwcG9ydCBj YWxsLWJhY2suDQo+IA0KPiBDaGVlcnMNCj4gSmFtZXMNCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBNYXJjIExpbnNuZXIgW21haWx0bzptbGluc25lckBjaXNj by5jb21dDQo+ID4gU2VudDogV2VkbmVzZGF5LCAyOCBPY3RvYmVyIDIwMDkgODoxOSBBTQ0KPiA+ IFRvOiBXaW50ZXJib3R0b20sIEphbWVzDQo+ID4gQ2M6IGVjcml0QGlldGYub3JnDQo+ID4gU3Vi amVjdDogUmU6IFtFY3JpdF0gRlc6IFtHZW9wcml2XSBXaW50ZXJib3R0b20tZWNyaXQtZGlyZWN0 DQo+IGNvbnNpZGVyZWQNCj4gPg0KPiA+IEphbWVzIFcuLA0KPiA+DQo+ID4gT24gMTAvMjcvMDkg Mzo1MyBQTSwgIldpbnRlcmJvdHRvbSwgSmFtZXMiDQo+IDxKYW1lcy5XaW50ZXJib3R0b21AYW5k cmV3LmNvbT4NCj4gPiB3cm90ZToNCj4gPg0KPiA+ID4gSGkgSmFtZXMsDQo+ID4gPg0KPiA+ID4g SXQgaXMgbm90IHVuYXV0aGVudGljYXRlZCwgdGhlIGRldmljZSBtdXN0IGhhdmUgYWNjZXNzIHRv IGFuDQo+IEludGVybmV0DQo+ID4gZmVlZCwNCj4gPiA+IGFuZCB0aGF0IGZlZWQgaXMgYWx3YXlz IHJlZ2lzdGVyZWQgb3IgYXV0aGVudGljYXRlZCBpbiBzb21lDQo+IGZhc2hpb24uDQo+ID4gPg0K PiA+ID4gT25lIG9mIHRoZSBrZXkgcHJvcG9zYWxzIG9mIHRoaXMgZHJhZnQgaXMgdGhhdCB0aGUg Y2FsbGluZyBkZXZpY2UsDQo+IGFuZA0KPiA+IHBsZWFzZQ0KPiA+ID4gZG8gbm90IHRoaW5rIHBo b25lLCB0aGluayBjb21wdXRpbmcgZGV2aWNlICh3aGljaCBtaWdodCBiZSBhIGdhbWUNCj4gPiBj b25zb2xlKQ0KPiA+ID4gZG9lcyByZWdpc3RlciB3aXRoIHRoZSBFU1JQLiBUaGlzIHJlbGF0aXZl bHkgc2hvcnQtdGVybQ0KPiByZWdpc3RyYXRpb24gaXMNCj4gPiB0aGUNCj4gPiA+IHdheSBpbiB3 aGljaCBjYWxsLWJhY2sgaXMgYXR0YWluZWQuIFRoZSByZWdpc3RyYXRpb24gY2FuIGFsc28gYmUN Cj4gdXNlZCBieQ0KPiA+IHRoZQ0KPiA+ID4gRVNSUCB0byBjaGVjayB0aGF0IHRoZSBjYWxsZXIg aXMgaW4gZmFjdCBpbiB0aGUgY2FsbGluZyBkb21haW4gb2YNCj4gdGhlDQo+ID4gUFNBUCBvcg0K PiA+ID4gYXQgYSBtaW5pbXVtIHdoZXJlIHRoZSBwb2ludCBvZiBwcmVzZW5jZSBpbiB0aGUgYWNj ZXNzIG5ldHdvcmsgaXMuDQo+ID4gPg0KPiA+DQo+ID4gV2hhdCBpcyBkaWZmZXJlbnQgaW4gdGhl IHJlZ2lzdHJhdGlvbiBwcm9jZXNzIHRoYXQgYWxsb3dzICJ0aGUgRVNSUA0KPiB0bw0KPiA+IGNo ZWNrDQo+ID4gdGhhdCB0aGUgY2FsbGVyIGlzIGluIGZhY3QgaW4gdGhlIGNhbGxpbmcgZG9tYWlu IG9mIHRoZSBQU0FQIiB0aGF0DQo+IGNhbid0DQo+ID4gaGFwcGVuIHZpYSBhIFNJUCBpbnZpdGUg KHdpdGggbm8gcmVnaXN0cmF0aW9uKT8NCj4gPg0KPiA+IFRoYW5rcywNCj4gPg0KPiA+IC1NYXJj LQ0KPiA+DQo+ID4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IEVjcml0IG1haWxpbmcgbGlzdA0KPiBFY3JpdEBpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQoNCg== From mlinsner@cisco.com Wed Oct 28 05:34:59 2009 Return-Path: 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 D73A728C0DE for ; Wed, 28 Oct 2009 05:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.483 X-Spam-Level: X-Spam-Status: No, score=-6.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 OjmCfP+ICq7G for ; Wed, 28 Oct 2009 05:34:56 -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 CF6B928C12A for ; Wed, 28 Oct 2009 05:34:55 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMvX50pAZnwN/2dsb2JhbADBbpg7hD8E X-IronPort-AV: E=Sophos;i="4.44,639,1249257600"; d="scan'208";a="65287940" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 28 Oct 2009 12:35:10 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9SCZApv005799; Wed, 28 Oct 2009 12:35:10 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.3959); Wed, 28 Oct 2009 08:35:10 -0400 Received: from [10.116.195.121] ([10.116.195.121]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 08:35:09 -0400 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 28 Oct 2009 08:35:06 -0400 From: Marc Linsner To: "Winterbottom, James" Message-ID: Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXLcQuLKe3iUH6R8GOPxhCYPrSHQADgY3QAAPPrMsABCVhIAAb3V49 In-Reply-To: <5A55A45AE77F5941B18E5457ECAC8188011EB8DA2220@SISPE7MB1.commscope.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 28 Oct 2009 12:35:09.0652 (UTC) FILETIME=[163C7940:01CA57CB] Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Wed, 28 Oct 2009 12:34:59 -0000 James, Thanks, call-back was the only advantage I could come up with, so I wanted to make sure I wasn't missing something. -Marc- On 10/27/09 7:18 PM, "Winterbottom, James" wrote: > I guess nothing, but it can be done in the registration. The primary advantage > of the registration is to support call-back. > > Cheers > James > >> -----Original Message----- >> From: Marc Linsner [mailto:mlinsner@cisco.com] >> Sent: Wednesday, 28 October 2009 8:19 AM >> To: Winterbottom, James >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered >> >> James W., >> >> On 10/27/09 3:53 PM, "Winterbottom, James" >> wrote: >> >>> Hi James, >>> >>> It is not unauthenticated, the device must have access to an Internet >> feed, >>> and that feed is always registered or authenticated in some fashion. >>> >>> One of the key proposals of this draft is that the calling device, and >> please >>> do not think phone, think computing device (which might be a game >> console) >>> does register with the ESRP. This relatively short-term registration is >> the >>> way in which call-back is attained. The registration can also be used by >> the >>> ESRP to check that the caller is in fact in the calling domain of the >> PSAP or >>> at a minimum where the point of presence in the access network is. >>> >> >> What is different in the registration process that allows "the ESRP to >> check >> that the caller is in fact in the calling domain of the PSAP" that can't >> happen via a SIP invite (with no registration)? >> >> Thanks, >> >> -Marc- >> >> > From mlinsner@cisco.com Wed Oct 28 06:00:20 2009 Return-Path: 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 12ECD3A6808 for ; Wed, 28 Oct 2009 06:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.801 X-Spam-Level: X-Spam-Status: No, score=-5.801 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 SJc7D7SI0LRG for ; Wed, 28 Oct 2009 06:00:18 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id EC4303A69E7 for ; Wed, 28 Oct 2009 06:00:17 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4EALfc50pAZnwM/2dsb2JhbACCIy+XQadlmDeEPwQ X-IronPort-AV: E=Sophos;i="4.44,639,1249257600"; d="scan'208,217";a="65327255" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 28 Oct 2009 13:00:32 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9SD0Wve006550; Wed, 28 Oct 2009 13:00:32 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 09:00:32 -0400 Received: from [10.116.195.121] ([10.116.195.121]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 09:00:31 -0400 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 28 Oct 2009 09:00:30 -0400 From: Marc Linsner To: "Winterbottom, James" , "ecrit@ietf.org" Message-ID: Thread-Topic: draft-winterbottom-ecrit-direct Thread-Index: AcpXzqBvSdLImAXqgkOL97H+2d+Srg== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3339565231_230622" X-OriginalArrivalTime: 28 Oct 2009 13:00:31.0829 (UTC) FILETIME=[A1864050:01CA57CE] Subject: [Ecrit] draft-winterbottom-ecrit-direct 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: , X-List-Received-Date: Wed, 28 Oct 2009 13:00:20 -0000 > 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_3339565231_230622 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable So, to be sure I=B9ve got this straight. 1. The primary mechanism outlined in this draft enables a =8Cfree-agent=B9 SIP UA to register with an ESRP such to enable PSAP call-back. 2. The secondary purpose of this draft is to simply document (in one place) how a SIP UA could make emergency calls without using a VSP. A) This assumes the PS jurisdiction is comfortable with implementing a Registrar along side their ESRP (in support of #1). B) If in fact the SIP UA is used for making non-emergency calls, the AOR used for the non-emergency calls would not be known by the ESRP/PSAP. C) Longer term =8Ccall-back=B9, outside the suggested 60 minutes, would not be possible due to lack of UA AOR information. -Marc- --B_3339565231_230622 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable draft-winterbottom-ecrit-direct So, to be sure I’ve got this straight.

  1. The primary mechanism outlined in this draft enables= a ‘free-agent’ SIP UA to register with an ESRP such to enable P= SAP call-back.
  2. The secondary purpose of this draft is to simply documen= t (in one place) how a SIP UA could make emergency calls without usin= g a VSP.

A) This assumes the PS jurisdiction is comfortable with implementing a Regi= strar along side their ESRP (in support of #1).
B)  If in fact the SIP UA is used for making non-emergency calls, the = AOR used for the non-emergency calls would not be known by the ESRP/PSAP. C)  Longer term ‘call-back’, outside the suggested 60 minu= tes, would not be possible due to lack of UA AOR information.


-Marc- --B_3339565231_230622-- From Martin.Thomson@andrew.com Wed Oct 28 14:56:57 2009 Return-Path: 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 92C5C28C1DF for ; Wed, 28 Oct 2009 14:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 b3Yq0NM308nW for ; Wed, 28 Oct 2009 14:56:56 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.243]) by core3.amsl.com (Postfix) with ESMTP id 89F2F28C1DB for ; Wed, 28 Oct 2009 14:56:56 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:56013 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S4858127AbZJ1V5L (ORCPT ); Wed, 28 Oct 2009 16:57:11 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 28 Oct 2009 16:57:11 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Thu, 29 Oct 2009 05:57:07 +0800 From: "Thomson, Martin" To: Marc Linsner , "Winterbottom, James" , "ecrit@ietf.org" Date: Thu, 29 Oct 2009 05:57:32 +0800 Thread-Topic: draft-winterbottom-ecrit-direct Thread-Index: AcpXzqBvSdLImAXqgkOL97H+2d+SrgASd9dA Message-ID: <8B0A9FCBB9832F43971E38010638454F0F251759@SISPE7MB1.commscope.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [Ecrit] draft-winterbottom-ecrit-direct 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: , X-List-Received-Date: Wed, 28 Oct 2009 21:56:57 -0000 SGkgTWFyYywNCg0KSnVzdCBvbiB0aGUgb25lIHBvaW50Og0KDQo+IEMpIMKgTG9uZ2VyIHRlcm0g 4oCYY2FsbC1iYWNr4oCZLCBvdXRzaWRlIHRoZSBzdWdnZXN0ZWQgNjAgbWludXRlcywgd291bGQg bm90IGJlIHBvc3NpYmxlIGR1ZSB0byBsYWNrIG9mIFVBIEFPUiBpbmZvcm1hdGlvbi4NCg0KVGhp cyBpcyBvbmUgYXNwZWN0IHRoYXQgY291bGQgYmUgbWFkZSBjbGVhcmVyLiAgSXQgc2hvdWxkIGJl Og0KDQogICBbW1RoZSBleGlzdGluZyBzdGF0ZW1lbnQgaXMgdG8gdGhpcyBlZmZlY3Q6IFRoZSBF U1JQL3JlZ2lzdHJhciANCiAgIHNlbGVjdHMgYSByZWdpc3RyYXRpb24gcGVyaW9kIGJhc2VkIG9u IGxvY2FsIHBvbGljeS5dXSAgVGhlIA0KICAgZW1lcmdlbmN5IGNsaWVudCBNVVNUIGFjY2VwdCBh IHJlZ2lzdHJhdGlvbiBmb3IgYXQgbGVhc3QgNjAgbWludXRlcywNCiAgIGJ1dCBNQVkgYWNjZXB0 IGxvbmdlciByZWdpc3RyYXRpb25zIGJhc2VkIG9uIGl0cyBvd24gcG9saWN5Lg0KDQooSeKAmWxs IG5vdGUgdGhhdCB0aGlzIGlzIHZpcnR1YWxseSBpZGVudGljYWwgdG8gdGhlIG1lY2hhbmlzbSBh ZG9wdGVkIGJ5IDNHUFAgZm9yIGVtZXJnZW5jeSByZWdpc3RyYXRpb25zLCBleGNlcHQgZm9yIHRo ZSByZWNvZ25pdGlvbiB0aGF0IGEgY2xpZW50IGlzIHBlcm1pdHRlZCB0byBzZXQgcG9saWN5IGlu IHRoaXMgcmVnYXJkIGFsc28uKQ0KDQotLU1hcnRpbiANCg== From mlinsner@cisco.com Wed Oct 28 15:51:08 2009 Return-Path: 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 ED4C928C0F4 for ; Wed, 28 Oct 2009 15:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.424 X-Spam-Level: X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 cEM6W1x3tMCQ for ; Wed, 28 Oct 2009 15:51:07 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id D466E3A6781 for ; Wed, 28 Oct 2009 15:51:06 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAC5o6EpAZnwN/2dsb2JhbADDEpgngjoGgX8EgmSJBA X-IronPort-AV: E=Sophos;i="4.44,642,1249257600"; d="scan'208";a="65423740" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 28 Oct 2009 22:51:21 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9SMpLsC013033; Wed, 28 Oct 2009 22:51:21 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.3959); Wed, 28 Oct 2009 18:51:21 -0400 Received: from [10.116.195.121] ([10.116.195.121]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 18:51:20 -0400 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 28 Oct 2009 18:51:18 -0400 From: Marc Linsner To: Brian Rosen Message-ID: Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdz In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 28 Oct 2009 22:51:20.0201 (UTC) FILETIME=[2A668F90:01CA5821] Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Wed, 28 Oct 2009 22:51:09 -0000 Brian, What I hear you saying: 'if we don't document how to spoof a PSAP, then nobody will figure it out.' Isn't that a little short sighted? Joey@miscreant.org will figure out how to establish a SIP session with any PSAP in the world within 10 minutes of that PSAP being accessible via the Internet, regardless of documentation. I believe there's more harm created in not documenting this for John.Q.Public@ordinary_citizen.com. Granted, nobody here is looking to cause harm to a PSAP. But Joey@miscreant.org can certainly expend public safety resources by reporting a bomb threat to a local school. Should we require that all SIP calls to the local school come from a trusted SP? Where does it end? This isn't the way to deal with spam. -Marc- On 10/27/09 11:00 AM, "Brian Rosen" wrote: > The first goal is to prevent bad calls. > > The second goal is to indentify the source of the bad calls. > > I'm starting with the first goal. I don't want you to be able to take a > device out of a box, plug it into a network, and have the only call you can > make be an emergency call. I want the device to actually "work" (as in be > able to place calls to all the entities that it was intended to) first, and > then be able to place emergency calls. > > Please spend some time in a PSAP while a kid with a simless phone has "fun" > with it. Imagine how much fun the test mechanism is as opposed to placing > real calls. > > If we somehow get a bad call, we need to send the cops. That means we need > an identity (and a location). > > I think a good cert could be the basis of a good identity, if we could get > one. I don't see how we do that. > > Brian > > > On 10/27/09 10:39 AM, "Richard Barnes" wrote: > >> Brian, >> >> Is the security goal here more access control (i.e., controlling who >> can send calls to a PSAP) or attribution/identification for post-hoc >> action. >> >> If it's the latter, then ISTM that the problem can largely be reduced >> to having a certificate infrastructure that binds authenticated >> identities to real-world entities. The "extended validation" >> certificates that current commercial CAs issue seem to largely satisfy >> this requirement. >> >> --Richard >> >> >> On Oct 27, 2009, at 4:31 PM, Brian Rosen wrote: >> >>> Of course not all VSPs will have trust relationships with all >>> PSAPs. One >>> can hope that long term, we can evolve to transitive trust >>> relationships >>> that work pretty well cross border. >>> >>> The emergency guys are actually terrified of private/individual >>> domains >>> sending them calls, and we're telling them we expect that to be >>> possible, >>> but rare, and we're giving them mechanisms that will effectively >>> allow them >>> to turn off calls selectively, based on factors including what >>> domain the >>> call comes from. They expect that such calls will be one of the >>> loopholes >>> where they get equivalents to sim-less calls, which drive them >>> nuts. They >>> don't want ANY calls that don't come from service providers, >>> although they >>> seem to be okay with the notion that the SP may not have great >>> identity (AOL >>> being a poster child). So, while indeed they understand, and have >>> concerns >>> about having to take calls from Sierra Leone VoIP services Pty, they >>> would >>> much rather have a call that went through them then a call that went >>> through >>> no service provider at all. >>> >>> I'm not trying to make calls direct from devices or private domains >>> impossible, but I think the notion that we're promoting them is a >>> very bad >>> idea until we have effective mechanisms to prevent abuse. >>> >>> Brian >>> >>> >>> >>> >>> On 10/27/09 9:02 AM, "Marc Linsner" wrote: >>> >>>> Brian, >>>> >>>> I'm a little confused. I don't remember you objecting to >>>> requirement RE1 >>>> from RFC5012 and I remember your use case about a Sierra Leone VSP. >>>> >>>> Are you implying that *all* VSPs will have a trust relationships >>>> with *all* >>>> PSAPs? >>>> >>>> What is the difference between a call coming from a private/ >>>> individual >>>> domain (as in not a commercial VSP) and a VSP on the other side of >>>> the world >>>> (outside the jurisdiction)? >>>> >>>> I'm trying to figure out whether you're objecting to anonymous >>>> calls to the >>>> PSAP or the mechanisms proposed in this draft? >>>> >>>> [Don't take this as my endorsement of the draft, as I'm not sure I >>>> agree >>>> with UAs registering with the ESRP.] >>>> >>>> -Marc- >>>> >>>> >>>> On 10/26/09 8:59 PM, "Brian Rosen" wrote: >>>> >>>>> First of all, I put it on the wrong email list, sorry about that. >>>>> >>>>> Then, we have carefully arranged it so that there is no identity >>>>> coming from >>>>> the access network provider, and because the location is coming >>>>> from that >>>>> provider, we really don't want to. But even if we did, we would >>>>> need a >>>>> really good identifier, and there isn't one. >>>>> >>>>> The problem we have with -direct is anonymous callers, and if they >>>>> have any >>>>> option, they would also be location-less. Until and unless we get >>>>> rid of >>>>> anonymity, we can't encourage service provider-less calls. The >>>>> draft does >>>>> not make any provision to provide any kind of identity. Many >>>>> networks >>>>> (think free wifi for example) would make providing good identity >>>>> difficult. >>>>> >>>>> The fact is that there is a SERVICE provider in nearly all of the >>>>> communications systems. The SERVICE provider is in a position to >>>>> assist >>>>> the emergency calling system when it needs more information. >>>>> That's what a >>>>> good SERVICE provider does. Cutting them out is not a great >>>>> idea. Most of >>>>> the attempts to provide real time communications between people >>>>> have evolved >>>>> to using service providers, even when there were alternatives. File >>>>> transfer via something like Torrent is a counterexample (which >>>>> isn't real >>>>> time), but even there, you end up with service providers like The >>>>> Pirate Bay >>>>> (R.I.P) to provide introduction services. I don't think we're >>>>> going to see >>>>> changes that eliminate service providers, and in this case, they >>>>> provide >>>>> value to the emergency calling systems. All of the emergency >>>>> professionals >>>>> I know have issues with service providers, but they would react >>>>> with horror >>>>> if you suggested cutting them out. Ask them, please. >>>>> >>>>> So, I claim you have a solution in search of a problem. We have >>>>> solved the >>>>> "calling network isn't the access network" problem already. Service >>>>> providers ARE in the path now, in nearly every case (in fact a >>>>> counter >>>>> example escapes me, although there probably are some). There is >>>>> no movement >>>>> I can detect which would change that any time soon; quite the >>>>> opposite. We >>>>> have a known killer problem without some kind of subscription to a >>>>> service >>>>> that provides a good identity, for which you provide no answers. >>>>> We have >>>>> experience with the killer problem: sim-less calling was supposed >>>>> to provide >>>>> a way to make an emergency call in exactly the kinds of >>>>> circumstances you >>>>> are describing. Our real world experience is that you create a >>>>> huge problem >>>>> that diverts resources from helping people to chasing scammers and >>>>> flea-market sellers. >>>>> >>>>> Nothing is perfect: you can get a AIM screen name without a very >>>>> good >>>>> identity for example. However, the notion that we're going to >>>>> provide >>>>> direct access without a service provider deliberately, especially >>>>> without >>>>> really good identity from the access network is, in my opinion not >>>>> only a >>>>> no, it's a heck no. I'll line up as many emergency service >>>>> professionals as >>>>> you would like to tell you this is a harmful idea. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 10/26/09 7:56 PM, "Dawson, Martin" >>>>> wrote: >>>>> >>>>>> I am glad this has come up. It's a debate that has to happen if >>>>>> we are to >>>>>> move >>>>>> beyond a long standing legacy misconception. >>>>>> >>>>>> In the circuit service world - whether it was POTS or mobile, the >>>>>> access >>>>>> network had full responsibility for delivering the emergency >>>>>> call. In that >>>>>> world, routing an emergency call meant getting a circuit >>>>>> established to the >>>>>> correct call center. In most parts of the world, this was done >>>>>> using the >>>>>> regional part of the PSTN to switch the circuit to a call center >>>>>> on the >>>>>> PSTN. >>>>>> In some jurisdictions, such as the US, it was done directly from >>>>>> the local >>>>>> exchange carrier to the call center. Either way, there was no >>>>>> third party >>>>>> involved. >>>>>> >>>>>> Now we have the Internet. We still have public access network >>>>>> providers. >>>>>> They >>>>>> switch packets onto the Internet for their subscribers. They can >>>>>> similarly >>>>>> ensure that packets reach the local emergency call centers. >>>>>> >>>>>> The fact is that there was no equivalent of a VSP in the >>>>>> traditional >>>>>> environment. VoIP is a presence service, and it had no common >>>>>> equivalent in >>>>>> the PSTN world. It could have, but the narrowband state of >>>>>> technology and >>>>>> the >>>>>> common market use cases didn't support its development. By the >>>>>> time ISDN >>>>>> arrived, the PSTN had already slipped into its palliative stage >>>>>> without >>>>>> realizing it. >>>>>> >>>>>> It's an entrenched misconception that because the circuit service >>>>>> provided >>>>>> by >>>>>> exchange carriers was most commonly used for "voice" (but, it >>>>>> should be >>>>>> noted, >>>>>> also for fax, telex, tty, security system monitoring and, even, >>>>>> IP data) >>>>>> that >>>>>> VSPs are somehow equivalent to exchange carriers. They are not. >>>>>> >>>>>> Indeed, involving VSPs in emergency calls is the Internet >>>>>> equivalent of >>>>>> involving long distance providers in POTS emergency calls. They >>>>>> are neither >>>>>> necessary nor particularly helpful; they can't be guaranteed to >>>>>> be within >>>>>> the >>>>>> emergency jurisdiction; depending on them actually diminishes the >>>>>> efficacy >>>>>> of >>>>>> emergency service access. It does not help the caller, the >>>>>> emergency >>>>>> service, >>>>>> nor the third party to insist on the third party's involvement. >>>>>> >>>>>> It can't be helped if you have over sold the benefits of VSP >>>>>> involvement to >>>>>> yourself and others Brian. It is time to have a reasoned debate. >>>>>> From my >>>>>> perspective, the argument that there is no "subscription" >>>>>> involved is >>>>>> patently >>>>>> false. There has to be a subscription of some description in >>>>>> order to get to >>>>>> the Internet. Yes, there is free public Internet access (just as >>>>>> there are >>>>>> free courtesy phones on the PSTN and free access to emergency >>>>>> services from >>>>>> pay phones. All these services are still connected to the public >>>>>> Internet >>>>>> infrastructure and they all represent an "operator" with some >>>>>> level of >>>>>> information about the caller. >>>>>> >>>>>> With the over-emphasis on VSPs, what is missing from the ECRIT >>>>>> and i3 models >>>>>> is the direct interface for querying the access network for >>>>>> subscriber data >>>>>> (should it prove necessary). These models need to take the long >>>>>> view of how >>>>>> emergency calling is done in the Internet age; they should not be >>>>>> protracting >>>>>> an unnecessary reliance on VSPs. >>>>>> >>>>>> I have deleted the premature and prejudicial text from the >>>>>> subject heading. >>>>>> And I'll leave this on ECRIT as the most appropriate WG. >>>>>> >>>>>> Cheers, >>>>>> Martin >>>>>> >>>>>> -----Original Message----- >>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>>>> Behalf Of >>>>>> Hannes Tschofenig >>>>>> Sent: Tuesday, 27 October 2009 8:23 AM >>>>>> To: ecrit@ietf.org >>>>>> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>>>> considered harmful, >>>>>> at least given our current experiences >>>>>> >>>>>> FYI: feedback from Brian regarding a recent ECRIT contribution. >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: geopriv-bounces@ietf.org >>>>>>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian >>>>>>> Sent: 26 October, 2009 23:10 >>>>>>> To: geopriv@ietf.org >>>>>>> Subject: [Geopriv] Winterbottom-ecrit-direct considered >>>>>>> harmful, at least given our current experiences >>>>>>> >>>>>>> The notion behind -direct is to not use a service provider to >>>>>>> place an emergency call. Instead, the device registers with >>>>>>> an Emergency Services Routing Proxy immediately before the >>>>>>> call and the call is routed directly from the device to the ESRP. >>>>>>> >>>>>>> At least at the moment, this is an exceedingly bad idea. >>>>>>> >>>>>>> Emergency calling authorities like service providers, a lot. >>>>>>> They like them because they can hold them accountable, and the >>>>>>> service providers don't like theft of service, which is >>>>>>> something the emergency call guys have an analog to. >>>>>>> >>>>>>> The facts are that where unaccountable access to emergency >>>>>>> calling is allowed, huge numbers of false calls occur, with no >>>>>>> way to stop them, and no way to tell the good ones from the >>>>>>> bad ones. This has been seen multiple times where so called >>>>>>> "simless" or "unauthenticated" calls are allowed. >>>>>>> >>>>>>> -direct precisely duplicates simless calling. The only >>>>>>> "registration" is an emergency registration, only emergency >>>>>>> calls are allowed, any device can make an emergency call if >>>>>>> all it has is a (radio) connection to any network. >>>>>>> We can predict, with a very high degree of certainty, that the >>>>>>> feature will be horribly abused: for example to test that a >>>>>>> phone without a service plan works. >>>>>>> >>>>>>> There have been studies which show tens of thousands of bad >>>>>>> calls with zero good ones. Nearly every authority I know >>>>>>> where the regulator has insisted on simless calling wants it >>>>>>> repealed. There is one counter example I know where the fact >>>>>>> that they got a couple, literally, of good calls among the >>>>>>> tens of thousands of bad calls was considered enough reason to >>>>>>> put up with the problem. >>>>>>> >>>>>>> Service providers give us information that may be useful: a >>>>>>> subscriber name and address for example, which is not >>>>>>> spoofable by the caller. They have ways to trace callers, >>>>>>> especially bad callers. They don't want their systems abused >>>>>>> any more than the emergency calling authorities do. >>>>>>> >>>>>>> This is a bad idea. A very bad idea. Please stop it. >>>>>>> >>>>>>> Someday, we may have better ways to prevent abuse. Until we >>>>>>> do, service providers are a good thing on an emergency call. >>>>>>> We don't want them cut out. >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Geopriv mailing list >>>>>>> Geopriv@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/geopriv >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> > > From mlinsner@cisco.com Wed Oct 28 15:51:31 2009 Return-Path: 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 7DF803A690D for ; Wed, 28 Oct 2009 15:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.746 X-Spam-Level: X-Spam-Status: No, score=-5.746 tagged_above=-999 required=5 tests=[AWL=-0.543, BAYES_00=-2.599, 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 52Wb8YHxLh4H for ; Wed, 28 Oct 2009 15:51:30 -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 A80C13A6781 for ; Wed, 28 Oct 2009 15:51:30 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMFAO9n6EpAZnwN/2dsb2JhbACaGah3mCeEPwQ X-IronPort-AV: E=Sophos;i="4.44,642,1249257600"; d="scan'208";a="65386009" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 28 Oct 2009 22:51:45 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9SMpjiM013146; Wed, 28 Oct 2009 22:51:45 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 18:51:45 -0400 Received: from [10.116.195.121] ([10.116.195.121]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 18:51:45 -0400 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 28 Oct 2009 18:51:42 -0400 From: Marc Linsner To: "Thomson, Martin" , "Winterbottom, James" , "ecrit@ietf.org" Message-ID: Thread-Topic: draft-winterbottom-ecrit-direct Thread-Index: AcpXzqBvSdLImAXqgkOL97H+2d+SrgASd9dAAAIt5vw= In-Reply-To: <8B0A9FCBB9832F43971E38010638454F0F251759@SISPE7MB1.commscope.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 28 Oct 2009 22:51:45.0252 (UTC) FILETIME=[39550A40:01CA5821] Subject: Re: [Ecrit] draft-winterbottom-ecrit-direct 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: , X-List-Received-Date: Wed, 28 Oct 2009 22:51:31 -0000 Martin, Thanks! -Marc- On 10/28/09 5:57 PM, "Thomson, Martin" wrote: > Hi Marc, >=20 > Just on the one point: >=20 >> C) =A0Longer term =8Ccall-back=B9, outside the suggested 60 minutes, would not= be >> possible due to lack of UA AOR information. >=20 > This is one aspect that could be made clearer. It should be: >=20 > [[The existing statement is to this effect: The ESRP/registrar > selects a registration period based on local policy.]] The > emergency client MUST accept a registration for at least 60 minutes, > but MAY accept longer registrations based on its own policy. >=20 > (I=B9ll note that this is virtually identical to the mechanism adopted by 3= GPP > for emergency registrations, except for the recognition that a client is > permitted to set policy in this regard also.) >=20 > --Martin=20 From br@brianrosen.net Wed Oct 28 20:17:53 2009 Return-Path: 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 8B8A728C119 for ; Wed, 28 Oct 2009 20:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.126 X-Spam-Level: X-Spam-Status: No, score=-2.126 tagged_above=-999 required=5 tests=[AWL=0.473, 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 wtQhyRw2BMAS for ; Wed, 28 Oct 2009 20:17:51 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id A35803A688F for ; Wed, 28 Oct 2009 20:17:51 -0700 (PDT) Received: from [209.173.57.233] (helo=[192.168.130.45]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1N3LWT-0005lx-Ln; Wed, 28 Oct 2009 22:18:06 -0500 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 28 Oct 2009 23:17:49 -0400 From: Brian Rosen To: Marc Linsner Message-ID: Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Thu, 29 Oct 2009 03:17:53 -0000 I'm not worried about security by obscurity. I don't want phones (or other devices) built to call directly. -phonebcp says "send the call on your normal outbound call path". That's what I want it to say, and I don't want it to say "send it direct, bypass your service provider. I'm not stopping attack, I am stopping abuse. I don't want devices that are not subscribed to services to be able to make emergency calls (that is, if they can't make "normal" calls, they should not be able to make emergency calls). Brian On 10/28/09 6:51 PM, "Marc Linsner" wrote: > Brian, > > What I hear you saying: 'if we don't document how to spoof a PSAP, then > nobody will figure it out.' Isn't that a little short sighted? > > Joey@miscreant.org will figure out how to establish a SIP session with any > PSAP in the world within 10 minutes of that PSAP being accessible via the > Internet, regardless of documentation. > > I believe there's more harm created in not documenting this for > John.Q.Public@ordinary_citizen.com. > > Granted, nobody here is looking to cause harm to a PSAP. But > Joey@miscreant.org can certainly expend public safety resources by reporting > a bomb threat to a local school. Should we require that all SIP calls to > the local school come from a trusted SP? Where does it end? > > This isn't the way to deal with spam. > > -Marc- > > > > On 10/27/09 11:00 AM, "Brian Rosen" wrote: > >> The first goal is to prevent bad calls. >> >> The second goal is to indentify the source of the bad calls. >> >> I'm starting with the first goal. I don't want you to be able to take a >> device out of a box, plug it into a network, and have the only call you can >> make be an emergency call. I want the device to actually "work" (as in be >> able to place calls to all the entities that it was intended to) first, and >> then be able to place emergency calls. >> >> Please spend some time in a PSAP while a kid with a simless phone has "fun" >> with it. Imagine how much fun the test mechanism is as opposed to placing >> real calls. >> >> If we somehow get a bad call, we need to send the cops. That means we need >> an identity (and a location). >> >> I think a good cert could be the basis of a good identity, if we could get >> one. I don't see how we do that. >> >> Brian >> >> >> On 10/27/09 10:39 AM, "Richard Barnes" wrote: >> >>> Brian, >>> >>> Is the security goal here more access control (i.e., controlling who >>> can send calls to a PSAP) or attribution/identification for post-hoc >>> action. >>> >>> If it's the latter, then ISTM that the problem can largely be reduced >>> to having a certificate infrastructure that binds authenticated >>> identities to real-world entities. The "extended validation" >>> certificates that current commercial CAs issue seem to largely satisfy >>> this requirement. >>> >>> --Richard >>> >>> >>> On Oct 27, 2009, at 4:31 PM, Brian Rosen wrote: >>> >>>> Of course not all VSPs will have trust relationships with all >>>> PSAPs. One >>>> can hope that long term, we can evolve to transitive trust >>>> relationships >>>> that work pretty well cross border. >>>> >>>> The emergency guys are actually terrified of private/individual >>>> domains >>>> sending them calls, and we're telling them we expect that to be >>>> possible, >>>> but rare, and we're giving them mechanisms that will effectively >>>> allow them >>>> to turn off calls selectively, based on factors including what >>>> domain the >>>> call comes from. They expect that such calls will be one of the >>>> loopholes >>>> where they get equivalents to sim-less calls, which drive them >>>> nuts. They >>>> don't want ANY calls that don't come from service providers, >>>> although they >>>> seem to be okay with the notion that the SP may not have great >>>> identity (AOL >>>> being a poster child). So, while indeed they understand, and have >>>> concerns >>>> about having to take calls from Sierra Leone VoIP services Pty, they >>>> would >>>> much rather have a call that went through them then a call that went >>>> through >>>> no service provider at all. >>>> >>>> I'm not trying to make calls direct from devices or private domains >>>> impossible, but I think the notion that we're promoting them is a >>>> very bad >>>> idea until we have effective mechanisms to prevent abuse. >>>> >>>> Brian >>>> >>>> >>>> >>>> >>>> On 10/27/09 9:02 AM, "Marc Linsner" wrote: >>>> >>>>> Brian, >>>>> >>>>> I'm a little confused. I don't remember you objecting to >>>>> requirement RE1 >>>>> from RFC5012 and I remember your use case about a Sierra Leone VSP. >>>>> >>>>> Are you implying that *all* VSPs will have a trust relationships >>>>> with *all* >>>>> PSAPs? >>>>> >>>>> What is the difference between a call coming from a private/ >>>>> individual >>>>> domain (as in not a commercial VSP) and a VSP on the other side of >>>>> the world >>>>> (outside the jurisdiction)? >>>>> >>>>> I'm trying to figure out whether you're objecting to anonymous >>>>> calls to the >>>>> PSAP or the mechanisms proposed in this draft? >>>>> >>>>> [Don't take this as my endorsement of the draft, as I'm not sure I >>>>> agree >>>>> with UAs registering with the ESRP.] >>>>> >>>>> -Marc- >>>>> >>>>> >>>>> On 10/26/09 8:59 PM, "Brian Rosen" wrote: >>>>> >>>>>> First of all, I put it on the wrong email list, sorry about that. >>>>>> >>>>>> Then, we have carefully arranged it so that there is no identity >>>>>> coming from >>>>>> the access network provider, and because the location is coming >>>>>> from that >>>>>> provider, we really don't want to. But even if we did, we would >>>>>> need a >>>>>> really good identifier, and there isn't one. >>>>>> >>>>>> The problem we have with -direct is anonymous callers, and if they >>>>>> have any >>>>>> option, they would also be location-less. Until and unless we get >>>>>> rid of >>>>>> anonymity, we can't encourage service provider-less calls. The >>>>>> draft does >>>>>> not make any provision to provide any kind of identity. Many >>>>>> networks >>>>>> (think free wifi for example) would make providing good identity >>>>>> difficult. >>>>>> >>>>>> The fact is that there is a SERVICE provider in nearly all of the >>>>>> communications systems. The SERVICE provider is in a position to >>>>>> assist >>>>>> the emergency calling system when it needs more information. >>>>>> That's what a >>>>>> good SERVICE provider does. Cutting them out is not a great >>>>>> idea. Most of >>>>>> the attempts to provide real time communications between people >>>>>> have evolved >>>>>> to using service providers, even when there were alternatives. File >>>>>> transfer via something like Torrent is a counterexample (which >>>>>> isn't real >>>>>> time), but even there, you end up with service providers like The >>>>>> Pirate Bay >>>>>> (R.I.P) to provide introduction services. I don't think we're >>>>>> going to see >>>>>> changes that eliminate service providers, and in this case, they >>>>>> provide >>>>>> value to the emergency calling systems. All of the emergency >>>>>> professionals >>>>>> I know have issues with service providers, but they would react >>>>>> with horror >>>>>> if you suggested cutting them out. Ask them, please. >>>>>> >>>>>> So, I claim you have a solution in search of a problem. We have >>>>>> solved the >>>>>> "calling network isn't the access network" problem already. Service >>>>>> providers ARE in the path now, in nearly every case (in fact a >>>>>> counter >>>>>> example escapes me, although there probably are some). There is >>>>>> no movement >>>>>> I can detect which would change that any time soon; quite the >>>>>> opposite. We >>>>>> have a known killer problem without some kind of subscription to a >>>>>> service >>>>>> that provides a good identity, for which you provide no answers. >>>>>> We have >>>>>> experience with the killer problem: sim-less calling was supposed >>>>>> to provide >>>>>> a way to make an emergency call in exactly the kinds of >>>>>> circumstances you >>>>>> are describing. Our real world experience is that you create a >>>>>> huge problem >>>>>> that diverts resources from helping people to chasing scammers and >>>>>> flea-market sellers. >>>>>> >>>>>> Nothing is perfect: you can get a AIM screen name without a very >>>>>> good >>>>>> identity for example. However, the notion that we're going to >>>>>> provide >>>>>> direct access without a service provider deliberately, especially >>>>>> without >>>>>> really good identity from the access network is, in my opinion not >>>>>> only a >>>>>> no, it's a heck no. I'll line up as many emergency service >>>>>> professionals as >>>>>> you would like to tell you this is a harmful idea. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 10/26/09 7:56 PM, "Dawson, Martin" >>>>>> wrote: >>>>>> >>>>>>> I am glad this has come up. It's a debate that has to happen if >>>>>>> we are to >>>>>>> move >>>>>>> beyond a long standing legacy misconception. >>>>>>> >>>>>>> In the circuit service world - whether it was POTS or mobile, the >>>>>>> access >>>>>>> network had full responsibility for delivering the emergency >>>>>>> call. In that >>>>>>> world, routing an emergency call meant getting a circuit >>>>>>> established to the >>>>>>> correct call center. In most parts of the world, this was done >>>>>>> using the >>>>>>> regional part of the PSTN to switch the circuit to a call center >>>>>>> on the >>>>>>> PSTN. >>>>>>> In some jurisdictions, such as the US, it was done directly from >>>>>>> the local >>>>>>> exchange carrier to the call center. Either way, there was no >>>>>>> third party >>>>>>> involved. >>>>>>> >>>>>>> Now we have the Internet. We still have public access network >>>>>>> providers. >>>>>>> They >>>>>>> switch packets onto the Internet for their subscribers. They can >>>>>>> similarly >>>>>>> ensure that packets reach the local emergency call centers. >>>>>>> >>>>>>> The fact is that there was no equivalent of a VSP in the >>>>>>> traditional >>>>>>> environment. VoIP is a presence service, and it had no common >>>>>>> equivalent in >>>>>>> the PSTN world. It could have, but the narrowband state of >>>>>>> technology and >>>>>>> the >>>>>>> common market use cases didn't support its development. By the >>>>>>> time ISDN >>>>>>> arrived, the PSTN had already slipped into its palliative stage >>>>>>> without >>>>>>> realizing it. >>>>>>> >>>>>>> It's an entrenched misconception that because the circuit service >>>>>>> provided >>>>>>> by >>>>>>> exchange carriers was most commonly used for "voice" (but, it >>>>>>> should be >>>>>>> noted, >>>>>>> also for fax, telex, tty, security system monitoring and, even, >>>>>>> IP data) >>>>>>> that >>>>>>> VSPs are somehow equivalent to exchange carriers. They are not. >>>>>>> >>>>>>> Indeed, involving VSPs in emergency calls is the Internet >>>>>>> equivalent of >>>>>>> involving long distance providers in POTS emergency calls. They >>>>>>> are neither >>>>>>> necessary nor particularly helpful; they can't be guaranteed to >>>>>>> be within >>>>>>> the >>>>>>> emergency jurisdiction; depending on them actually diminishes the >>>>>>> efficacy >>>>>>> of >>>>>>> emergency service access. It does not help the caller, the >>>>>>> emergency >>>>>>> service, >>>>>>> nor the third party to insist on the third party's involvement. >>>>>>> >>>>>>> It can't be helped if you have over sold the benefits of VSP >>>>>>> involvement to >>>>>>> yourself and others Brian. It is time to have a reasoned debate. >>>>>>> From my >>>>>>> perspective, the argument that there is no "subscription" >>>>>>> involved is >>>>>>> patently >>>>>>> false. There has to be a subscription of some description in >>>>>>> order to get to >>>>>>> the Internet. Yes, there is free public Internet access (just as >>>>>>> there are >>>>>>> free courtesy phones on the PSTN and free access to emergency >>>>>>> services from >>>>>>> pay phones. All these services are still connected to the public >>>>>>> Internet >>>>>>> infrastructure and they all represent an "operator" with some >>>>>>> level of >>>>>>> information about the caller. >>>>>>> >>>>>>> With the over-emphasis on VSPs, what is missing from the ECRIT >>>>>>> and i3 models >>>>>>> is the direct interface for querying the access network for >>>>>>> subscriber data >>>>>>> (should it prove necessary). These models need to take the long >>>>>>> view of how >>>>>>> emergency calling is done in the Internet age; they should not be >>>>>>> protracting >>>>>>> an unnecessary reliance on VSPs. >>>>>>> >>>>>>> I have deleted the premature and prejudicial text from the >>>>>>> subject heading. >>>>>>> And I'll leave this on ECRIT as the most appropriate WG. >>>>>>> >>>>>>> Cheers, >>>>>>> Martin >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>>>>> Behalf Of >>>>>>> Hannes Tschofenig >>>>>>> Sent: Tuesday, 27 October 2009 8:23 AM >>>>>>> To: ecrit@ietf.org >>>>>>> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>>>>> considered harmful, >>>>>>> at least given our current experiences >>>>>>> >>>>>>> FYI: feedback from Brian regarding a recent ECRIT contribution. >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: geopriv-bounces@ietf.org >>>>>>>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian >>>>>>>> Sent: 26 October, 2009 23:10 >>>>>>>> To: geopriv@ietf.org >>>>>>>> Subject: [Geopriv] Winterbottom-ecrit-direct considered >>>>>>>> harmful, at least given our current experiences >>>>>>>> >>>>>>>> The notion behind -direct is to not use a service provider to >>>>>>>> place an emergency call. Instead, the device registers with >>>>>>>> an Emergency Services Routing Proxy immediately before the >>>>>>>> call and the call is routed directly from the device to the ESRP. >>>>>>>> >>>>>>>> At least at the moment, this is an exceedingly bad idea. >>>>>>>> >>>>>>>> Emergency calling authorities like service providers, a lot. >>>>>>>> They like them because they can hold them accountable, and the >>>>>>>> service providers don't like theft of service, which is >>>>>>>> something the emergency call guys have an analog to. >>>>>>>> >>>>>>>> The facts are that where unaccountable access to emergency >>>>>>>> calling is allowed, huge numbers of false calls occur, with no >>>>>>>> way to stop them, and no way to tell the good ones from the >>>>>>>> bad ones. This has been seen multiple times where so called >>>>>>>> "simless" or "unauthenticated" calls are allowed. >>>>>>>> >>>>>>>> -direct precisely duplicates simless calling. The only >>>>>>>> "registration" is an emergency registration, only emergency >>>>>>>> calls are allowed, any device can make an emergency call if >>>>>>>> all it has is a (radio) connection to any network. >>>>>>>> We can predict, with a very high degree of certainty, that the >>>>>>>> feature will be horribly abused: for example to test that a >>>>>>>> phone without a service plan works. >>>>>>>> >>>>>>>> There have been studies which show tens of thousands of bad >>>>>>>> calls with zero good ones. Nearly every authority I know >>>>>>>> where the regulator has insisted on simless calling wants it >>>>>>>> repealed. There is one counter example I know where the fact >>>>>>>> that they got a couple, literally, of good calls among the >>>>>>>> tens of thousands of bad calls was considered enough reason to >>>>>>>> put up with the problem. >>>>>>>> >>>>>>>> Service providers give us information that may be useful: a >>>>>>>> subscriber name and address for example, which is not >>>>>>>> spoofable by the caller. They have ways to trace callers, >>>>>>>> especially bad callers. They don't want their systems abused >>>>>>>> any more than the emergency calling authorities do. >>>>>>>> >>>>>>>> This is a bad idea. A very bad idea. Please stop it. >>>>>>>> >>>>>>>> Someday, we may have better ways to prevent abuse. Until we >>>>>>>> do, service providers are a good thing on an emergency call. >>>>>>>> We don't want them cut out. >>>>>>>> >>>>>>>> Brian >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Geopriv mailing list >>>>>>>> Geopriv@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> >> >> > > From James.Winterbottom@andrew.com Wed Oct 28 22:58:30 2009 Return-Path: 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 F41513A69EB for ; Wed, 28 Oct 2009 22:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.114 X-Spam-Level: X-Spam-Status: No, score=-2.114 tagged_above=-999 required=5 tests=[AWL=0.485, 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 unugc2OvT1QT for ; Wed, 28 Oct 2009 22:58:28 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id D8F273A69D8 for ; Wed, 28 Oct 2009 22:58:27 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:51427 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S70463AbZJ2F6n convert rfc822-to-8bit (ORCPT ); Thu, 29 Oct 2009 00:58:43 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.393.1; Thu, 29 Oct 2009 00:58:43 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Thu, 29 Oct 2009 13:58:40 +0800 From: "Winterbottom, James" To: Brian Rosen , Marc Linsner Date: Thu, 29 Oct 2009 13:58:38 +0800 Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4ABX+qcA== Message-ID: <5A55A45AE77F5941B18E5457ECAC8188011EB8E419A2@SISPE7MB1.commscope.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Thu, 29 Oct 2009 05:58:30 -0000 My nintendo DS doesn't have a normal call provider! Nor does my smart fridge, nor will a whole range of devices quite capable of transmitting speech over IP connections. I want these to be able to make emergency calls if they need to. We are not in competition, you want to remain in a legacy world with VSPs, fine, I want to move past that. Emergency networks are not an add-on to standards call networks, they are their own network and application. Cheers James > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Brian Rosen > Sent: Thursday, 29 October 2009 2:18 PM > To: Marc Linsner > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered > > I'm not worried about security by obscurity. I don't want phones (or > other > devices) built to call directly. > > -phonebcp says "send the call on your normal outbound call path". That's > what I want it to say, and I don't want it to say "send it direct, bypass > your service provider. > > I'm not stopping attack, I am stopping abuse. > > I don't want devices that are not subscribed to services to be able to > make > emergency calls (that is, if they can't make "normal" calls, they should > not > be able to make emergency calls). > > Brian > > > On 10/28/09 6:51 PM, "Marc Linsner" wrote: > > > Brian, > > > > What I hear you saying: 'if we don't document how to spoof a PSAP, then > > nobody will figure it out.' Isn't that a little short sighted? > > > > Joey@miscreant.org will figure out how to establish a SIP session with > any > > PSAP in the world within 10 minutes of that PSAP being accessible via > the > > Internet, regardless of documentation. > > > > I believe there's more harm created in not documenting this for > > John.Q.Public@ordinary_citizen.com. > > > > Granted, nobody here is looking to cause harm to a PSAP. But > > Joey@miscreant.org can certainly expend public safety resources by > reporting > > a bomb threat to a local school. Should we require that all SIP calls > to > > the local school come from a trusted SP? Where does it end? > > > > This isn't the way to deal with spam. > > > > -Marc- > > > > > > > > On 10/27/09 11:00 AM, "Brian Rosen" wrote: > > > >> The first goal is to prevent bad calls. > >> > >> The second goal is to indentify the source of the bad calls. > >> > >> I'm starting with the first goal. I don't want you to be able to take > a > >> device out of a box, plug it into a network, and have the only call you > can > >> make be an emergency call. I want the device to actually "work" (as in > be > >> able to place calls to all the entities that it was intended to) first, > and > >> then be able to place emergency calls. > >> > >> Please spend some time in a PSAP while a kid with a simless phone has > "fun" > >> with it. Imagine how much fun the test mechanism is as opposed to > placing > >> real calls. > >> > >> If we somehow get a bad call, we need to send the cops. That means we > need > >> an identity (and a location). > >> > >> I think a good cert could be the basis of a good identity, if we could > get > >> one. I don't see how we do that. > >> > >> Brian > >> > >> > >> On 10/27/09 10:39 AM, "Richard Barnes" wrote: > >> > >>> Brian, > >>> > >>> Is the security goal here more access control (i.e., controlling who > >>> can send calls to a PSAP) or attribution/identification for post-hoc > >>> action. > >>> > >>> If it's the latter, then ISTM that the problem can largely be reduced > >>> to having a certificate infrastructure that binds authenticated > >>> identities to real-world entities. The "extended validation" > >>> certificates that current commercial CAs issue seem to largely satisfy > >>> this requirement. > >>> > >>> --Richard > >>> > >>> > >>> On Oct 27, 2009, at 4:31 PM, Brian Rosen wrote: > >>> > >>>> Of course not all VSPs will have trust relationships with all > >>>> PSAPs. One > >>>> can hope that long term, we can evolve to transitive trust > >>>> relationships > >>>> that work pretty well cross border. > >>>> > >>>> The emergency guys are actually terrified of private/individual > >>>> domains > >>>> sending them calls, and we're telling them we expect that to be > >>>> possible, > >>>> but rare, and we're giving them mechanisms that will effectively > >>>> allow them > >>>> to turn off calls selectively, based on factors including what > >>>> domain the > >>>> call comes from. They expect that such calls will be one of the > >>>> loopholes > >>>> where they get equivalents to sim-less calls, which drive them > >>>> nuts. They > >>>> don't want ANY calls that don't come from service providers, > >>>> although they > >>>> seem to be okay with the notion that the SP may not have great > >>>> identity (AOL > >>>> being a poster child). So, while indeed they understand, and have > >>>> concerns > >>>> about having to take calls from Sierra Leone VoIP services Pty, they > >>>> would > >>>> much rather have a call that went through them then a call that went > >>>> through > >>>> no service provider at all. > >>>> > >>>> I'm not trying to make calls direct from devices or private domains > >>>> impossible, but I think the notion that we're promoting them is a > >>>> very bad > >>>> idea until we have effective mechanisms to prevent abuse. > >>>> > >>>> Brian > >>>> > >>>> > >>>> > >>>> > >>>> On 10/27/09 9:02 AM, "Marc Linsner" wrote: > >>>> > >>>>> Brian, > >>>>> > >>>>> I'm a little confused. I don't remember you objecting to > >>>>> requirement RE1 > >>>>> from RFC5012 and I remember your use case about a Sierra Leone VSP. > >>>>> > >>>>> Are you implying that *all* VSPs will have a trust relationships > >>>>> with *all* > >>>>> PSAPs? > >>>>> > >>>>> What is the difference between a call coming from a private/ > >>>>> individual > >>>>> domain (as in not a commercial VSP) and a VSP on the other side of > >>>>> the world > >>>>> (outside the jurisdiction)? > >>>>> > >>>>> I'm trying to figure out whether you're objecting to anonymous > >>>>> calls to the > >>>>> PSAP or the mechanisms proposed in this draft? > >>>>> > >>>>> [Don't take this as my endorsement of the draft, as I'm not sure I > >>>>> agree > >>>>> with UAs registering with the ESRP.] > >>>>> > >>>>> -Marc- > >>>>> > >>>>> > >>>>> On 10/26/09 8:59 PM, "Brian Rosen" wrote: > >>>>> > >>>>>> First of all, I put it on the wrong email list, sorry about that. > >>>>>> > >>>>>> Then, we have carefully arranged it so that there is no identity > >>>>>> coming from > >>>>>> the access network provider, and because the location is coming > >>>>>> from that > >>>>>> provider, we really don't want to. But even if we did, we would > >>>>>> need a > >>>>>> really good identifier, and there isn't one. > >>>>>> > >>>>>> The problem we have with -direct is anonymous callers, and if they > >>>>>> have any > >>>>>> option, they would also be location-less. Until and unless we get > >>>>>> rid of > >>>>>> anonymity, we can't encourage service provider-less calls. The > >>>>>> draft does > >>>>>> not make any provision to provide any kind of identity. Many > >>>>>> networks > >>>>>> (think free wifi for example) would make providing good identity > >>>>>> difficult. > >>>>>> > >>>>>> The fact is that there is a SERVICE provider in nearly all of the > >>>>>> communications systems. The SERVICE provider is in a position to > >>>>>> assist > >>>>>> the emergency calling system when it needs more information. > >>>>>> That's what a > >>>>>> good SERVICE provider does. Cutting them out is not a great > >>>>>> idea. Most of > >>>>>> the attempts to provide real time communications between people > >>>>>> have evolved > >>>>>> to using service providers, even when there were alternatives. > File > >>>>>> transfer via something like Torrent is a counterexample (which > >>>>>> isn't real > >>>>>> time), but even there, you end up with service providers like The > >>>>>> Pirate Bay > >>>>>> (R.I.P) to provide introduction services. I don't think we're > >>>>>> going to see > >>>>>> changes that eliminate service providers, and in this case, they > >>>>>> provide > >>>>>> value to the emergency calling systems. All of the emergency > >>>>>> professionals > >>>>>> I know have issues with service providers, but they would react > >>>>>> with horror > >>>>>> if you suggested cutting them out. Ask them, please. > >>>>>> > >>>>>> So, I claim you have a solution in search of a problem. We have > >>>>>> solved the > >>>>>> "calling network isn't the access network" problem already. > Service > >>>>>> providers ARE in the path now, in nearly every case (in fact a > >>>>>> counter > >>>>>> example escapes me, although there probably are some). There is > >>>>>> no movement > >>>>>> I can detect which would change that any time soon; quite the > >>>>>> opposite. We > >>>>>> have a known killer problem without some kind of subscription to a > >>>>>> service > >>>>>> that provides a good identity, for which you provide no answers. > >>>>>> We have > >>>>>> experience with the killer problem: sim-less calling was supposed > >>>>>> to provide > >>>>>> a way to make an emergency call in exactly the kinds of > >>>>>> circumstances you > >>>>>> are describing. Our real world experience is that you create a > >>>>>> huge problem > >>>>>> that diverts resources from helping people to chasing scammers and > >>>>>> flea-market sellers. > >>>>>> > >>>>>> Nothing is perfect: you can get a AIM screen name without a very > >>>>>> good > >>>>>> identity for example. However, the notion that we're going to > >>>>>> provide > >>>>>> direct access without a service provider deliberately, especially > >>>>>> without > >>>>>> really good identity from the access network is, in my opinion not > >>>>>> only a > >>>>>> no, it's a heck no. I'll line up as many emergency service > >>>>>> professionals as > >>>>>> you would like to tell you this is a harmful idea. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> On 10/26/09 7:56 PM, "Dawson, Martin" > >>>>>> wrote: > >>>>>> > >>>>>>> I am glad this has come up. It's a debate that has to happen if > >>>>>>> we are to > >>>>>>> move > >>>>>>> beyond a long standing legacy misconception. > >>>>>>> > >>>>>>> In the circuit service world - whether it was POTS or mobile, the > >>>>>>> access > >>>>>>> network had full responsibility for delivering the emergency > >>>>>>> call. In that > >>>>>>> world, routing an emergency call meant getting a circuit > >>>>>>> established to the > >>>>>>> correct call center. In most parts of the world, this was done > >>>>>>> using the > >>>>>>> regional part of the PSTN to switch the circuit to a call center > >>>>>>> on the > >>>>>>> PSTN. > >>>>>>> In some jurisdictions, such as the US, it was done directly from > >>>>>>> the local > >>>>>>> exchange carrier to the call center. Either way, there was no > >>>>>>> third party > >>>>>>> involved. > >>>>>>> > >>>>>>> Now we have the Internet. We still have public access network > >>>>>>> providers. > >>>>>>> They > >>>>>>> switch packets onto the Internet for their subscribers. They can > >>>>>>> similarly > >>>>>>> ensure that packets reach the local emergency call centers. > >>>>>>> > >>>>>>> The fact is that there was no equivalent of a VSP in the > >>>>>>> traditional > >>>>>>> environment. VoIP is a presence service, and it had no common > >>>>>>> equivalent in > >>>>>>> the PSTN world. It could have, but the narrowband state of > >>>>>>> technology and > >>>>>>> the > >>>>>>> common market use cases didn't support its development. By the > >>>>>>> time ISDN > >>>>>>> arrived, the PSTN had already slipped into its palliative stage > >>>>>>> without > >>>>>>> realizing it. > >>>>>>> > >>>>>>> It's an entrenched misconception that because the circuit service > >>>>>>> provided > >>>>>>> by > >>>>>>> exchange carriers was most commonly used for "voice" (but, it > >>>>>>> should be > >>>>>>> noted, > >>>>>>> also for fax, telex, tty, security system monitoring and, even, > >>>>>>> IP data) > >>>>>>> that > >>>>>>> VSPs are somehow equivalent to exchange carriers. They are not. > >>>>>>> > >>>>>>> Indeed, involving VSPs in emergency calls is the Internet > >>>>>>> equivalent of > >>>>>>> involving long distance providers in POTS emergency calls. They > >>>>>>> are neither > >>>>>>> necessary nor particularly helpful; they can't be guaranteed to > >>>>>>> be within > >>>>>>> the > >>>>>>> emergency jurisdiction; depending on them actually diminishes the > >>>>>>> efficacy > >>>>>>> of > >>>>>>> emergency service access. It does not help the caller, the > >>>>>>> emergency > >>>>>>> service, > >>>>>>> nor the third party to insist on the third party's involvement. > >>>>>>> > >>>>>>> It can't be helped if you have over sold the benefits of VSP > >>>>>>> involvement to > >>>>>>> yourself and others Brian. It is time to have a reasoned debate. > >>>>>>> From my > >>>>>>> perspective, the argument that there is no "subscription" > >>>>>>> involved is > >>>>>>> patently > >>>>>>> false. There has to be a subscription of some description in > >>>>>>> order to get to > >>>>>>> the Internet. Yes, there is free public Internet access (just as > >>>>>>> there are > >>>>>>> free courtesy phones on the PSTN and free access to emergency > >>>>>>> services from > >>>>>>> pay phones. All these services are still connected to the public > >>>>>>> Internet > >>>>>>> infrastructure and they all represent an "operator" with some > >>>>>>> level of > >>>>>>> information about the caller. > >>>>>>> > >>>>>>> With the over-emphasis on VSPs, what is missing from the ECRIT > >>>>>>> and i3 models > >>>>>>> is the direct interface for querying the access network for > >>>>>>> subscriber data > >>>>>>> (should it prove necessary). These models need to take the long > >>>>>>> view of how > >>>>>>> emergency calling is done in the Internet age; they should not be > >>>>>>> protracting > >>>>>>> an unnecessary reliance on VSPs. > >>>>>>> > >>>>>>> I have deleted the premature and prejudicial text from the > >>>>>>> subject heading. > >>>>>>> And I'll leave this on ECRIT as the most appropriate WG. > >>>>>>> > >>>>>>> Cheers, > >>>>>>> Martin > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >>>>>>> Behalf Of > >>>>>>> Hannes Tschofenig > >>>>>>> Sent: Tuesday, 27 October 2009 8:23 AM > >>>>>>> To: ecrit@ietf.org > >>>>>>> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct > >>>>>>> considered harmful, > >>>>>>> at least given our current experiences > >>>>>>> > >>>>>>> FYI: feedback from Brian regarding a recent ECRIT contribution. > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: geopriv-bounces@ietf.org > >>>>>>>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian > >>>>>>>> Sent: 26 October, 2009 23:10 > >>>>>>>> To: geopriv@ietf.org > >>>>>>>> Subject: [Geopriv] Winterbottom-ecrit-direct considered > >>>>>>>> harmful, at least given our current experiences > >>>>>>>> > >>>>>>>> The notion behind -direct is to not use a service provider to > >>>>>>>> place an emergency call. Instead, the device registers with > >>>>>>>> an Emergency Services Routing Proxy immediately before the > >>>>>>>> call and the call is routed directly from the device to the ESRP. > >>>>>>>> > >>>>>>>> At least at the moment, this is an exceedingly bad idea. > >>>>>>>> > >>>>>>>> Emergency calling authorities like service providers, a lot. > >>>>>>>> They like them because they can hold them accountable, and the > >>>>>>>> service providers don't like theft of service, which is > >>>>>>>> something the emergency call guys have an analog to. > >>>>>>>> > >>>>>>>> The facts are that where unaccountable access to emergency > >>>>>>>> calling is allowed, huge numbers of false calls occur, with no > >>>>>>>> way to stop them, and no way to tell the good ones from the > >>>>>>>> bad ones. This has been seen multiple times where so called > >>>>>>>> "simless" or "unauthenticated" calls are allowed. > >>>>>>>> > >>>>>>>> -direct precisely duplicates simless calling. The only > >>>>>>>> "registration" is an emergency registration, only emergency > >>>>>>>> calls are allowed, any device can make an emergency call if > >>>>>>>> all it has is a (radio) connection to any network. > >>>>>>>> We can predict, with a very high degree of certainty, that the > >>>>>>>> feature will be horribly abused: for example to test that a > >>>>>>>> phone without a service plan works. > >>>>>>>> > >>>>>>>> There have been studies which show tens of thousands of bad > >>>>>>>> calls with zero good ones. Nearly every authority I know > >>>>>>>> where the regulator has insisted on simless calling wants it > >>>>>>>> repealed. There is one counter example I know where the fact > >>>>>>>> that they got a couple, literally, of good calls among the > >>>>>>>> tens of thousands of bad calls was considered enough reason to > >>>>>>>> put up with the problem. > >>>>>>>> > >>>>>>>> Service providers give us information that may be useful: a > >>>>>>>> subscriber name and address for example, which is not > >>>>>>>> spoofable by the caller. They have ways to trace callers, > >>>>>>>> especially bad callers. They don't want their systems abused > >>>>>>>> any more than the emergency calling authorities do. > >>>>>>>> > >>>>>>>> This is a bad idea. A very bad idea. Please stop it. > >>>>>>>> > >>>>>>>> Someday, we may have better ways to prevent abuse. Until we > >>>>>>>> do, service providers are a good thing on an emergency call. > >>>>>>>> We don't want them cut out. > >>>>>>>> > >>>>>>>> Brian > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> Geopriv mailing list > >>>>>>>> Geopriv@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv > >>>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> 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 > >>>>> > >>>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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 john.elwell@siemens-enterprise.com Thu Oct 29 02:28:30 2009 Return-Path: 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 F394728C0F4 for ; Thu, 29 Oct 2009 02:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.039 X-Spam-Level: X-Spam-Status: No, score=-6.039 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 3lAHhxZQlCUY for ; Thu, 29 Oct 2009 02:28:28 -0700 (PDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by core3.amsl.com (Postfix) with ESMTP id 2E73F3A6A55 for ; Thu, 29 Oct 2009 02:28:27 -0700 (PDT) Received: from mail2.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9T9STnT000591; Thu, 29 Oct 2009 10:28:29 +0100 Received: from DEMCHP99ET1MSX.ww902.siemens.net (demchp99et1msx.ww902.siemens.net [139.25.131.180]) by mail2.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9T9STRO029722; Thu, 29 Oct 2009 10:28:29 +0100 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET1MSX.ww902.siemens.net ([139.25.131.180]) with mapi; Thu, 29 Oct 2009 10:28:28 +0100 From: "Elwell, John" To: Brian Rosen , Marc Linsner Date: Thu, 29 Oct 2009 10:28:36 +0100 Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4ADN3iYA== Message-ID: <7402509E63C5A145A6095D46C179A5B7148B380D@DEMCHP99E35MSX.ww902.siemens.net> References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Thu, 29 Oct 2009 09:28:30 -0000 Brian, Just a question for clarification below: > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Brian Rosen > Sent: 29 October 2009 03:18 > To: Marc Linsner > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct > considered > > I'm not worried about security by obscurity. I don't want > phones (or other > devices) built to call directly. > > -phonebcp says "send the call on your normal outbound call > path". That's > what I want it to say, and I don't want it to say "send it > direct, bypass > your service provider. [JRE] So if my normal outbound call path is my SIP-PBX, then the SIP-PBX ca= n route directly to the PSAP? John > > I'm not stopping attack, I am stopping abuse. > > I don't want devices that are not subscribed to services to > be able to make > emergency calls (that is, if they can't make "normal" calls, > they should not > be able to make emergency calls). > > Brian > > > On 10/28/09 6:51 PM, "Marc Linsner" wrote: > > > Brian, > > > > What I hear you saying: 'if we don't document how to spoof > a PSAP, then > > nobody will figure it out.' Isn't that a little short sighted? > > > > Joey@miscreant.org will figure out how to establish a SIP > session with any > > PSAP in the world within 10 minutes of that PSAP being > accessible via the > > Internet, regardless of documentation. > > > > I believe there's more harm created in not documenting this for > > John.Q.Public@ordinary_citizen.com. > > > > Granted, nobody here is looking to cause harm to a PSAP. But > > Joey@miscreant.org can certainly expend public safety > resources by reporting > > a bomb threat to a local school. Should we require that > all SIP calls to > > the local school come from a trusted SP? Where does it end? > > > > This isn't the way to deal with spam. > > > > -Marc- > > > > > > > > On 10/27/09 11:00 AM, "Brian Rosen" wrote: > > > >> The first goal is to prevent bad calls. > >> > >> The second goal is to indentify the source of the bad calls. > >> > >> I'm starting with the first goal. I don't want you to be > able to take a > >> device out of a box, plug it into a network, and have the > only call you can > >> make be an emergency call. I want the device to actually > "work" (as in be > >> able to place calls to all the entities that it was > intended to) first, and > >> then be able to place emergency calls. > >> > >> Please spend some time in a PSAP while a kid with a > simless phone has "fun" > >> with it. Imagine how much fun the test mechanism is as > opposed to placing > >> real calls. > >> > >> If we somehow get a bad call, we need to send the cops. > That means we need > >> an identity (and a location). > >> > >> I think a good cert could be the basis of a good identity, > if we could get > >> one. I don't see how we do that. > >> > >> Brian > >> > >> > >> On 10/27/09 10:39 AM, "Richard Barnes" wrote: > >> > >>> Brian, > >>> > >>> Is the security goal here more access control (i.e., > controlling who > >>> can send calls to a PSAP) or attribution/identification > for post-hoc > >>> action. > >>> > >>> If it's the latter, then ISTM that the problem can > largely be reduced > >>> to having a certificate infrastructure that binds authenticated > >>> identities to real-world entities. The "extended validation" > >>> certificates that current commercial CAs issue seem to > largely satisfy > >>> this requirement. > >>> > >>> --Richard > >>> > >>> > >>> On Oct 27, 2009, at 4:31 PM, Brian Rosen wrote: > >>> > >>>> Of course not all VSPs will have trust relationships with all > >>>> PSAPs. One > >>>> can hope that long term, we can evolve to transitive trust > >>>> relationships > >>>> that work pretty well cross border. > >>>> > >>>> The emergency guys are actually terrified of private/individual > >>>> domains > >>>> sending them calls, and we're telling them we expect that to be > >>>> possible, > >>>> but rare, and we're giving them mechanisms that will effectively > >>>> allow them > >>>> to turn off calls selectively, based on factors including what > >>>> domain the > >>>> call comes from. They expect that such calls will be one of the > >>>> loopholes > >>>> where they get equivalents to sim-less calls, which drive them > >>>> nuts. They > >>>> don't want ANY calls that don't come from service providers, > >>>> although they > >>>> seem to be okay with the notion that the SP may not have great > >>>> identity (AOL > >>>> being a poster child). So, while indeed they > understand, and have > >>>> concerns > >>>> about having to take calls from Sierra Leone VoIP > services Pty, they > >>>> would > >>>> much rather have a call that went through them then a > call that went > >>>> through > >>>> no service provider at all. > >>>> > >>>> I'm not trying to make calls direct from devices or > private domains > >>>> impossible, but I think the notion that we're promoting them is a > >>>> very bad > >>>> idea until we have effective mechanisms to prevent abuse. > >>>> > >>>> Brian > >>>> > >>>> > >>>> > >>>> > >>>> On 10/27/09 9:02 AM, "Marc Linsner" wrote: > >>>> > >>>>> Brian, > >>>>> > >>>>> I'm a little confused. I don't remember you objecting to > >>>>> requirement RE1 > >>>>> from RFC5012 and I remember your use case about a > Sierra Leone VSP. > >>>>> > >>>>> Are you implying that *all* VSPs will have a trust relationships > >>>>> with *all* > >>>>> PSAPs? > >>>>> > >>>>> What is the difference between a call coming from a private/ > >>>>> individual > >>>>> domain (as in not a commercial VSP) and a VSP on the > other side of > >>>>> the world > >>>>> (outside the jurisdiction)? > >>>>> > >>>>> I'm trying to figure out whether you're objecting to anonymous > >>>>> calls to the > >>>>> PSAP or the mechanisms proposed in this draft? > >>>>> > >>>>> [Don't take this as my endorsement of the draft, as I'm > not sure I > >>>>> agree > >>>>> with UAs registering with the ESRP.] > >>>>> > >>>>> -Marc- > >>>>> > >>>>> > >>>>> On 10/26/09 8:59 PM, "Brian Rosen" wrote: > >>>>> > >>>>>> First of all, I put it on the wrong email list, sorry > about that. > >>>>>> > >>>>>> Then, we have carefully arranged it so that there is > no identity > >>>>>> coming from > >>>>>> the access network provider, and because the location is coming > >>>>>> from that > >>>>>> provider, we really don't want to. But even if we > did, we would > >>>>>> need a > >>>>>> really good identifier, and there isn't one. > >>>>>> > >>>>>> The problem we have with -direct is anonymous callers, > and if they > >>>>>> have any > >>>>>> option, they would also be location-less. Until and > unless we get > >>>>>> rid of > >>>>>> anonymity, we can't encourage service provider-less calls. The > >>>>>> draft does > >>>>>> not make any provision to provide any kind of identity. Many > >>>>>> networks > >>>>>> (think free wifi for example) would make providing > good identity > >>>>>> difficult. > >>>>>> > >>>>>> The fact is that there is a SERVICE provider in nearly > all of the > >>>>>> communications systems. The SERVICE provider is in a > position to > >>>>>> assist > >>>>>> the emergency calling system when it needs more information. > >>>>>> That's what a > >>>>>> good SERVICE provider does. Cutting them out is not a great > >>>>>> idea. Most of > >>>>>> the attempts to provide real time communications between people > >>>>>> have evolved > >>>>>> to using service providers, even when there were > alternatives. File > >>>>>> transfer via something like Torrent is a counterexample (which > >>>>>> isn't real > >>>>>> time), but even there, you end up with service > providers like The > >>>>>> Pirate Bay > >>>>>> (R.I.P) to provide introduction services. I don't think we're > >>>>>> going to see > >>>>>> changes that eliminate service providers, and in this > case, they > >>>>>> provide > >>>>>> value to the emergency calling systems. All of the emergency > >>>>>> professionals > >>>>>> I know have issues with service providers, but they would react > >>>>>> with horror > >>>>>> if you suggested cutting them out. Ask them, please. > >>>>>> > >>>>>> So, I claim you have a solution in search of a > problem. We have > >>>>>> solved the > >>>>>> "calling network isn't the access network" problem > already. Service > >>>>>> providers ARE in the path now, in nearly every case (in fact a > >>>>>> counter > >>>>>> example escapes me, although there probably are some). > There is > >>>>>> no movement > >>>>>> I can detect which would change that any time soon; quite the > >>>>>> opposite. We > >>>>>> have a known killer problem without some kind of > subscription to a > >>>>>> service > >>>>>> that provides a good identity, for which you provide > no answers. > >>>>>> We have > >>>>>> experience with the killer problem: sim-less calling > was supposed > >>>>>> to provide > >>>>>> a way to make an emergency call in exactly the kinds of > >>>>>> circumstances you > >>>>>> are describing. Our real world experience is that you create a > >>>>>> huge problem > >>>>>> that diverts resources from helping people to chasing > scammers and > >>>>>> flea-market sellers. > >>>>>> > >>>>>> Nothing is perfect: you can get a AIM screen name > without a very > >>>>>> good > >>>>>> identity for example. However, the notion that we're going to > >>>>>> provide > >>>>>> direct access without a service provider deliberately, > especially > >>>>>> without > >>>>>> really good identity from the access network is, in my > opinion not > >>>>>> only a > >>>>>> no, it's a heck no. I'll line up as many emergency service > >>>>>> professionals as > >>>>>> you would like to tell you this is a harmful idea. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> On 10/26/09 7:56 PM, "Dawson, Martin" > > >>>>>> wrote: > >>>>>> > >>>>>>> I am glad this has come up. It's a debate that has to > happen if > >>>>>>> we are to > >>>>>>> move > >>>>>>> beyond a long standing legacy misconception. > >>>>>>> > >>>>>>> In the circuit service world - whether it was POTS or > mobile, the > >>>>>>> access > >>>>>>> network had full responsibility for delivering the emergency > >>>>>>> call. In that > >>>>>>> world, routing an emergency call meant getting a circuit > >>>>>>> established to the > >>>>>>> correct call center. In most parts of the world, this was done > >>>>>>> using the > >>>>>>> regional part of the PSTN to switch the circuit to a > call center > >>>>>>> on the > >>>>>>> PSTN. > >>>>>>> In some jurisdictions, such as the US, it was done > directly from > >>>>>>> the local > >>>>>>> exchange carrier to the call center. Either way, there was no > >>>>>>> third party > >>>>>>> involved. > >>>>>>> > >>>>>>> Now we have the Internet. We still have public access network > >>>>>>> providers. > >>>>>>> They > >>>>>>> switch packets onto the Internet for their > subscribers. They can > >>>>>>> similarly > >>>>>>> ensure that packets reach the local emergency call centers. > >>>>>>> > >>>>>>> The fact is that there was no equivalent of a VSP in the > >>>>>>> traditional > >>>>>>> environment. VoIP is a presence service, and it had no common > >>>>>>> equivalent in > >>>>>>> the PSTN world. It could have, but the narrowband state of > >>>>>>> technology and > >>>>>>> the > >>>>>>> common market use cases didn't support its development. By the > >>>>>>> time ISDN > >>>>>>> arrived, the PSTN had already slipped into its > palliative stage > >>>>>>> without > >>>>>>> realizing it. > >>>>>>> > >>>>>>> It's an entrenched misconception that because the > circuit service > >>>>>>> provided > >>>>>>> by > >>>>>>> exchange carriers was most commonly used for "voice" (but, it > >>>>>>> should be > >>>>>>> noted, > >>>>>>> also for fax, telex, tty, security system monitoring > and, even, > >>>>>>> IP data) > >>>>>>> that > >>>>>>> VSPs are somehow equivalent to exchange carriers. > They are not. > >>>>>>> > >>>>>>> Indeed, involving VSPs in emergency calls is the Internet > >>>>>>> equivalent of > >>>>>>> involving long distance providers in POTS emergency > calls. They > >>>>>>> are neither > >>>>>>> necessary nor particularly helpful; they can't be > guaranteed to > >>>>>>> be within > >>>>>>> the > >>>>>>> emergency jurisdiction; depending on them actually > diminishes the > >>>>>>> efficacy > >>>>>>> of > >>>>>>> emergency service access. It does not help the caller, the > >>>>>>> emergency > >>>>>>> service, > >>>>>>> nor the third party to insist on the third party's > involvement. > >>>>>>> > >>>>>>> It can't be helped if you have over sold the benefits of VSP > >>>>>>> involvement to > >>>>>>> yourself and others Brian. It is time to have a > reasoned debate. > >>>>>>> From my > >>>>>>> perspective, the argument that there is no "subscription" > >>>>>>> involved is > >>>>>>> patently > >>>>>>> false. There has to be a subscription of some description in > >>>>>>> order to get to > >>>>>>> the Internet. Yes, there is free public Internet > access (just as > >>>>>>> there are > >>>>>>> free courtesy phones on the PSTN and free access to emergency > >>>>>>> services from > >>>>>>> pay phones. All these services are still connected to > the public > >>>>>>> Internet > >>>>>>> infrastructure and they all represent an "operator" with some > >>>>>>> level of > >>>>>>> information about the caller. > >>>>>>> > >>>>>>> With the over-emphasis on VSPs, what is missing from the ECRIT > >>>>>>> and i3 models > >>>>>>> is the direct interface for querying the access network for > >>>>>>> subscriber data > >>>>>>> (should it prove necessary). These models need to > take the long > >>>>>>> view of how > >>>>>>> emergency calling is done in the Internet age; they > should not be > >>>>>>> protracting > >>>>>>> an unnecessary reliance on VSPs. > >>>>>>> > >>>>>>> I have deleted the premature and prejudicial text from the > >>>>>>> subject heading. > >>>>>>> And I'll leave this on ECRIT as the most appropriate WG. > >>>>>>> > >>>>>>> Cheers, > >>>>>>> Martin > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On > >>>>>>> Behalf Of > >>>>>>> Hannes Tschofenig > >>>>>>> Sent: Tuesday, 27 October 2009 8:23 AM > >>>>>>> To: ecrit@ietf.org > >>>>>>> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct > >>>>>>> considered harmful, > >>>>>>> at least given our current experiences > >>>>>>> > >>>>>>> FYI: feedback from Brian regarding a recent ECRIT > contribution. > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: geopriv-bounces@ietf.org > >>>>>>>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian > >>>>>>>> Sent: 26 October, 2009 23:10 > >>>>>>>> To: geopriv@ietf.org > >>>>>>>> Subject: [Geopriv] Winterbottom-ecrit-direct considered > >>>>>>>> harmful, at least given our current experiences > >>>>>>>> > >>>>>>>> The notion behind -direct is to not use a service provider to > >>>>>>>> place an emergency call. Instead, the device registers with > >>>>>>>> an Emergency Services Routing Proxy immediately before the > >>>>>>>> call and the call is routed directly from the device > to the ESRP. > >>>>>>>> > >>>>>>>> At least at the moment, this is an exceedingly bad idea. > >>>>>>>> > >>>>>>>> Emergency calling authorities like service providers, a lot. > >>>>>>>> They like them because they can hold them > accountable, and the > >>>>>>>> service providers don't like theft of service, which is > >>>>>>>> something the emergency call guys have an analog to. > >>>>>>>> > >>>>>>>> The facts are that where unaccountable access to emergency > >>>>>>>> calling is allowed, huge numbers of false calls > occur, with no > >>>>>>>> way to stop them, and no way to tell the good ones from the > >>>>>>>> bad ones. This has been seen multiple times where so called > >>>>>>>> "simless" or "unauthenticated" calls are allowed. > >>>>>>>> > >>>>>>>> -direct precisely duplicates simless calling. The only > >>>>>>>> "registration" is an emergency registration, only emergency > >>>>>>>> calls are allowed, any device can make an emergency call if > >>>>>>>> all it has is a (radio) connection to any network. > >>>>>>>> We can predict, with a very high degree of > certainty, that the > >>>>>>>> feature will be horribly abused: for example to test that a > >>>>>>>> phone without a service plan works. > >>>>>>>> > >>>>>>>> There have been studies which show tens of thousands of bad > >>>>>>>> calls with zero good ones. Nearly every authority I know > >>>>>>>> where the regulator has insisted on simless calling wants it > >>>>>>>> repealed. There is one counter example I know where the fact > >>>>>>>> that they got a couple, literally, of good calls among the > >>>>>>>> tens of thousands of bad calls was considered enough > reason to > >>>>>>>> put up with the problem. > >>>>>>>> > >>>>>>>> Service providers give us information that may be useful: a > >>>>>>>> subscriber name and address for example, which is not > >>>>>>>> spoofable by the caller. They have ways to trace callers, > >>>>>>>> especially bad callers. They don't want their systems abused > >>>>>>>> any more than the emergency calling authorities do. > >>>>>>>> > >>>>>>>> This is a bad idea. A very bad idea. Please stop it. > >>>>>>>> > >>>>>>>> Someday, we may have better ways to prevent abuse. Until we > >>>>>>>> do, service providers are a good thing on an emergency call. > >>>>>>>> We don't want them cut out. > >>>>>>>> > >>>>>>>> Brian > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> Geopriv mailing list > >>>>>>>> Geopriv@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv > >>>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> 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 > >>>>> > >>>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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 rbarnes@bbn.com Thu Oct 29 02:36:30 2009 Return-Path: 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 AA48228C107 for ; Thu, 29 Oct 2009 02:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 S-iViOz1bnmD for ; Thu, 29 Oct 2009 02:36:28 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 737653A686D for ; Thu, 29 Oct 2009 02:36:28 -0700 (PDT) Received: from [128.89.255.97] (helo=[77.42.251.196]) by mx3.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1N3RQu-00032N-CB; Thu, 29 Oct 2009 05:36:41 -0400 Message-Id: From: Richard Barnes To: "Elwell, John" In-Reply-To: <7402509E63C5A145A6095D46C179A5B7148B380D@DEMCHP99E35MSX.ww902.siemens.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 29 Oct 2009 11:36:37 +0200 References: <7402509E63C5A145A6095D46C179A5B7148B380D@DEMCHP99E35MSX.ww902.siemens.net> X-Mailer: Apple Mail (2.936) Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Thu, 29 Oct 2009 09:36:30 -0000 ... and if the answer is "yes", then how do you distinguish between that case and the direct case? On Oct 29, 2009, at 11:28 AM, Elwell, John wrote: > Brian, > > Just a question for clarification below: > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> On Behalf Of Brian Rosen >> Sent: 29 October 2009 03:18 >> To: Marc Linsner >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >> considered >> >> I'm not worried about security by obscurity. I don't want >> phones (or other >> devices) built to call directly. >> >> -phonebcp says "send the call on your normal outbound call >> path". That's >> what I want it to say, and I don't want it to say "send it >> direct, bypass >> your service provider. > [JRE] So if my normal outbound call path is my SIP-PBX, then the SIP- > PBX can route directly to the PSAP? > > John > > >> >> I'm not stopping attack, I am stopping abuse. >> >> I don't want devices that are not subscribed to services to >> be able to make >> emergency calls (that is, if they can't make "normal" calls, >> they should not >> be able to make emergency calls). >> >> Brian >> >> >> On 10/28/09 6:51 PM, "Marc Linsner" wrote: >> >>> Brian, >>> >>> What I hear you saying: 'if we don't document how to spoof >> a PSAP, then >>> nobody will figure it out.' Isn't that a little short sighted? >>> >>> Joey@miscreant.org will figure out how to establish a SIP >> session with any >>> PSAP in the world within 10 minutes of that PSAP being >> accessible via the >>> Internet, regardless of documentation. >>> >>> I believe there's more harm created in not documenting this for >>> John.Q.Public@ordinary_citizen.com. >>> >>> Granted, nobody here is looking to cause harm to a PSAP. But >>> Joey@miscreant.org can certainly expend public safety >> resources by reporting >>> a bomb threat to a local school. Should we require that >> all SIP calls to >>> the local school come from a trusted SP? Where does it end? >>> >>> This isn't the way to deal with spam. >>> >>> -Marc- >>> >>> >>> >>> On 10/27/09 11:00 AM, "Brian Rosen" wrote: >>> >>>> The first goal is to prevent bad calls. >>>> >>>> The second goal is to indentify the source of the bad calls. >>>> >>>> I'm starting with the first goal. I don't want you to be >> able to take a >>>> device out of a box, plug it into a network, and have the >> only call you can >>>> make be an emergency call. I want the device to actually >> "work" (as in be >>>> able to place calls to all the entities that it was >> intended to) first, and >>>> then be able to place emergency calls. >>>> >>>> Please spend some time in a PSAP while a kid with a >> simless phone has "fun" >>>> with it. Imagine how much fun the test mechanism is as >> opposed to placing >>>> real calls. >>>> >>>> If we somehow get a bad call, we need to send the cops. >> That means we need >>>> an identity (and a location). >>>> >>>> I think a good cert could be the basis of a good identity, >> if we could get >>>> one. I don't see how we do that. >>>> >>>> Brian >>>> >>>> >>>> On 10/27/09 10:39 AM, "Richard Barnes" wrote: >>>> >>>>> Brian, >>>>> >>>>> Is the security goal here more access control (i.e., >> controlling who >>>>> can send calls to a PSAP) or attribution/identification >> for post-hoc >>>>> action. >>>>> >>>>> If it's the latter, then ISTM that the problem can >> largely be reduced >>>>> to having a certificate infrastructure that binds authenticated >>>>> identities to real-world entities. The "extended validation" >>>>> certificates that current commercial CAs issue seem to >> largely satisfy >>>>> this requirement. >>>>> >>>>> --Richard >>>>> >>>>> >>>>> On Oct 27, 2009, at 4:31 PM, Brian Rosen wrote: >>>>> >>>>>> Of course not all VSPs will have trust relationships with all >>>>>> PSAPs. One >>>>>> can hope that long term, we can evolve to transitive trust >>>>>> relationships >>>>>> that work pretty well cross border. >>>>>> >>>>>> The emergency guys are actually terrified of private/individual >>>>>> domains >>>>>> sending them calls, and we're telling them we expect that to be >>>>>> possible, >>>>>> but rare, and we're giving them mechanisms that will effectively >>>>>> allow them >>>>>> to turn off calls selectively, based on factors including what >>>>>> domain the >>>>>> call comes from. They expect that such calls will be one of the >>>>>> loopholes >>>>>> where they get equivalents to sim-less calls, which drive them >>>>>> nuts. They >>>>>> don't want ANY calls that don't come from service providers, >>>>>> although they >>>>>> seem to be okay with the notion that the SP may not have great >>>>>> identity (AOL >>>>>> being a poster child). So, while indeed they >> understand, and have >>>>>> concerns >>>>>> about having to take calls from Sierra Leone VoIP >> services Pty, they >>>>>> would >>>>>> much rather have a call that went through them then a >> call that went >>>>>> through >>>>>> no service provider at all. >>>>>> >>>>>> I'm not trying to make calls direct from devices or >> private domains >>>>>> impossible, but I think the notion that we're promoting them is a >>>>>> very bad >>>>>> idea until we have effective mechanisms to prevent abuse. >>>>>> >>>>>> Brian >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 10/27/09 9:02 AM, "Marc Linsner" wrote: >>>>>> >>>>>>> Brian, >>>>>>> >>>>>>> I'm a little confused. I don't remember you objecting to >>>>>>> requirement RE1 >>>>>>> from RFC5012 and I remember your use case about a >> Sierra Leone VSP. >>>>>>> >>>>>>> Are you implying that *all* VSPs will have a trust relationships >>>>>>> with *all* >>>>>>> PSAPs? >>>>>>> >>>>>>> What is the difference between a call coming from a private/ >>>>>>> individual >>>>>>> domain (as in not a commercial VSP) and a VSP on the >> other side of >>>>>>> the world >>>>>>> (outside the jurisdiction)? >>>>>>> >>>>>>> I'm trying to figure out whether you're objecting to anonymous >>>>>>> calls to the >>>>>>> PSAP or the mechanisms proposed in this draft? >>>>>>> >>>>>>> [Don't take this as my endorsement of the draft, as I'm >> not sure I >>>>>>> agree >>>>>>> with UAs registering with the ESRP.] >>>>>>> >>>>>>> -Marc- >>>>>>> >>>>>>> >>>>>>> On 10/26/09 8:59 PM, "Brian Rosen" wrote: >>>>>>> >>>>>>>> First of all, I put it on the wrong email list, sorry >> about that. >>>>>>>> >>>>>>>> Then, we have carefully arranged it so that there is >> no identity >>>>>>>> coming from >>>>>>>> the access network provider, and because the location is coming >>>>>>>> from that >>>>>>>> provider, we really don't want to. But even if we >> did, we would >>>>>>>> need a >>>>>>>> really good identifier, and there isn't one. >>>>>>>> >>>>>>>> The problem we have with -direct is anonymous callers, >> and if they >>>>>>>> have any >>>>>>>> option, they would also be location-less. Until and >> unless we get >>>>>>>> rid of >>>>>>>> anonymity, we can't encourage service provider-less calls. The >>>>>>>> draft does >>>>>>>> not make any provision to provide any kind of identity. Many >>>>>>>> networks >>>>>>>> (think free wifi for example) would make providing >> good identity >>>>>>>> difficult. >>>>>>>> >>>>>>>> The fact is that there is a SERVICE provider in nearly >> all of the >>>>>>>> communications systems. The SERVICE provider is in a >> position to >>>>>>>> assist >>>>>>>> the emergency calling system when it needs more information. >>>>>>>> That's what a >>>>>>>> good SERVICE provider does. Cutting them out is not a great >>>>>>>> idea. Most of >>>>>>>> the attempts to provide real time communications between people >>>>>>>> have evolved >>>>>>>> to using service providers, even when there were >> alternatives. File >>>>>>>> transfer via something like Torrent is a counterexample (which >>>>>>>> isn't real >>>>>>>> time), but even there, you end up with service >> providers like The >>>>>>>> Pirate Bay >>>>>>>> (R.I.P) to provide introduction services. I don't think we're >>>>>>>> going to see >>>>>>>> changes that eliminate service providers, and in this >> case, they >>>>>>>> provide >>>>>>>> value to the emergency calling systems. All of the emergency >>>>>>>> professionals >>>>>>>> I know have issues with service providers, but they would react >>>>>>>> with horror >>>>>>>> if you suggested cutting them out. Ask them, please. >>>>>>>> >>>>>>>> So, I claim you have a solution in search of a >> problem. We have >>>>>>>> solved the >>>>>>>> "calling network isn't the access network" problem >> already. Service >>>>>>>> providers ARE in the path now, in nearly every case (in fact a >>>>>>>> counter >>>>>>>> example escapes me, although there probably are some). >> There is >>>>>>>> no movement >>>>>>>> I can detect which would change that any time soon; quite the >>>>>>>> opposite. We >>>>>>>> have a known killer problem without some kind of >> subscription to a >>>>>>>> service >>>>>>>> that provides a good identity, for which you provide >> no answers. >>>>>>>> We have >>>>>>>> experience with the killer problem: sim-less calling >> was supposed >>>>>>>> to provide >>>>>>>> a way to make an emergency call in exactly the kinds of >>>>>>>> circumstances you >>>>>>>> are describing. Our real world experience is that you create a >>>>>>>> huge problem >>>>>>>> that diverts resources from helping people to chasing >> scammers and >>>>>>>> flea-market sellers. >>>>>>>> >>>>>>>> Nothing is perfect: you can get a AIM screen name >> without a very >>>>>>>> good >>>>>>>> identity for example. However, the notion that we're going to >>>>>>>> provide >>>>>>>> direct access without a service provider deliberately, >> especially >>>>>>>> without >>>>>>>> really good identity from the access network is, in my >> opinion not >>>>>>>> only a >>>>>>>> no, it's a heck no. I'll line up as many emergency service >>>>>>>> professionals as >>>>>>>> you would like to tell you this is a harmful idea. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 10/26/09 7:56 PM, "Dawson, Martin" >> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I am glad this has come up. It's a debate that has to >> happen if >>>>>>>>> we are to >>>>>>>>> move >>>>>>>>> beyond a long standing legacy misconception. >>>>>>>>> >>>>>>>>> In the circuit service world - whether it was POTS or >> mobile, the >>>>>>>>> access >>>>>>>>> network had full responsibility for delivering the emergency >>>>>>>>> call. In that >>>>>>>>> world, routing an emergency call meant getting a circuit >>>>>>>>> established to the >>>>>>>>> correct call center. In most parts of the world, this was done >>>>>>>>> using the >>>>>>>>> regional part of the PSTN to switch the circuit to a >> call center >>>>>>>>> on the >>>>>>>>> PSTN. >>>>>>>>> In some jurisdictions, such as the US, it was done >> directly from >>>>>>>>> the local >>>>>>>>> exchange carrier to the call center. Either way, there was no >>>>>>>>> third party >>>>>>>>> involved. >>>>>>>>> >>>>>>>>> Now we have the Internet. We still have public access network >>>>>>>>> providers. >>>>>>>>> They >>>>>>>>> switch packets onto the Internet for their >> subscribers. They can >>>>>>>>> similarly >>>>>>>>> ensure that packets reach the local emergency call centers. >>>>>>>>> >>>>>>>>> The fact is that there was no equivalent of a VSP in the >>>>>>>>> traditional >>>>>>>>> environment. VoIP is a presence service, and it had no common >>>>>>>>> equivalent in >>>>>>>>> the PSTN world. It could have, but the narrowband state of >>>>>>>>> technology and >>>>>>>>> the >>>>>>>>> common market use cases didn't support its development. By the >>>>>>>>> time ISDN >>>>>>>>> arrived, the PSTN had already slipped into its >> palliative stage >>>>>>>>> without >>>>>>>>> realizing it. >>>>>>>>> >>>>>>>>> It's an entrenched misconception that because the >> circuit service >>>>>>>>> provided >>>>>>>>> by >>>>>>>>> exchange carriers was most commonly used for "voice" (but, it >>>>>>>>> should be >>>>>>>>> noted, >>>>>>>>> also for fax, telex, tty, security system monitoring >> and, even, >>>>>>>>> IP data) >>>>>>>>> that >>>>>>>>> VSPs are somehow equivalent to exchange carriers. >> They are not. >>>>>>>>> >>>>>>>>> Indeed, involving VSPs in emergency calls is the Internet >>>>>>>>> equivalent of >>>>>>>>> involving long distance providers in POTS emergency >> calls. They >>>>>>>>> are neither >>>>>>>>> necessary nor particularly helpful; they can't be >> guaranteed to >>>>>>>>> be within >>>>>>>>> the >>>>>>>>> emergency jurisdiction; depending on them actually >> diminishes the >>>>>>>>> efficacy >>>>>>>>> of >>>>>>>>> emergency service access. It does not help the caller, the >>>>>>>>> emergency >>>>>>>>> service, >>>>>>>>> nor the third party to insist on the third party's >> involvement. >>>>>>>>> >>>>>>>>> It can't be helped if you have over sold the benefits of VSP >>>>>>>>> involvement to >>>>>>>>> yourself and others Brian. It is time to have a >> reasoned debate. >>>>>>>>> From my >>>>>>>>> perspective, the argument that there is no "subscription" >>>>>>>>> involved is >>>>>>>>> patently >>>>>>>>> false. There has to be a subscription of some description in >>>>>>>>> order to get to >>>>>>>>> the Internet. Yes, there is free public Internet >> access (just as >>>>>>>>> there are >>>>>>>>> free courtesy phones on the PSTN and free access to emergency >>>>>>>>> services from >>>>>>>>> pay phones. All these services are still connected to >> the public >>>>>>>>> Internet >>>>>>>>> infrastructure and they all represent an "operator" with some >>>>>>>>> level of >>>>>>>>> information about the caller. >>>>>>>>> >>>>>>>>> With the over-emphasis on VSPs, what is missing from the ECRIT >>>>>>>>> and i3 models >>>>>>>>> is the direct interface for querying the access network for >>>>>>>>> subscriber data >>>>>>>>> (should it prove necessary). These models need to >> take the long >>>>>>>>> view of how >>>>>>>>> emergency calling is done in the Internet age; they >> should not be >>>>>>>>> protracting >>>>>>>>> an unnecessary reliance on VSPs. >>>>>>>>> >>>>>>>>> I have deleted the premature and prejudicial text from the >>>>>>>>> subject heading. >>>>>>>>> And I'll leave this on ECRIT as the most appropriate WG. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Martin >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: ecrit-bounces@ietf.org >> [mailto:ecrit-bounces@ietf.org] On >>>>>>>>> Behalf Of >>>>>>>>> Hannes Tschofenig >>>>>>>>> Sent: Tuesday, 27 October 2009 8:23 AM >>>>>>>>> To: ecrit@ietf.org >>>>>>>>> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>>>>>>> considered harmful, >>>>>>>>> at least given our current experiences >>>>>>>>> >>>>>>>>> FYI: feedback from Brian regarding a recent ECRIT >> contribution. >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: geopriv-bounces@ietf.org >>>>>>>>>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian >>>>>>>>>> Sent: 26 October, 2009 23:10 >>>>>>>>>> To: geopriv@ietf.org >>>>>>>>>> Subject: [Geopriv] Winterbottom-ecrit-direct considered >>>>>>>>>> harmful, at least given our current experiences >>>>>>>>>> >>>>>>>>>> The notion behind -direct is to not use a service provider to >>>>>>>>>> place an emergency call. Instead, the device registers with >>>>>>>>>> an Emergency Services Routing Proxy immediately before the >>>>>>>>>> call and the call is routed directly from the device >> to the ESRP. >>>>>>>>>> >>>>>>>>>> At least at the moment, this is an exceedingly bad idea. >>>>>>>>>> >>>>>>>>>> Emergency calling authorities like service providers, a lot. >>>>>>>>>> They like them because they can hold them >> accountable, and the >>>>>>>>>> service providers don't like theft of service, which is >>>>>>>>>> something the emergency call guys have an analog to. >>>>>>>>>> >>>>>>>>>> The facts are that where unaccountable access to emergency >>>>>>>>>> calling is allowed, huge numbers of false calls >> occur, with no >>>>>>>>>> way to stop them, and no way to tell the good ones from the >>>>>>>>>> bad ones. This has been seen multiple times where so called >>>>>>>>>> "simless" or "unauthenticated" calls are allowed. >>>>>>>>>> >>>>>>>>>> -direct precisely duplicates simless calling. The only >>>>>>>>>> "registration" is an emergency registration, only emergency >>>>>>>>>> calls are allowed, any device can make an emergency call if >>>>>>>>>> all it has is a (radio) connection to any network. >>>>>>>>>> We can predict, with a very high degree of >> certainty, that the >>>>>>>>>> feature will be horribly abused: for example to test that a >>>>>>>>>> phone without a service plan works. >>>>>>>>>> >>>>>>>>>> There have been studies which show tens of thousands of bad >>>>>>>>>> calls with zero good ones. Nearly every authority I know >>>>>>>>>> where the regulator has insisted on simless calling wants it >>>>>>>>>> repealed. There is one counter example I know where the fact >>>>>>>>>> that they got a couple, literally, of good calls among the >>>>>>>>>> tens of thousands of bad calls was considered enough >> reason to >>>>>>>>>> put up with the problem. >>>>>>>>>> >>>>>>>>>> Service providers give us information that may be useful: a >>>>>>>>>> subscriber name and address for example, which is not >>>>>>>>>> spoofable by the caller. They have ways to trace callers, >>>>>>>>>> especially bad callers. They don't want their systems abused >>>>>>>>>> any more than the emergency calling authorities do. >>>>>>>>>> >>>>>>>>>> This is a bad idea. A very bad idea. Please stop it. >>>>>>>>>> >>>>>>>>>> Someday, we may have better ways to prevent abuse. Until we >>>>>>>>>> do, service providers are a good thing on an emergency call. >>>>>>>>>> We don't want them cut out. >>>>>>>>>> >>>>>>>>>> Brian >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Geopriv mailing list >>>>>>>>>> Geopriv@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 mlinsner@cisco.com Thu Oct 29 05:32:03 2009 Return-Path: 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 B24023A682E for ; Thu, 29 Oct 2009 05:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.389 X-Spam-Level: X-Spam-Status: No, score=-6.389 tagged_above=-999 required=5 tests=[AWL=0.210, 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 T1mgRfqmDQ4b for ; Thu, 29 Oct 2009 05:32:01 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id EE42B3A67A1 for ; Thu, 29 Oct 2009 05:32:00 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGco6UpAZnwM/2dsb2JhbADEYZgRgjkGgX4EgmeJDA X-IronPort-AV: E=Sophos;i="4.44,645,1249257600"; d="scan'208";a="65513008" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 29 Oct 2009 12:32:16 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9TCWGAS001397; Thu, 29 Oct 2009 12:32:16 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 08:32:16 -0400 Received: from [10.116.195.121] ([10.116.195.121]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 08:32:14 -0400 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Thu, 29 Oct 2009 08:32:13 -0400 From: Marc Linsner To: Brian Rosen Message-ID: Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4AE1y5CA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 29 Oct 2009 12:32:15.0087 (UTC) FILETIME=[D899B7F0:01CA5893] Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Thu, 29 Oct 2009 12:32:03 -0000 Brian, Please define what you consider to be a service provider. Is Skype a service? Is Jabber a service? Is Google Voice a service? Is mydomain.com hosted on a commercial site a service? Is mydomain.com hosted on a home server a service? Is myEnterpriseVoIP.com a service? So, what you are saying that if I can make calls via all of the above, it's OK for all of the above to contact an ESRP? Are you requiring that I have a full-time proxy on-line for mydomain.com or can I simply run a transient UA and dynamic DNS? -Marc- On 10/28/09 11:17 PM, "Brian Rosen" wrote: > I'm not worried about security by obscurity. I don't want phones (or other > devices) built to call directly. > > -phonebcp says "send the call on your normal outbound call path". That's > what I want it to say, and I don't want it to say "send it direct, bypass > your service provider. > > I'm not stopping attack, I am stopping abuse. > > I don't want devices that are not subscribed to services to be able to make > emergency calls (that is, if they can't make "normal" calls, they should not > be able to make emergency calls). > > Brian > > > On 10/28/09 6:51 PM, "Marc Linsner" wrote: > >> Brian, >> >> What I hear you saying: 'if we don't document how to spoof a PSAP, then >> nobody will figure it out.' Isn't that a little short sighted? >> >> Joey@miscreant.org will figure out how to establish a SIP session with any >> PSAP in the world within 10 minutes of that PSAP being accessible via the >> Internet, regardless of documentation. >> >> I believe there's more harm created in not documenting this for >> John.Q.Public@ordinary_citizen.com. >> >> Granted, nobody here is looking to cause harm to a PSAP. But >> Joey@miscreant.org can certainly expend public safety resources by reporting >> a bomb threat to a local school. Should we require that all SIP calls to >> the local school come from a trusted SP? Where does it end? >> >> This isn't the way to deal with spam. >> >> -Marc- >> >> >> >> On 10/27/09 11:00 AM, "Brian Rosen" wrote: >> >>> The first goal is to prevent bad calls. >>> >>> The second goal is to indentify the source of the bad calls. >>> >>> I'm starting with the first goal. I don't want you to be able to take a >>> device out of a box, plug it into a network, and have the only call you can >>> make be an emergency call. I want the device to actually "work" (as in be >>> able to place calls to all the entities that it was intended to) first, and >>> then be able to place emergency calls. >>> >>> Please spend some time in a PSAP while a kid with a simless phone has "fun" >>> with it. Imagine how much fun the test mechanism is as opposed to placing >>> real calls. >>> >>> If we somehow get a bad call, we need to send the cops. That means we need >>> an identity (and a location). >>> >>> I think a good cert could be the basis of a good identity, if we could get >>> one. I don't see how we do that. >>> >>> Brian >>> >>> >>> On 10/27/09 10:39 AM, "Richard Barnes" wrote: >>> >>>> Brian, >>>> >>>> Is the security goal here more access control (i.e., controlling who >>>> can send calls to a PSAP) or attribution/identification for post-hoc >>>> action. >>>> >>>> If it's the latter, then ISTM that the problem can largely be reduced >>>> to having a certificate infrastructure that binds authenticated >>>> identities to real-world entities. The "extended validation" >>>> certificates that current commercial CAs issue seem to largely satisfy >>>> this requirement. >>>> >>>> --Richard >>>> >>>> >>>> On Oct 27, 2009, at 4:31 PM, Brian Rosen wrote: >>>> >>>>> Of course not all VSPs will have trust relationships with all >>>>> PSAPs. One >>>>> can hope that long term, we can evolve to transitive trust >>>>> relationships >>>>> that work pretty well cross border. >>>>> >>>>> The emergency guys are actually terrified of private/individual >>>>> domains >>>>> sending them calls, and we're telling them we expect that to be >>>>> possible, >>>>> but rare, and we're giving them mechanisms that will effectively >>>>> allow them >>>>> to turn off calls selectively, based on factors including what >>>>> domain the >>>>> call comes from. They expect that such calls will be one of the >>>>> loopholes >>>>> where they get equivalents to sim-less calls, which drive them >>>>> nuts. They >>>>> don't want ANY calls that don't come from service providers, >>>>> although they >>>>> seem to be okay with the notion that the SP may not have great >>>>> identity (AOL >>>>> being a poster child). So, while indeed they understand, and have >>>>> concerns >>>>> about having to take calls from Sierra Leone VoIP services Pty, they >>>>> would >>>>> much rather have a call that went through them then a call that went >>>>> through >>>>> no service provider at all. >>>>> >>>>> I'm not trying to make calls direct from devices or private domains >>>>> impossible, but I think the notion that we're promoting them is a >>>>> very bad >>>>> idea until we have effective mechanisms to prevent abuse. >>>>> >>>>> Brian >>>>> >>>>> >>>>> >>>>> >>>>> On 10/27/09 9:02 AM, "Marc Linsner" wrote: >>>>> >>>>>> Brian, >>>>>> >>>>>> I'm a little confused. I don't remember you objecting to >>>>>> requirement RE1 >>>>>> from RFC5012 and I remember your use case about a Sierra Leone VSP. >>>>>> >>>>>> Are you implying that *all* VSPs will have a trust relationships >>>>>> with *all* >>>>>> PSAPs? >>>>>> >>>>>> What is the difference between a call coming from a private/ >>>>>> individual >>>>>> domain (as in not a commercial VSP) and a VSP on the other side of >>>>>> the world >>>>>> (outside the jurisdiction)? >>>>>> >>>>>> I'm trying to figure out whether you're objecting to anonymous >>>>>> calls to the >>>>>> PSAP or the mechanisms proposed in this draft? >>>>>> >>>>>> [Don't take this as my endorsement of the draft, as I'm not sure I >>>>>> agree >>>>>> with UAs registering with the ESRP.] >>>>>> >>>>>> -Marc- >>>>>> >>>>>> >>>>>> On 10/26/09 8:59 PM, "Brian Rosen" wrote: >>>>>> >>>>>>> First of all, I put it on the wrong email list, sorry about that. >>>>>>> >>>>>>> Then, we have carefully arranged it so that there is no identity >>>>>>> coming from >>>>>>> the access network provider, and because the location is coming >>>>>>> from that >>>>>>> provider, we really don't want to. But even if we did, we would >>>>>>> need a >>>>>>> really good identifier, and there isn't one. >>>>>>> >>>>>>> The problem we have with -direct is anonymous callers, and if they >>>>>>> have any >>>>>>> option, they would also be location-less. Until and unless we get >>>>>>> rid of >>>>>>> anonymity, we can't encourage service provider-less calls. The >>>>>>> draft does >>>>>>> not make any provision to provide any kind of identity. Many >>>>>>> networks >>>>>>> (think free wifi for example) would make providing good identity >>>>>>> difficult. >>>>>>> >>>>>>> The fact is that there is a SERVICE provider in nearly all of the >>>>>>> communications systems. The SERVICE provider is in a position to >>>>>>> assist >>>>>>> the emergency calling system when it needs more information. >>>>>>> That's what a >>>>>>> good SERVICE provider does. Cutting them out is not a great >>>>>>> idea. Most of >>>>>>> the attempts to provide real time communications between people >>>>>>> have evolved >>>>>>> to using service providers, even when there were alternatives. File >>>>>>> transfer via something like Torrent is a counterexample (which >>>>>>> isn't real >>>>>>> time), but even there, you end up with service providers like The >>>>>>> Pirate Bay >>>>>>> (R.I.P) to provide introduction services. I don't think we're >>>>>>> going to see >>>>>>> changes that eliminate service providers, and in this case, they >>>>>>> provide >>>>>>> value to the emergency calling systems. All of the emergency >>>>>>> professionals >>>>>>> I know have issues with service providers, but they would react >>>>>>> with horror >>>>>>> if you suggested cutting them out. Ask them, please. >>>>>>> >>>>>>> So, I claim you have a solution in search of a problem. We have >>>>>>> solved the >>>>>>> "calling network isn't the access network" problem already. Service >>>>>>> providers ARE in the path now, in nearly every case (in fact a >>>>>>> counter >>>>>>> example escapes me, although there probably are some). There is >>>>>>> no movement >>>>>>> I can detect which would change that any time soon; quite the >>>>>>> opposite. We >>>>>>> have a known killer problem without some kind of subscription to a >>>>>>> service >>>>>>> that provides a good identity, for which you provide no answers. >>>>>>> We have >>>>>>> experience with the killer problem: sim-less calling was supposed >>>>>>> to provide >>>>>>> a way to make an emergency call in exactly the kinds of >>>>>>> circumstances you >>>>>>> are describing. Our real world experience is that you create a >>>>>>> huge problem >>>>>>> that diverts resources from helping people to chasing scammers and >>>>>>> flea-market sellers. >>>>>>> >>>>>>> Nothing is perfect: you can get a AIM screen name without a very >>>>>>> good >>>>>>> identity for example. However, the notion that we're going to >>>>>>> provide >>>>>>> direct access without a service provider deliberately, especially >>>>>>> without >>>>>>> really good identity from the access network is, in my opinion not >>>>>>> only a >>>>>>> no, it's a heck no. I'll line up as many emergency service >>>>>>> professionals as >>>>>>> you would like to tell you this is a harmful idea. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 10/26/09 7:56 PM, "Dawson, Martin" >>>>>>> wrote: >>>>>>> >>>>>>>> I am glad this has come up. It's a debate that has to happen if >>>>>>>> we are to >>>>>>>> move >>>>>>>> beyond a long standing legacy misconception. >>>>>>>> >>>>>>>> In the circuit service world - whether it was POTS or mobile, the >>>>>>>> access >>>>>>>> network had full responsibility for delivering the emergency >>>>>>>> call. In that >>>>>>>> world, routing an emergency call meant getting a circuit >>>>>>>> established to the >>>>>>>> correct call center. In most parts of the world, this was done >>>>>>>> using the >>>>>>>> regional part of the PSTN to switch the circuit to a call center >>>>>>>> on the >>>>>>>> PSTN. >>>>>>>> In some jurisdictions, such as the US, it was done directly from >>>>>>>> the local >>>>>>>> exchange carrier to the call center. Either way, there was no >>>>>>>> third party >>>>>>>> involved. >>>>>>>> >>>>>>>> Now we have the Internet. We still have public access network >>>>>>>> providers. >>>>>>>> They >>>>>>>> switch packets onto the Internet for their subscribers. They can >>>>>>>> similarly >>>>>>>> ensure that packets reach the local emergency call centers. >>>>>>>> >>>>>>>> The fact is that there was no equivalent of a VSP in the >>>>>>>> traditional >>>>>>>> environment. VoIP is a presence service, and it had no common >>>>>>>> equivalent in >>>>>>>> the PSTN world. It could have, but the narrowband state of >>>>>>>> technology and >>>>>>>> the >>>>>>>> common market use cases didn't support its development. By the >>>>>>>> time ISDN >>>>>>>> arrived, the PSTN had already slipped into its palliative stage >>>>>>>> without >>>>>>>> realizing it. >>>>>>>> >>>>>>>> It's an entrenched misconception that because the circuit service >>>>>>>> provided >>>>>>>> by >>>>>>>> exchange carriers was most commonly used for "voice" (but, it >>>>>>>> should be >>>>>>>> noted, >>>>>>>> also for fax, telex, tty, security system monitoring and, even, >>>>>>>> IP data) >>>>>>>> that >>>>>>>> VSPs are somehow equivalent to exchange carriers. They are not. >>>>>>>> >>>>>>>> Indeed, involving VSPs in emergency calls is the Internet >>>>>>>> equivalent of >>>>>>>> involving long distance providers in POTS emergency calls. They >>>>>>>> are neither >>>>>>>> necessary nor particularly helpful; they can't be guaranteed to >>>>>>>> be within >>>>>>>> the >>>>>>>> emergency jurisdiction; depending on them actually diminishes the >>>>>>>> efficacy >>>>>>>> of >>>>>>>> emergency service access. It does not help the caller, the >>>>>>>> emergency >>>>>>>> service, >>>>>>>> nor the third party to insist on the third party's involvement. >>>>>>>> >>>>>>>> It can't be helped if you have over sold the benefits of VSP >>>>>>>> involvement to >>>>>>>> yourself and others Brian. It is time to have a reasoned debate. >>>>>>>> From my >>>>>>>> perspective, the argument that there is no "subscription" >>>>>>>> involved is >>>>>>>> patently >>>>>>>> false. There has to be a subscription of some description in >>>>>>>> order to get to >>>>>>>> the Internet. Yes, there is free public Internet access (just as >>>>>>>> there are >>>>>>>> free courtesy phones on the PSTN and free access to emergency >>>>>>>> services from >>>>>>>> pay phones. All these services are still connected to the public >>>>>>>> Internet >>>>>>>> infrastructure and they all represent an "operator" with some >>>>>>>> level of >>>>>>>> information about the caller. >>>>>>>> >>>>>>>> With the over-emphasis on VSPs, what is missing from the ECRIT >>>>>>>> and i3 models >>>>>>>> is the direct interface for querying the access network for >>>>>>>> subscriber data >>>>>>>> (should it prove necessary). These models need to take the long >>>>>>>> view of how >>>>>>>> emergency calling is done in the Internet age; they should not be >>>>>>>> protracting >>>>>>>> an unnecessary reliance on VSPs. >>>>>>>> >>>>>>>> I have deleted the premature and prejudicial text from the >>>>>>>> subject heading. >>>>>>>> And I'll leave this on ECRIT as the most appropriate WG. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Martin >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>>>>>> Behalf Of >>>>>>>> Hannes Tschofenig >>>>>>>> Sent: Tuesday, 27 October 2009 8:23 AM >>>>>>>> To: ecrit@ietf.org >>>>>>>> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>>>>>> considered harmful, >>>>>>>> at least given our current experiences >>>>>>>> >>>>>>>> FYI: feedback from Brian regarding a recent ECRIT contribution. >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: geopriv-bounces@ietf.org >>>>>>>>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian >>>>>>>>> Sent: 26 October, 2009 23:10 >>>>>>>>> To: geopriv@ietf.org >>>>>>>>> Subject: [Geopriv] Winterbottom-ecrit-direct considered >>>>>>>>> harmful, at least given our current experiences >>>>>>>>> >>>>>>>>> The notion behind -direct is to not use a service provider to >>>>>>>>> place an emergency call. Instead, the device registers with >>>>>>>>> an Emergency Services Routing Proxy immediately before the >>>>>>>>> call and the call is routed directly from the device to the ESRP. >>>>>>>>> >>>>>>>>> At least at the moment, this is an exceedingly bad idea. >>>>>>>>> >>>>>>>>> Emergency calling authorities like service providers, a lot. >>>>>>>>> They like them because they can hold them accountable, and the >>>>>>>>> service providers don't like theft of service, which is >>>>>>>>> something the emergency call guys have an analog to. >>>>>>>>> >>>>>>>>> The facts are that where unaccountable access to emergency >>>>>>>>> calling is allowed, huge numbers of false calls occur, with no >>>>>>>>> way to stop them, and no way to tell the good ones from the >>>>>>>>> bad ones. This has been seen multiple times where so called >>>>>>>>> "simless" or "unauthenticated" calls are allowed. >>>>>>>>> >>>>>>>>> -direct precisely duplicates simless calling. The only >>>>>>>>> "registration" is an emergency registration, only emergency >>>>>>>>> calls are allowed, any device can make an emergency call if >>>>>>>>> all it has is a (radio) connection to any network. >>>>>>>>> We can predict, with a very high degree of certainty, that the >>>>>>>>> feature will be horribly abused: for example to test that a >>>>>>>>> phone without a service plan works. >>>>>>>>> >>>>>>>>> There have been studies which show tens of thousands of bad >>>>>>>>> calls with zero good ones. Nearly every authority I know >>>>>>>>> where the regulator has insisted on simless calling wants it >>>>>>>>> repealed. There is one counter example I know where the fact >>>>>>>>> that they got a couple, literally, of good calls among the >>>>>>>>> tens of thousands of bad calls was considered enough reason to >>>>>>>>> put up with the problem. >>>>>>>>> >>>>>>>>> Service providers give us information that may be useful: a >>>>>>>>> subscriber name and address for example, which is not >>>>>>>>> spoofable by the caller. They have ways to trace callers, >>>>>>>>> especially bad callers. They don't want their systems abused >>>>>>>>> any more than the emergency calling authorities do. >>>>>>>>> >>>>>>>>> This is a bad idea. A very bad idea. Please stop it. >>>>>>>>> >>>>>>>>> Someday, we may have better ways to prevent abuse. Until we >>>>>>>>> do, service providers are a good thing on an emergency call. >>>>>>>>> We don't want them cut out. >>>>>>>>> >>>>>>>>> Brian >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Geopriv mailing list >>>>>>>>> Geopriv@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>> >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>> >>> >> >> > > From drage@alcatel-lucent.com Thu Oct 29 08:48:17 2009 Return-Path: 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 BF2523A6ACE for ; Thu, 29 Oct 2009 08:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 P-KbFMXAtKOp for ; Thu, 29 Oct 2009 08:48:15 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 54E5528C0D6 for ; Thu, 29 Oct 2009 08:48:14 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n9TFmH4o014806 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 29 Oct 2009 16:48:20 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 29 Oct 2009 16:48:17 +0100 From: "DRAGE, Keith (Keith)" To: Marc Linsner , Brian Rosen Date: Thu, 29 Oct 2009 16:48:15 +0100 Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4AE1y5CAAGs5+w Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Thu, 29 Oct 2009 15:48:17 -0000 I suspect that what Brian is saying is that anyone can be a service provide= r (or whatever else you want to call it) in this case provided that: 1) they make that agreement with the PSAP providers they route calls t= o; 2) they authenticate the calls requests to a level of security that me= ets the PSAPs (and any legal) requirements; 3) the PSAP trusts that they have done so. While this would normally be what we would understand as public telecommunc= ation operators, it doesn't mean they have to be. regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Marc Linsner > Sent: Thursday, October 29, 2009 12:32 PM > To: Brian Rosen > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct > considered > > Brian, > > Please define what you consider to be a service provider. > > Is Skype a service? > Is Jabber a service? > Is Google Voice a service? > Is mydomain.com hosted on a commercial site a service? > Is mydomain.com hosted on a home server a service? > Is myEnterpriseVoIP.com a service? > > So, what you are saying that if I can make calls via all of > the above, it's OK for all of the above to contact an ESRP? > > Are you requiring that I have a full-time proxy on-line for > mydomain.com or can I simply run a transient UA and dynamic DNS? > > -Marc- > > > > On 10/28/09 11:17 PM, "Brian Rosen" wrote: > > > I'm not worried about security by obscurity. I don't want > phones (or > > other > > devices) built to call directly. > > > > -phonebcp says "send the call on your normal outbound call path". > > That's what I want it to say, and I don't want it to say "send it > > direct, bypass your service provider. > > > > I'm not stopping attack, I am stopping abuse. > > > > I don't want devices that are not subscribed to services to > be able to > > make emergency calls (that is, if they can't make "normal" > calls, they > > should not be able to make emergency calls). > > > > Brian > > > > > > On 10/28/09 6:51 PM, "Marc Linsner" wrote: > > > >> Brian, > >> > >> What I hear you saying: 'if we don't document how to spoof a PSAP, > >> then nobody will figure it out.' Isn't that a little > short sighted? > >> > >> Joey@miscreant.org will figure out how to establish a SIP session > >> with any PSAP in the world within 10 minutes of that PSAP being > >> accessible via the Internet, regardless of documentation. > >> > >> I believe there's more harm created in not documenting this for > >> John.Q.Public@ordinary_citizen.com. > >> > >> Granted, nobody here is looking to cause harm to a PSAP. But > >> Joey@miscreant.org can certainly expend public safety resources by > >> reporting a bomb threat to a local school. Should we require that > >> all SIP calls to the local school come from a trusted SP? > Where does it end? > >> > >> This isn't the way to deal with spam. > >> > >> -Marc- > >> > >> > >> > >> On 10/27/09 11:00 AM, "Brian Rosen" wrote: > >> > >>> The first goal is to prevent bad calls. > >>> > >>> The second goal is to indentify the source of the bad calls. > >>> > >>> I'm starting with the first goal. I don't want you to be able to > >>> take a device out of a box, plug it into a network, and have the > >>> only call you can make be an emergency call. I want the > device to > >>> actually "work" (as in be able to place calls to all the entities > >>> that it was intended to) first, and then be able to place > emergency calls. > >>> > >>> Please spend some time in a PSAP while a kid with a > simless phone has "fun" > >>> with it. Imagine how much fun the test mechanism is as > opposed to > >>> placing real calls. > >>> > >>> If we somehow get a bad call, we need to send the cops. > That means > >>> we need an identity (and a location). > >>> > >>> I think a good cert could be the basis of a good identity, if we > >>> could get one. I don't see how we do that. > >>> > >>> Brian > >>> > >>> > >>> On 10/27/09 10:39 AM, "Richard Barnes" wrote: > >>> > >>>> Brian, > >>>> > >>>> Is the security goal here more access control (i.e., controlling > >>>> who can send calls to a PSAP) or attribution/identification for > >>>> post-hoc action. > >>>> > >>>> If it's the latter, then ISTM that the problem can largely be > >>>> reduced to having a certificate infrastructure that binds > >>>> authenticated identities to real-world entities. The > "extended validation" > >>>> certificates that current commercial CAs issue seem to largely > >>>> satisfy this requirement. > >>>> > >>>> --Richard > >>>> > >>>> > >>>> On Oct 27, 2009, at 4:31 PM, Brian Rosen wrote: > >>>> > >>>>> Of course not all VSPs will have trust relationships with all > >>>>> PSAPs. One can hope that long term, we can evolve to > transitive > >>>>> trust relationships that work pretty well cross border. > >>>>> > >>>>> The emergency guys are actually terrified of private/individual > >>>>> domains sending them calls, and we're telling them we > expect that > >>>>> to be possible, but rare, and we're giving them mechanisms that > >>>>> will effectively allow them to turn off calls > selectively, based > >>>>> on factors including what domain the call comes from. > They expect > >>>>> that such calls will be one of the loopholes where they get > >>>>> equivalents to sim-less calls, which drive them nuts. > They don't > >>>>> want ANY calls that don't come from service providers, although > >>>>> they seem to be okay with the notion that the SP may not have > >>>>> great identity (AOL being a poster child). So, while > indeed they > >>>>> understand, and have concerns about having to take calls from > >>>>> Sierra Leone VoIP services Pty, they would much rather > have a call > >>>>> that went through them then a call that went through no service > >>>>> provider at all. > >>>>> > >>>>> I'm not trying to make calls direct from devices or private > >>>>> domains impossible, but I think the notion that we're promoting > >>>>> them is a very bad idea until we have effective mechanisms to > >>>>> prevent abuse. > >>>>> > >>>>> Brian > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On 10/27/09 9:02 AM, "Marc Linsner" wrote: > >>>>> > >>>>>> Brian, > >>>>>> > >>>>>> I'm a little confused. I don't remember you objecting to > >>>>>> requirement RE1 from RFC5012 and I remember your use > case about a > >>>>>> Sierra Leone VSP. > >>>>>> > >>>>>> Are you implying that *all* VSPs will have a trust > relationships > >>>>>> with *all* PSAPs? > >>>>>> > >>>>>> What is the difference between a call coming from a private/ > >>>>>> individual domain (as in not a commercial VSP) and a > VSP on the > >>>>>> other side of the world (outside the jurisdiction)? > >>>>>> > >>>>>> I'm trying to figure out whether you're objecting to anonymous > >>>>>> calls to the PSAP or the mechanisms proposed in this draft? > >>>>>> > >>>>>> [Don't take this as my endorsement of the draft, as > I'm not sure > >>>>>> I agree with UAs registering with the ESRP.] > >>>>>> > >>>>>> -Marc- > >>>>>> > >>>>>> > >>>>>> On 10/26/09 8:59 PM, "Brian Rosen" wrote: > >>>>>> > >>>>>>> First of all, I put it on the wrong email list, sorry > about that. > >>>>>>> > >>>>>>> Then, we have carefully arranged it so that there is > no identity > >>>>>>> coming from the access network provider, and because the > >>>>>>> location is coming from that provider, we really > don't want to. > >>>>>>> But even if we did, we would need a really good > identifier, and > >>>>>>> there isn't one. > >>>>>>> > >>>>>>> The problem we have with -direct is anonymous callers, and if > >>>>>>> they have any option, they would also be > location-less. Until > >>>>>>> and unless we get rid of anonymity, we can't > encourage service > >>>>>>> provider-less calls. The draft does not make any > provision to > >>>>>>> provide any kind of identity. Many networks (think free wifi > >>>>>>> for example) would make providing good identity difficult. > >>>>>>> > >>>>>>> The fact is that there is a SERVICE provider in > nearly all of the > >>>>>>> communications systems. The SERVICE provider is in > a position to > >>>>>>> assist > >>>>>>> the emergency calling system when it needs more information. > >>>>>>> That's what a > >>>>>>> good SERVICE provider does. Cutting them out is not a great > >>>>>>> idea. Most of the attempts to provide real time > communications > >>>>>>> between people have evolved to using service providers, even > >>>>>>> when there were alternatives. File transfer via > something like > >>>>>>> Torrent is a counterexample (which isn't real time), but even > >>>>>>> there, you end up with service providers like The Pirate Bay > >>>>>>> (R.I.P) to provide introduction services. I don't > think we're > >>>>>>> going to see changes that eliminate service providers, and in > >>>>>>> this case, they provide value to the emergency > calling systems. > >>>>>>> All of the emergency professionals I know have issues with > >>>>>>> service providers, but they would react with horror if you > >>>>>>> suggested cutting them out. Ask them, please. > >>>>>>> > >>>>>>> So, I claim you have a solution in search of a > problem. We have > >>>>>>> solved the "calling network isn't the access network" problem > >>>>>>> already. Service providers ARE in the path now, in > nearly every > >>>>>>> case (in fact a counter example escapes me, although there > >>>>>>> probably are some). There is no movement I can detect which > >>>>>>> would change that any time soon; quite the opposite. > We have a > >>>>>>> known killer problem without some kind of subscription to a > >>>>>>> service that provides a good identity, for which you > provide no > >>>>>>> answers. > >>>>>>> We have > >>>>>>> experience with the killer problem: sim-less calling was > >>>>>>> supposed to provide a way to make an emergency call > in exactly > >>>>>>> the kinds of circumstances you are describing. Our > real world > >>>>>>> experience is that you create a huge problem that diverts > >>>>>>> resources from helping people to chasing scammers and > >>>>>>> flea-market sellers. > >>>>>>> > >>>>>>> Nothing is perfect: you can get a AIM screen name > without a very > >>>>>>> good identity for example. However, the notion that > we're going > >>>>>>> to provide direct access without a service provider > >>>>>>> deliberately, especially without really good identity > from the > >>>>>>> access network is, in my opinion not only a no, it's > a heck no. > >>>>>>> I'll line up as many emergency service professionals as you > >>>>>>> would like to tell you this is a harmful idea. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On 10/26/09 7:56 PM, "Dawson, Martin" > > >>>>>>> wrote: > >>>>>>> > >>>>>>>> I am glad this has come up. It's a debate that has > to happen if > >>>>>>>> we are to move beyond a long standing legacy misconception. > >>>>>>>> > >>>>>>>> In the circuit service world - whether it was POTS > or mobile, > >>>>>>>> the access network had full responsibility for > delivering the > >>>>>>>> emergency call. In that world, routing an emergency > call meant > >>>>>>>> getting a circuit established to the correct call center. In > >>>>>>>> most parts of the world, this was done using the > regional part > >>>>>>>> of the PSTN to switch the circuit to a call center > on the PSTN. > >>>>>>>> In some jurisdictions, such as the US, it was done directly > >>>>>>>> from the local exchange carrier to the call center. > Either way, > >>>>>>>> there was no third party involved. > >>>>>>>> > >>>>>>>> Now we have the Internet. We still have public > access network > >>>>>>>> providers. > >>>>>>>> They > >>>>>>>> switch packets onto the Internet for their subscribers. They > >>>>>>>> can similarly ensure that packets reach the local emergency > >>>>>>>> call centers. > >>>>>>>> > >>>>>>>> The fact is that there was no equivalent of a VSP in the > >>>>>>>> traditional environment. VoIP is a presence service, > and it had > >>>>>>>> no common equivalent in the PSTN world. It could > have, but the > >>>>>>>> narrowband state of technology and the common market > use cases > >>>>>>>> didn't support its development. By the time ISDN > arrived, the > >>>>>>>> PSTN had already slipped into its palliative stage without > >>>>>>>> realizing it. > >>>>>>>> > >>>>>>>> It's an entrenched misconception that because the circuit > >>>>>>>> service provided by exchange carriers was most commonly used > >>>>>>>> for "voice" (but, it should be noted, also for fax, > telex, tty, > >>>>>>>> security system monitoring and, even, IP data) that VSPs are > >>>>>>>> somehow equivalent to exchange carriers. They are not. > >>>>>>>> > >>>>>>>> Indeed, involving VSPs in emergency calls is the Internet > >>>>>>>> equivalent of involving long distance providers in POTS > >>>>>>>> emergency calls. They are neither necessary nor particularly > >>>>>>>> helpful; they can't be guaranteed to be within the emergency > >>>>>>>> jurisdiction; depending on them actually diminishes the > >>>>>>>> efficacy of emergency service access. It does not help the > >>>>>>>> caller, the emergency service, nor the third party > to insist on > >>>>>>>> the third party's involvement. > >>>>>>>> > >>>>>>>> It can't be helped if you have over sold the benefits of VSP > >>>>>>>> involvement to yourself and others Brian. It is time > to have a > >>>>>>>> reasoned debate. > >>>>>>>> From my > >>>>>>>> perspective, the argument that there is no "subscription" > >>>>>>>> involved is > >>>>>>>> patently > >>>>>>>> false. There has to be a subscription of some description in > >>>>>>>> order to get to the Internet. Yes, there is free public > >>>>>>>> Internet access (just as there are free courtesy > phones on the > >>>>>>>> PSTN and free access to emergency services from pay > phones. All > >>>>>>>> these services are still connected to the public Internet > >>>>>>>> infrastructure and they all represent an "operator" > with some > >>>>>>>> level of information about the caller. > >>>>>>>> > >>>>>>>> With the over-emphasis on VSPs, what is missing from > the ECRIT > >>>>>>>> and i3 models is the direct interface for querying > the access > >>>>>>>> network for subscriber data (should it prove > necessary). These > >>>>>>>> models need to take the long view of how emergency > calling is > >>>>>>>> done in the Internet age; they should not be protracting an > >>>>>>>> unnecessary reliance on VSPs. > >>>>>>>> > >>>>>>>> I have deleted the premature and prejudicial text from the > >>>>>>>> subject heading. > >>>>>>>> And I'll leave this on ECRIT as the most appropriate WG. > >>>>>>>> > >>>>>>>> Cheers, > >>>>>>>> Martin > >>>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On > >>>>>>>> Behalf Of Hannes Tschofenig > >>>>>>>> Sent: Tuesday, 27 October 2009 8:23 AM > >>>>>>>> To: ecrit@ietf.org > >>>>>>>> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct > >>>>>>>> considered harmful, at least given our current experiences > >>>>>>>> > >>>>>>>> FYI: feedback from Brian regarding a recent ECRIT > contribution. > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: geopriv-bounces@ietf.org > >>>>>>>>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian > >>>>>>>>> Sent: 26 October, 2009 23:10 > >>>>>>>>> To: geopriv@ietf.org > >>>>>>>>> Subject: [Geopriv] Winterbottom-ecrit-direct considered > >>>>>>>>> harmful, at least given our current experiences > >>>>>>>>> > >>>>>>>>> The notion behind -direct is to not use a service > provider to > >>>>>>>>> place an emergency call. Instead, the device > registers with > >>>>>>>>> an Emergency Services Routing Proxy immediately before the > >>>>>>>>> call and the call is routed directly from the > device to the ESRP. > >>>>>>>>> > >>>>>>>>> At least at the moment, this is an exceedingly bad idea. > >>>>>>>>> > >>>>>>>>> Emergency calling authorities like service providers, a lot. > >>>>>>>>> They like them because they can hold them > accountable, and the > >>>>>>>>> service providers don't like theft of service, which is > >>>>>>>>> something the emergency call guys have an analog to. > >>>>>>>>> > >>>>>>>>> The facts are that where unaccountable access to emergency > >>>>>>>>> calling is allowed, huge numbers of false calls > occur, with no > >>>>>>>>> way to stop them, and no way to tell the good ones from the > >>>>>>>>> bad ones. This has been seen multiple times where > so called > >>>>>>>>> "simless" or "unauthenticated" calls are allowed. > >>>>>>>>> > >>>>>>>>> -direct precisely duplicates simless calling. The only > >>>>>>>>> "registration" is an emergency registration, only emergency > >>>>>>>>> calls are allowed, any device can make an emergency call if > >>>>>>>>> all it has is a (radio) connection to any network. > >>>>>>>>> We can predict, with a very high degree of > certainty, that the > >>>>>>>>> feature will be horribly abused: for example to test that a > >>>>>>>>> phone without a service plan works. > >>>>>>>>> > >>>>>>>>> There have been studies which show tens of thousands of bad > >>>>>>>>> calls with zero good ones. Nearly every authority I know > >>>>>>>>> where the regulator has insisted on simless calling > wants it > >>>>>>>>> repealed. There is one counter example I know > where the fact > >>>>>>>>> that they got a couple, literally, of good calls among the > >>>>>>>>> tens of thousands of bad calls was considered > enough reason to > >>>>>>>>> put up with the problem. > >>>>>>>>> > >>>>>>>>> Service providers give us information that may be useful: a > >>>>>>>>> subscriber name and address for example, which is not > >>>>>>>>> spoofable by the caller. They have ways to trace callers, > >>>>>>>>> especially bad callers. They don't want their > systems abused > >>>>>>>>> any more than the emergency calling authorities do. > >>>>>>>>> > >>>>>>>>> This is a bad idea. A very bad idea. Please stop it. > >>>>>>>>> > >>>>>>>>> Someday, we may have better ways to prevent abuse. Until we > >>>>>>>>> do, service providers are a good thing on an emergency call. > >>>>>>>>> We don't want them cut out. > >>>>>>>>> > >>>>>>>>> Brian > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> Geopriv mailing list > >>>>>>>>> Geopriv@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv > >>>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> 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 > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 br@brianrosen.net Thu Oct 29 11:35:08 2009 Return-Path: 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 213B63A6921 for ; Thu, 29 Oct 2009 11:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 RZrIpnwjq0VD for ; Thu, 29 Oct 2009 11:35:05 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id AEFE43A685E for ; Thu, 29 Oct 2009 11:35:05 -0700 (PDT) Received: from armoursquare.rice.iit.edu ([64.131.110.238] helo=[10.10.10.82]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1N3Zq2-0002Vg-0P; Thu, 29 Oct 2009 13:35:10 -0500 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Thu, 29 Oct 2009 14:35:06 -0400 From: Brian Rosen To: "DRAGE, Keith (Keith)" , Marc Linsner Message-ID: Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4AE1y5CAAGs5+wAAX4z4U= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Thu, 29 Oct 2009 18:35:08 -0000 Thank you. That is what I meant, and you said it better than I was going to. We may also have some transitive relationships: that is, if there is a "local" PSAP that trusts that they have done so, other PSAPs may trust that they have done so. Brian On 10/29/09 11:48 AM, "DRAGE, Keith (Keith)" wrote: > I suspect that what Brian is saying is that anyone can be a service provider > (or whatever else you want to call it) in this case provided that: > > 1) they make that agreement with the PSAP providers they route calls to; > > 2) they authenticate the calls requests to a level of security that meets > the PSAPs (and any legal) requirements; > > 3) the PSAP trusts that they have done so. > > While this would normally be what we would understand as public > telecommuncation operators, it doesn't mean they have to be. > > regards > > Keith > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> On Behalf Of Marc Linsner >> Sent: Thursday, October 29, 2009 12:32 PM >> To: Brian Rosen >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >> considered >> >> Brian, >> >> Please define what you consider to be a service provider. >> >> Is Skype a service? >> Is Jabber a service? >> Is Google Voice a service? >> Is mydomain.com hosted on a commercial site a service? >> Is mydomain.com hosted on a home server a service? >> Is myEnterpriseVoIP.com a service? >> >> So, what you are saying that if I can make calls via all of >> the above, it's OK for all of the above to contact an ESRP? >> >> Are you requiring that I have a full-time proxy on-line for >> mydomain.com or can I simply run a transient UA and dynamic DNS? >> >> -Marc- >> >> >> >> On 10/28/09 11:17 PM, "Brian Rosen" wrote: >> >>> I'm not worried about security by obscurity. I don't want >> phones (or >>> other >>> devices) built to call directly. >>> >>> -phonebcp says "send the call on your normal outbound call path". >>> That's what I want it to say, and I don't want it to say "send it >>> direct, bypass your service provider. >>> >>> I'm not stopping attack, I am stopping abuse. >>> >>> I don't want devices that are not subscribed to services to >> be able to >>> make emergency calls (that is, if they can't make "normal" >> calls, they >>> should not be able to make emergency calls). >>> >>> Brian >>> >>> >>> On 10/28/09 6:51 PM, "Marc Linsner" wrote: >>> >>>> Brian, >>>> >>>> What I hear you saying: 'if we don't document how to spoof a PSAP, >>>> then nobody will figure it out.' Isn't that a little >> short sighted? >>>> >>>> Joey@miscreant.org will figure out how to establish a SIP session >>>> with any PSAP in the world within 10 minutes of that PSAP being >>>> accessible via the Internet, regardless of documentation. >>>> >>>> I believe there's more harm created in not documenting this for >>>> John.Q.Public@ordinary_citizen.com. >>>> >>>> Granted, nobody here is looking to cause harm to a PSAP. But >>>> Joey@miscreant.org can certainly expend public safety resources by >>>> reporting a bomb threat to a local school. Should we require that >>>> all SIP calls to the local school come from a trusted SP? >> Where does it end? >>>> >>>> This isn't the way to deal with spam. >>>> >>>> -Marc- >>>> >>>> >>>> >>>> On 10/27/09 11:00 AM, "Brian Rosen" wrote: >>>> >>>>> The first goal is to prevent bad calls. >>>>> >>>>> The second goal is to indentify the source of the bad calls. >>>>> >>>>> I'm starting with the first goal. I don't want you to be able to >>>>> take a device out of a box, plug it into a network, and have the >>>>> only call you can make be an emergency call. I want the >> device to >>>>> actually "work" (as in be able to place calls to all the entities >>>>> that it was intended to) first, and then be able to place >> emergency calls. >>>>> >>>>> Please spend some time in a PSAP while a kid with a >> simless phone has "fun" >>>>> with it. Imagine how much fun the test mechanism is as >> opposed to >>>>> placing real calls. >>>>> >>>>> If we somehow get a bad call, we need to send the cops. >> That means >>>>> we need an identity (and a location). >>>>> >>>>> I think a good cert could be the basis of a good identity, if we >>>>> could get one. I don't see how we do that. >>>>> >>>>> Brian >>>>> >>>>> >>>>> On 10/27/09 10:39 AM, "Richard Barnes" wrote: >>>>> >>>>>> Brian, >>>>>> >>>>>> Is the security goal here more access control (i.e., controlling >>>>>> who can send calls to a PSAP) or attribution/identification for >>>>>> post-hoc action. >>>>>> >>>>>> If it's the latter, then ISTM that the problem can largely be >>>>>> reduced to having a certificate infrastructure that binds >>>>>> authenticated identities to real-world entities. The >> "extended validation" >>>>>> certificates that current commercial CAs issue seem to largely >>>>>> satisfy this requirement. >>>>>> >>>>>> --Richard >>>>>> >>>>>> >>>>>> On Oct 27, 2009, at 4:31 PM, Brian Rosen wrote: >>>>>> >>>>>>> Of course not all VSPs will have trust relationships with all >>>>>>> PSAPs. One can hope that long term, we can evolve to >> transitive >>>>>>> trust relationships that work pretty well cross border. >>>>>>> >>>>>>> The emergency guys are actually terrified of private/individual >>>>>>> domains sending them calls, and we're telling them we >> expect that >>>>>>> to be possible, but rare, and we're giving them mechanisms that >>>>>>> will effectively allow them to turn off calls >> selectively, based >>>>>>> on factors including what domain the call comes from. >> They expect >>>>>>> that such calls will be one of the loopholes where they get >>>>>>> equivalents to sim-less calls, which drive them nuts. >> They don't >>>>>>> want ANY calls that don't come from service providers, although >>>>>>> they seem to be okay with the notion that the SP may not have >>>>>>> great identity (AOL being a poster child). So, while >> indeed they >>>>>>> understand, and have concerns about having to take calls from >>>>>>> Sierra Leone VoIP services Pty, they would much rather >> have a call >>>>>>> that went through them then a call that went through no service >>>>>>> provider at all. >>>>>>> >>>>>>> I'm not trying to make calls direct from devices or private >>>>>>> domains impossible, but I think the notion that we're promoting >>>>>>> them is a very bad idea until we have effective mechanisms to >>>>>>> prevent abuse. >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 10/27/09 9:02 AM, "Marc Linsner" wrote: >>>>>>> >>>>>>>> Brian, >>>>>>>> >>>>>>>> I'm a little confused. I don't remember you objecting to >>>>>>>> requirement RE1 from RFC5012 and I remember your use >> case about a >>>>>>>> Sierra Leone VSP. >>>>>>>> >>>>>>>> Are you implying that *all* VSPs will have a trust >> relationships >>>>>>>> with *all* PSAPs? >>>>>>>> >>>>>>>> What is the difference between a call coming from a private/ >>>>>>>> individual domain (as in not a commercial VSP) and a >> VSP on the >>>>>>>> other side of the world (outside the jurisdiction)? >>>>>>>> >>>>>>>> I'm trying to figure out whether you're objecting to anonymous >>>>>>>> calls to the PSAP or the mechanisms proposed in this draft? >>>>>>>> >>>>>>>> [Don't take this as my endorsement of the draft, as >> I'm not sure >>>>>>>> I agree with UAs registering with the ESRP.] >>>>>>>> >>>>>>>> -Marc- >>>>>>>> >>>>>>>> >>>>>>>> On 10/26/09 8:59 PM, "Brian Rosen" wrote: >>>>>>>> >>>>>>>>> First of all, I put it on the wrong email list, sorry >> about that. >>>>>>>>> >>>>>>>>> Then, we have carefully arranged it so that there is >> no identity >>>>>>>>> coming from the access network provider, and because the >>>>>>>>> location is coming from that provider, we really >> don't want to. >>>>>>>>> But even if we did, we would need a really good >> identifier, and >>>>>>>>> there isn't one. >>>>>>>>> >>>>>>>>> The problem we have with -direct is anonymous callers, and if >>>>>>>>> they have any option, they would also be >> location-less. Until >>>>>>>>> and unless we get rid of anonymity, we can't >> encourage service >>>>>>>>> provider-less calls. The draft does not make any >> provision to >>>>>>>>> provide any kind of identity. Many networks (think free wifi >>>>>>>>> for example) would make providing good identity difficult. >>>>>>>>> >>>>>>>>> The fact is that there is a SERVICE provider in >> nearly all of the >>>>>>>>> communications systems. The SERVICE provider is in >> a position to >>>>>>>>> assist >>>>>>>>> the emergency calling system when it needs more information. >>>>>>>>> That's what a >>>>>>>>> good SERVICE provider does. Cutting them out is not a great >>>>>>>>> idea. Most of the attempts to provide real time >> communications >>>>>>>>> between people have evolved to using service providers, even >>>>>>>>> when there were alternatives. File transfer via >> something like >>>>>>>>> Torrent is a counterexample (which isn't real time), but even >>>>>>>>> there, you end up with service providers like The Pirate Bay >>>>>>>>> (R.I.P) to provide introduction services. I don't >> think we're >>>>>>>>> going to see changes that eliminate service providers, and in >>>>>>>>> this case, they provide value to the emergency >> calling systems. >>>>>>>>> All of the emergency professionals I know have issues with >>>>>>>>> service providers, but they would react with horror if you >>>>>>>>> suggested cutting them out. Ask them, please. >>>>>>>>> >>>>>>>>> So, I claim you have a solution in search of a >> problem. We have >>>>>>>>> solved the "calling network isn't the access network" problem >>>>>>>>> already. Service providers ARE in the path now, in >> nearly every >>>>>>>>> case (in fact a counter example escapes me, although there >>>>>>>>> probably are some). There is no movement I can detect which >>>>>>>>> would change that any time soon; quite the opposite. >> We have a >>>>>>>>> known killer problem without some kind of subscription to a >>>>>>>>> service that provides a good identity, for which you >> provide no >>>>>>>>> answers. >>>>>>>>> We have >>>>>>>>> experience with the killer problem: sim-less calling was >>>>>>>>> supposed to provide a way to make an emergency call >> in exactly >>>>>>>>> the kinds of circumstances you are describing. Our >> real world >>>>>>>>> experience is that you create a huge problem that diverts >>>>>>>>> resources from helping people to chasing scammers and >>>>>>>>> flea-market sellers. >>>>>>>>> >>>>>>>>> Nothing is perfect: you can get a AIM screen name >> without a very >>>>>>>>> good identity for example. However, the notion that >> we're going >>>>>>>>> to provide direct access without a service provider >>>>>>>>> deliberately, especially without really good identity >> from the >>>>>>>>> access network is, in my opinion not only a no, it's >> a heck no. >>>>>>>>> I'll line up as many emergency service professionals as you >>>>>>>>> would like to tell you this is a harmful idea. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/26/09 7:56 PM, "Dawson, Martin" >> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> I am glad this has come up. It's a debate that has >> to happen if >>>>>>>>>> we are to move beyond a long standing legacy misconception. >>>>>>>>>> >>>>>>>>>> In the circuit service world - whether it was POTS >> or mobile, >>>>>>>>>> the access network had full responsibility for >> delivering the >>>>>>>>>> emergency call. In that world, routing an emergency >> call meant >>>>>>>>>> getting a circuit established to the correct call center. In >>>>>>>>>> most parts of the world, this was done using the >> regional part >>>>>>>>>> of the PSTN to switch the circuit to a call center >> on the PSTN. >>>>>>>>>> In some jurisdictions, such as the US, it was done directly >>>>>>>>>> from the local exchange carrier to the call center. >> Either way, >>>>>>>>>> there was no third party involved. >>>>>>>>>> >>>>>>>>>> Now we have the Internet. We still have public >> access network >>>>>>>>>> providers. >>>>>>>>>> They >>>>>>>>>> switch packets onto the Internet for their subscribers. They >>>>>>>>>> can similarly ensure that packets reach the local emergency >>>>>>>>>> call centers. >>>>>>>>>> >>>>>>>>>> The fact is that there was no equivalent of a VSP in the >>>>>>>>>> traditional environment. VoIP is a presence service, >> and it had >>>>>>>>>> no common equivalent in the PSTN world. It could >> have, but the >>>>>>>>>> narrowband state of technology and the common market >> use cases >>>>>>>>>> didn't support its development. By the time ISDN >> arrived, the >>>>>>>>>> PSTN had already slipped into its palliative stage without >>>>>>>>>> realizing it. >>>>>>>>>> >>>>>>>>>> It's an entrenched misconception that because the circuit >>>>>>>>>> service provided by exchange carriers was most commonly used >>>>>>>>>> for "voice" (but, it should be noted, also for fax, >> telex, tty, >>>>>>>>>> security system monitoring and, even, IP data) that VSPs are >>>>>>>>>> somehow equivalent to exchange carriers. They are not. >>>>>>>>>> >>>>>>>>>> Indeed, involving VSPs in emergency calls is the Internet >>>>>>>>>> equivalent of involving long distance providers in POTS >>>>>>>>>> emergency calls. They are neither necessary nor particularly >>>>>>>>>> helpful; they can't be guaranteed to be within the emergency >>>>>>>>>> jurisdiction; depending on them actually diminishes the >>>>>>>>>> efficacy of emergency service access. It does not help the >>>>>>>>>> caller, the emergency service, nor the third party >> to insist on >>>>>>>>>> the third party's involvement. >>>>>>>>>> >>>>>>>>>> It can't be helped if you have over sold the benefits of VSP >>>>>>>>>> involvement to yourself and others Brian. It is time >> to have a >>>>>>>>>> reasoned debate. >>>>>>>>>> From my >>>>>>>>>> perspective, the argument that there is no "subscription" >>>>>>>>>> involved is >>>>>>>>>> patently >>>>>>>>>> false. There has to be a subscription of some description in >>>>>>>>>> order to get to the Internet. Yes, there is free public >>>>>>>>>> Internet access (just as there are free courtesy >> phones on the >>>>>>>>>> PSTN and free access to emergency services from pay >> phones. All >>>>>>>>>> these services are still connected to the public Internet >>>>>>>>>> infrastructure and they all represent an "operator" >> with some >>>>>>>>>> level of information about the caller. >>>>>>>>>> >>>>>>>>>> With the over-emphasis on VSPs, what is missing from >> the ECRIT >>>>>>>>>> and i3 models is the direct interface for querying >> the access >>>>>>>>>> network for subscriber data (should it prove >> necessary). These >>>>>>>>>> models need to take the long view of how emergency >> calling is >>>>>>>>>> done in the Internet age; they should not be protracting an >>>>>>>>>> unnecessary reliance on VSPs. >>>>>>>>>> >>>>>>>>>> I have deleted the premature and prejudicial text from the >>>>>>>>>> subject heading. >>>>>>>>>> And I'll leave this on ECRIT as the most appropriate WG. >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Martin >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: ecrit-bounces@ietf.org >> [mailto:ecrit-bounces@ietf.org] On >>>>>>>>>> Behalf Of Hannes Tschofenig >>>>>>>>>> Sent: Tuesday, 27 October 2009 8:23 AM >>>>>>>>>> To: ecrit@ietf.org >>>>>>>>>> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>>>>>>>> considered harmful, at least given our current experiences >>>>>>>>>> >>>>>>>>>> FYI: feedback from Brian regarding a recent ECRIT >> contribution. >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: geopriv-bounces@ietf.org >>>>>>>>>>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian >>>>>>>>>>> Sent: 26 October, 2009 23:10 >>>>>>>>>>> To: geopriv@ietf.org >>>>>>>>>>> Subject: [Geopriv] Winterbottom-ecrit-direct considered >>>>>>>>>>> harmful, at least given our current experiences >>>>>>>>>>> >>>>>>>>>>> The notion behind -direct is to not use a service >> provider to >>>>>>>>>>> place an emergency call. Instead, the device >> registers with >>>>>>>>>>> an Emergency Services Routing Proxy immediately before the >>>>>>>>>>> call and the call is routed directly from the >> device to the ESRP. >>>>>>>>>>> >>>>>>>>>>> At least at the moment, this is an exceedingly bad idea. >>>>>>>>>>> >>>>>>>>>>> Emergency calling authorities like service providers, a lot. >>>>>>>>>>> They like them because they can hold them >> accountable, and the >>>>>>>>>>> service providers don't like theft of service, which is >>>>>>>>>>> something the emergency call guys have an analog to. >>>>>>>>>>> >>>>>>>>>>> The facts are that where unaccountable access to emergency >>>>>>>>>>> calling is allowed, huge numbers of false calls >> occur, with no >>>>>>>>>>> way to stop them, and no way to tell the good ones from the >>>>>>>>>>> bad ones. This has been seen multiple times where >> so called >>>>>>>>>>> "simless" or "unauthenticated" calls are allowed. >>>>>>>>>>> >>>>>>>>>>> -direct precisely duplicates simless calling. The only >>>>>>>>>>> "registration" is an emergency registration, only emergency >>>>>>>>>>> calls are allowed, any device can make an emergency call if >>>>>>>>>>> all it has is a (radio) connection to any network. >>>>>>>>>>> We can predict, with a very high degree of >> certainty, that the >>>>>>>>>>> feature will be horribly abused: for example to test that a >>>>>>>>>>> phone without a service plan works. >>>>>>>>>>> >>>>>>>>>>> There have been studies which show tens of thousands of bad >>>>>>>>>>> calls with zero good ones. Nearly every authority I know >>>>>>>>>>> where the regulator has insisted on simless calling >> wants it >>>>>>>>>>> repealed. There is one counter example I know >> where the fact >>>>>>>>>>> that they got a couple, literally, of good calls among the >>>>>>>>>>> tens of thousands of bad calls was considered >> enough reason to >>>>>>>>>>> put up with the problem. >>>>>>>>>>> >>>>>>>>>>> Service providers give us information that may be useful: a >>>>>>>>>>> subscriber name and address for example, which is not >>>>>>>>>>> spoofable by the caller. They have ways to trace callers, >>>>>>>>>>> especially bad callers. They don't want their >> systems abused >>>>>>>>>>> any more than the emergency calling authorities do. >>>>>>>>>>> >>>>>>>>>>> This is a bad idea. A very bad idea. Please stop it. >>>>>>>>>>> >>>>>>>>>>> Someday, we may have better ways to prevent abuse. Until we >>>>>>>>>>> do, service providers are a good thing on an emergency call. >>>>>>>>>>> We don't want them cut out. >>>>>>>>>>> >>>>>>>>>>> Brian >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Geopriv mailing list >>>>>>>>>>> Geopriv@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 mlinsner@cisco.com Thu Oct 29 12:27:17 2009 Return-Path: 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 2A4003A6927 for ; Thu, 29 Oct 2009 12:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.409 X-Spam-Level: X-Spam-Status: No, score=-6.409 tagged_above=-999 required=5 tests=[AWL=0.190, 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 RGDPDSc1YnxI for ; Thu, 29 Oct 2009 12:27:14 -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 DC5F53A6899 for ; Thu, 29 Oct 2009 12:27:14 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJ+J6UqrR7Hu/2dsb2JhbADHX5gcgjkGgX4EgmeJDA X-IronPort-AV: E=Sophos;i="4.44,648,1249257600"; d="scan'208";a="263545527" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 29 Oct 2009 19:27:26 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9TJRPP7009655; Thu, 29 Oct 2009 19:27:26 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 15:27:25 -0400 Received: from [10.116.195.121] ([10.116.195.121]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 15:27:23 -0400 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Thu, 29 Oct 2009 15:27:21 -0400 From: Marc Linsner To: Brian Rosen Message-ID: Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4AE1y5CAAGs5+wAAX4z4UAAdMnZQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 29 Oct 2009 19:27:23.0927 (UTC) FILETIME=[D76D1270:01CA58CD] Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Thu, 29 Oct 2009 19:27:17 -0000 These are all PSAP policy decisions. Just as it's a PSAP policy decision to support the suggested mechanism in the draft. Existence of the document describing the mechanism doesn't force PSAP policy. I personally would like to see some PSAPs and/or PS jurisdictions line up behind the draft before it proceeds, but I don't see any harm in it going forward. Of course, I'm dreaming about this special place where a PSAP actually wants to enable communication with all their customers and not force them to be a member of a special club. [non-chair hat on] -Marc- On 10/29/09 2:35 PM, "Brian Rosen" wrote: > Thank you. That is what I meant, and you said it better than I was going > to. > > We may also have some transitive relationships: that is, if there is a > "local" PSAP that trusts that they have done so, other PSAPs may trust that > they have done so. > > Brian > > On 10/29/09 11:48 AM, "DRAGE, Keith (Keith)" > wrote: > >> I suspect that what Brian is saying is that anyone can be a service provider >> (or whatever else you want to call it) in this case provided that: >> >> 1) they make that agreement with the PSAP providers they route calls to; >> >> 2) they authenticate the calls requests to a level of security that >> meets >> the PSAPs (and any legal) requirements; >> >> 3) the PSAP trusts that they have done so. >> >> While this would normally be what we would understand as public >> telecommuncation operators, it doesn't mean they have to be. >> >> regards >> >> Keith >> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>> On Behalf Of Marc Linsner >>> Sent: Thursday, October 29, 2009 12:32 PM >>> To: Brian Rosen >>> Cc: ecrit@ietf.org >>> Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>> considered >>> >>> Brian, >>> >>> Please define what you consider to be a service provider. >>> >>> Is Skype a service? >>> Is Jabber a service? >>> Is Google Voice a service? >>> Is mydomain.com hosted on a commercial site a service? >>> Is mydomain.com hosted on a home server a service? >>> Is myEnterpriseVoIP.com a service? >>> >>> So, what you are saying that if I can make calls via all of >>> the above, it's OK for all of the above to contact an ESRP? >>> >>> Are you requiring that I have a full-time proxy on-line for >>> mydomain.com or can I simply run a transient UA and dynamic DNS? >>> >>> -Marc- >>> >>> >>> >>> On 10/28/09 11:17 PM, "Brian Rosen" wrote: >>> >>>> I'm not worried about security by obscurity. I don't want >>> phones (or >>>> other >>>> devices) built to call directly. >>>> >>>> -phonebcp says "send the call on your normal outbound call path". >>>> That's what I want it to say, and I don't want it to say "send it >>>> direct, bypass your service provider. >>>> >>>> I'm not stopping attack, I am stopping abuse. >>>> >>>> I don't want devices that are not subscribed to services to >>> be able to >>>> make emergency calls (that is, if they can't make "normal" >>> calls, they >>>> should not be able to make emergency calls). >>>> >>>> Brian >>>> >>>> >>>> On 10/28/09 6:51 PM, "Marc Linsner" wrote: >>>> >>>>> Brian, >>>>> >>>>> What I hear you saying: 'if we don't document how to spoof a PSAP, >>>>> then nobody will figure it out.' Isn't that a little >>> short sighted? >>>>> >>>>> Joey@miscreant.org will figure out how to establish a SIP session >>>>> with any PSAP in the world within 10 minutes of that PSAP being >>>>> accessible via the Internet, regardless of documentation. >>>>> >>>>> I believe there's more harm created in not documenting this for >>>>> John.Q.Public@ordinary_citizen.com. >>>>> >>>>> Granted, nobody here is looking to cause harm to a PSAP. But >>>>> Joey@miscreant.org can certainly expend public safety resources by >>>>> reporting a bomb threat to a local school. Should we require that >>>>> all SIP calls to the local school come from a trusted SP? >>> Where does it end? >>>>> >>>>> This isn't the way to deal with spam. >>>>> >>>>> -Marc- >>>>> >>>>> >>>>> >>>>> On 10/27/09 11:00 AM, "Brian Rosen" wrote: >>>>> >>>>>> The first goal is to prevent bad calls. >>>>>> >>>>>> The second goal is to indentify the source of the bad calls. >>>>>> >>>>>> I'm starting with the first goal. I don't want you to be able to >>>>>> take a device out of a box, plug it into a network, and have the >>>>>> only call you can make be an emergency call. I want the >>> device to >>>>>> actually "work" (as in be able to place calls to all the entities >>>>>> that it was intended to) first, and then be able to place >>> emergency calls. >>>>>> >>>>>> Please spend some time in a PSAP while a kid with a >>> simless phone has "fun" >>>>>> with it. Imagine how much fun the test mechanism is as >>> opposed to >>>>>> placing real calls. >>>>>> >>>>>> If we somehow get a bad call, we need to send the cops. >>> That means >>>>>> we need an identity (and a location). >>>>>> >>>>>> I think a good cert could be the basis of a good identity, if we >>>>>> could get one. I don't see how we do that. >>>>>> >>>>>> Brian >>>>>> >>>>>> >>>>>> On 10/27/09 10:39 AM, "Richard Barnes" wrote: >>>>>> >>>>>>> Brian, >>>>>>> >>>>>>> Is the security goal here more access control (i.e., controlling >>>>>>> who can send calls to a PSAP) or attribution/identification for >>>>>>> post-hoc action. >>>>>>> >>>>>>> If it's the latter, then ISTM that the problem can largely be >>>>>>> reduced to having a certificate infrastructure that binds >>>>>>> authenticated identities to real-world entities. The >>> "extended validation" >>>>>>> certificates that current commercial CAs issue seem to largely >>>>>>> satisfy this requirement. >>>>>>> >>>>>>> --Richard >>>>>>> >>>>>>> >>>>>>> On Oct 27, 2009, at 4:31 PM, Brian Rosen wrote: >>>>>>> >>>>>>>> Of course not all VSPs will have trust relationships with all >>>>>>>> PSAPs. One can hope that long term, we can evolve to >>> transitive >>>>>>>> trust relationships that work pretty well cross border. >>>>>>>> >>>>>>>> The emergency guys are actually terrified of private/individual >>>>>>>> domains sending them calls, and we're telling them we >>> expect that >>>>>>>> to be possible, but rare, and we're giving them mechanisms that >>>>>>>> will effectively allow them to turn off calls >>> selectively, based >>>>>>>> on factors including what domain the call comes from. >>> They expect >>>>>>>> that such calls will be one of the loopholes where they get >>>>>>>> equivalents to sim-less calls, which drive them nuts. >>> They don't >>>>>>>> want ANY calls that don't come from service providers, although >>>>>>>> they seem to be okay with the notion that the SP may not have >>>>>>>> great identity (AOL being a poster child). So, while >>> indeed they >>>>>>>> understand, and have concerns about having to take calls from >>>>>>>> Sierra Leone VoIP services Pty, they would much rather >>> have a call >>>>>>>> that went through them then a call that went through no service >>>>>>>> provider at all. >>>>>>>> >>>>>>>> I'm not trying to make calls direct from devices or private >>>>>>>> domains impossible, but I think the notion that we're promoting >>>>>>>> them is a very bad idea until we have effective mechanisms to >>>>>>>> prevent abuse. >>>>>>>> >>>>>>>> Brian >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 10/27/09 9:02 AM, "Marc Linsner" wrote: >>>>>>>> >>>>>>>>> Brian, >>>>>>>>> >>>>>>>>> I'm a little confused. I don't remember you objecting to >>>>>>>>> requirement RE1 from RFC5012 and I remember your use >>> case about a >>>>>>>>> Sierra Leone VSP. >>>>>>>>> >>>>>>>>> Are you implying that *all* VSPs will have a trust >>> relationships >>>>>>>>> with *all* PSAPs? >>>>>>>>> >>>>>>>>> What is the difference between a call coming from a private/ >>>>>>>>> individual domain (as in not a commercial VSP) and a >>> VSP on the >>>>>>>>> other side of the world (outside the jurisdiction)? >>>>>>>>> >>>>>>>>> I'm trying to figure out whether you're objecting to anonymous >>>>>>>>> calls to the PSAP or the mechanisms proposed in this draft? >>>>>>>>> >>>>>>>>> [Don't take this as my endorsement of the draft, as >>> I'm not sure >>>>>>>>> I agree with UAs registering with the ESRP.] >>>>>>>>> >>>>>>>>> -Marc- >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/26/09 8:59 PM, "Brian Rosen" wrote: >>>>>>>>> >>>>>>>>>> First of all, I put it on the wrong email list, sorry >>> about that. >>>>>>>>>> >>>>>>>>>> Then, we have carefully arranged it so that there is >>> no identity >>>>>>>>>> coming from the access network provider, and because the >>>>>>>>>> location is coming from that provider, we really >>> don't want to. >>>>>>>>>> But even if we did, we would need a really good >>> identifier, and >>>>>>>>>> there isn't one. >>>>>>>>>> >>>>>>>>>> The problem we have with -direct is anonymous callers, and if >>>>>>>>>> they have any option, they would also be >>> location-less. Until >>>>>>>>>> and unless we get rid of anonymity, we can't >>> encourage service >>>>>>>>>> provider-less calls. The draft does not make any >>> provision to >>>>>>>>>> provide any kind of identity. Many networks (think free wifi >>>>>>>>>> for example) would make providing good identity difficult. >>>>>>>>>> >>>>>>>>>> The fact is that there is a SERVICE provider in >>> nearly all of the >>>>>>>>>> communications systems. The SERVICE provider is in >>> a position to >>>>>>>>>> assist >>>>>>>>>> the emergency calling system when it needs more information. >>>>>>>>>> That's what a >>>>>>>>>> good SERVICE provider does. Cutting them out is not a great >>>>>>>>>> idea. Most of the attempts to provide real time >>> communications >>>>>>>>>> between people have evolved to using service providers, even >>>>>>>>>> when there were alternatives. File transfer via >>> something like >>>>>>>>>> Torrent is a counterexample (which isn't real time), but even >>>>>>>>>> there, you end up with service providers like The Pirate Bay >>>>>>>>>> (R.I.P) to provide introduction services. I don't >>> think we're >>>>>>>>>> going to see changes that eliminate service providers, and in >>>>>>>>>> this case, they provide value to the emergency >>> calling systems. >>>>>>>>>> All of the emergency professionals I know have issues with >>>>>>>>>> service providers, but they would react with horror if you >>>>>>>>>> suggested cutting them out. Ask them, please. >>>>>>>>>> >>>>>>>>>> So, I claim you have a solution in search of a >>> problem. We have >>>>>>>>>> solved the "calling network isn't the access network" problem >>>>>>>>>> already. Service providers ARE in the path now, in >>> nearly every >>>>>>>>>> case (in fact a counter example escapes me, although there >>>>>>>>>> probably are some). There is no movement I can detect which >>>>>>>>>> would change that any time soon; quite the opposite. >>> We have a >>>>>>>>>> known killer problem without some kind of subscription to a >>>>>>>>>> service that provides a good identity, for which you >>> provide no >>>>>>>>>> answers. >>>>>>>>>> We have >>>>>>>>>> experience with the killer problem: sim-less calling was >>>>>>>>>> supposed to provide a way to make an emergency call >>> in exactly >>>>>>>>>> the kinds of circumstances you are describing. Our >>> real world >>>>>>>>>> experience is that you create a huge problem that diverts >>>>>>>>>> resources from helping people to chasing scammers and >>>>>>>>>> flea-market sellers. >>>>>>>>>> >>>>>>>>>> Nothing is perfect: you can get a AIM screen name >>> without a very >>>>>>>>>> good identity for example. However, the notion that >>> we're going >>>>>>>>>> to provide direct access without a service provider >>>>>>>>>> deliberately, especially without really good identity >>> from the >>>>>>>>>> access network is, in my opinion not only a no, it's >>> a heck no. >>>>>>>>>> I'll line up as many emergency service professionals as you >>>>>>>>>> would like to tell you this is a harmful idea. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 10/26/09 7:56 PM, "Dawson, Martin" >>> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> I am glad this has come up. It's a debate that has >>> to happen if >>>>>>>>>>> we are to move beyond a long standing legacy misconception. >>>>>>>>>>> >>>>>>>>>>> In the circuit service world - whether it was POTS >>> or mobile, >>>>>>>>>>> the access network had full responsibility for >>> delivering the >>>>>>>>>>> emergency call. In that world, routing an emergency >>> call meant >>>>>>>>>>> getting a circuit established to the correct call center. In >>>>>>>>>>> most parts of the world, this was done using the >>> regional part >>>>>>>>>>> of the PSTN to switch the circuit to a call center >>> on the PSTN. >>>>>>>>>>> In some jurisdictions, such as the US, it was done directly >>>>>>>>>>> from the local exchange carrier to the call center. >>> Either way, >>>>>>>>>>> there was no third party involved. >>>>>>>>>>> >>>>>>>>>>> Now we have the Internet. We still have public >>> access network >>>>>>>>>>> providers. >>>>>>>>>>> They >>>>>>>>>>> switch packets onto the Internet for their subscribers. They >>>>>>>>>>> can similarly ensure that packets reach the local emergency >>>>>>>>>>> call centers. >>>>>>>>>>> >>>>>>>>>>> The fact is that there was no equivalent of a VSP in the >>>>>>>>>>> traditional environment. VoIP is a presence service, >>> and it had >>>>>>>>>>> no common equivalent in the PSTN world. It could >>> have, but the >>>>>>>>>>> narrowband state of technology and the common market >>> use cases >>>>>>>>>>> didn't support its development. By the time ISDN >>> arrived, the >>>>>>>>>>> PSTN had already slipped into its palliative stage without >>>>>>>>>>> realizing it. >>>>>>>>>>> >>>>>>>>>>> It's an entrenched misconception that because the circuit >>>>>>>>>>> service provided by exchange carriers was most commonly used >>>>>>>>>>> for "voice" (but, it should be noted, also for fax, >>> telex, tty, >>>>>>>>>>> security system monitoring and, even, IP data) that VSPs are >>>>>>>>>>> somehow equivalent to exchange carriers. They are not. >>>>>>>>>>> >>>>>>>>>>> Indeed, involving VSPs in emergency calls is the Internet >>>>>>>>>>> equivalent of involving long distance providers in POTS >>>>>>>>>>> emergency calls. They are neither necessary nor particularly >>>>>>>>>>> helpful; they can't be guaranteed to be within the emergency >>>>>>>>>>> jurisdiction; depending on them actually diminishes the >>>>>>>>>>> efficacy of emergency service access. It does not help the >>>>>>>>>>> caller, the emergency service, nor the third party >>> to insist on >>>>>>>>>>> the third party's involvement. >>>>>>>>>>> >>>>>>>>>>> It can't be helped if you have over sold the benefits of VSP >>>>>>>>>>> involvement to yourself and others Brian. It is time >>> to have a >>>>>>>>>>> reasoned debate. >>>>>>>>>>> From my >>>>>>>>>>> perspective, the argument that there is no "subscription" >>>>>>>>>>> involved is >>>>>>>>>>> patently >>>>>>>>>>> false. There has to be a subscription of some description in >>>>>>>>>>> order to get to the Internet. Yes, there is free public >>>>>>>>>>> Internet access (just as there are free courtesy >>> phones on the >>>>>>>>>>> PSTN and free access to emergency services from pay >>> phones. All >>>>>>>>>>> these services are still connected to the public Internet >>>>>>>>>>> infrastructure and they all represent an "operator" >>> with some >>>>>>>>>>> level of information about the caller. >>>>>>>>>>> >>>>>>>>>>> With the over-emphasis on VSPs, what is missing from >>> the ECRIT >>>>>>>>>>> and i3 models is the direct interface for querying >>> the access >>>>>>>>>>> network for subscriber data (should it prove >>> necessary). These >>>>>>>>>>> models need to take the long view of how emergency >>> calling is >>>>>>>>>>> done in the Internet age; they should not be protracting an >>>>>>>>>>> unnecessary reliance on VSPs. >>>>>>>>>>> >>>>>>>>>>> I have deleted the premature and prejudicial text from the >>>>>>>>>>> subject heading. >>>>>>>>>>> And I'll leave this on ECRIT as the most appropriate WG. >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Martin >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: ecrit-bounces@ietf.org >>> [mailto:ecrit-bounces@ietf.org] On >>>>>>>>>>> Behalf Of Hannes Tschofenig >>>>>>>>>>> Sent: Tuesday, 27 October 2009 8:23 AM >>>>>>>>>>> To: ecrit@ietf.org >>>>>>>>>>> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>>>>>>>>> considered harmful, at least given our current experiences >>>>>>>>>>> >>>>>>>>>>> FYI: feedback from Brian regarding a recent ECRIT >>> contribution. >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: geopriv-bounces@ietf.org >>>>>>>>>>>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian >>>>>>>>>>>> Sent: 26 October, 2009 23:10 >>>>>>>>>>>> To: geopriv@ietf.org >>>>>>>>>>>> Subject: [Geopriv] Winterbottom-ecrit-direct considered >>>>>>>>>>>> harmful, at least given our current experiences >>>>>>>>>>>> >>>>>>>>>>>> The notion behind -direct is to not use a service >>> provider to >>>>>>>>>>>> place an emergency call. Instead, the device >>> registers with >>>>>>>>>>>> an Emergency Services Routing Proxy immediately before the >>>>>>>>>>>> call and the call is routed directly from the >>> device to the ESRP. >>>>>>>>>>>> >>>>>>>>>>>> At least at the moment, this is an exceedingly bad idea. >>>>>>>>>>>> >>>>>>>>>>>> Emergency calling authorities like service providers, a lot. >>>>>>>>>>>> They like them because they can hold them >>> accountable, and the >>>>>>>>>>>> service providers don't like theft of service, which is >>>>>>>>>>>> something the emergency call guys have an analog to. >>>>>>>>>>>> >>>>>>>>>>>> The facts are that where unaccountable access to emergency >>>>>>>>>>>> calling is allowed, huge numbers of false calls >>> occur, with no >>>>>>>>>>>> way to stop them, and no way to tell the good ones from the >>>>>>>>>>>> bad ones. This has been seen multiple times where >>> so called >>>>>>>>>>>> "simless" or "unauthenticated" calls are allowed. >>>>>>>>>>>> >>>>>>>>>>>> -direct precisely duplicates simless calling. The only >>>>>>>>>>>> "registration" is an emergency registration, only emergency >>>>>>>>>>>> calls are allowed, any device can make an emergency call if >>>>>>>>>>>> all it has is a (radio) connection to any network. >>>>>>>>>>>> We can predict, with a very high degree of >>> certainty, that the >>>>>>>>>>>> feature will be horribly abused: for example to test that a >>>>>>>>>>>> phone without a service plan works. >>>>>>>>>>>> >>>>>>>>>>>> There have been studies which show tens of thousands of bad >>>>>>>>>>>> calls with zero good ones. Nearly every authority I know >>>>>>>>>>>> where the regulator has insisted on simless calling >>> wants it >>>>>>>>>>>> repealed. There is one counter example I know >>> where the fact >>>>>>>>>>>> that they got a couple, literally, of good calls among the >>>>>>>>>>>> tens of thousands of bad calls was considered >>> enough reason to >>>>>>>>>>>> put up with the problem. >>>>>>>>>>>> >>>>>>>>>>>> Service providers give us information that may be useful: a >>>>>>>>>>>> subscriber name and address for example, which is not >>>>>>>>>>>> spoofable by the caller. They have ways to trace callers, >>>>>>>>>>>> especially bad callers. They don't want their >>> systems abused >>>>>>>>>>>> any more than the emergency calling authorities do. >>>>>>>>>>>> >>>>>>>>>>>> This is a bad idea. A very bad idea. Please stop it. >>>>>>>>>>>> >>>>>>>>>>>> Someday, we may have better ways to prevent abuse. Until we >>>>>>>>>>>> do, service providers are a good thing on an emergency call. >>>>>>>>>>>> We don't want them cut out. >>>>>>>>>>>> >>>>>>>>>>>> Brian >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Geopriv mailing list >>>>>>>>>>>> Geopriv@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 br@brianrosen.net Thu Oct 29 13:35:37 2009 Return-Path: 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 D05AC3A6A3F for ; Thu, 29 Oct 2009 13:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 FiPXRvw3ayvJ for ; Thu, 29 Oct 2009 13:35:35 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 5DD7B3A69A1 for ; Thu, 29 Oct 2009 13:35:35 -0700 (PDT) Received: from armoursquare.rice.iit.edu ([64.131.110.238] helo=[10.10.10.82]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1N3bie-0000eR-Qp; Thu, 29 Oct 2009 15:35:41 -0500 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Thu, 29 Oct 2009 16:35:47 -0400 From: Brian Rosen To: Marc Linsner Message-ID: Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4AE1y5CAAGs5+wAAX4z4UAAdMnZQACY9dz In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Thu, 29 Oct 2009 20:35:37 -0000 The IETF writing standards that describe how devices should bypass their service provider and place emergency calls direct is not a PSAP policy issue. I'm satisfied with the current -phonebcp dictum to send calls on the normal call path. For an "unregistered" device, that will not allow any "calls" including emergency calls. I discussed this draft on the NENA LTD meeting this morning. That may generate some list discussion from some PSAP people who are subscribed. I would also like to hear from more PSAP folks on this subject. Brian On 10/29/09 3:27 PM, "Marc Linsner" wrote: > These are all PSAP policy decisions. Just as it's a PSAP policy decision to > support the suggested mechanism in the draft. Existence of the document > describing the mechanism doesn't force PSAP policy. > > I personally would like to see some PSAPs and/or PS jurisdictions line up > behind the draft before it proceeds, but I don't see any harm in it going > forward. > > Of course, I'm dreaming about this special place where a PSAP actually wants > to enable communication with all their customers and not force them to be a > member of a special club. > > [non-chair hat on] > > -Marc- > > > On 10/29/09 2:35 PM, "Brian Rosen" wrote: > >> Thank you. That is what I meant, and you said it better than I was going >> to. >> >> We may also have some transitive relationships: that is, if there is a >> "local" PSAP that trusts that they have done so, other PSAPs may trust that >> they have done so. >> >> Brian >> >> On 10/29/09 11:48 AM, "DRAGE, Keith (Keith)" >> wrote: >> >>> I suspect that what Brian is saying is that anyone can be a service provider >>> (or whatever else you want to call it) in this case provided that: >>> >>> 1) they make that agreement with the PSAP providers they route calls >>> to; >>> >>> 2) they authenticate the calls requests to a level of security that >>> meets >>> the PSAPs (and any legal) requirements; >>> >>> 3) the PSAP trusts that they have done so. >>> >>> While this would normally be what we would understand as public >>> telecommuncation operators, it doesn't mean they have to be. >>> >>> regards >>> >>> Keith >>> >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>>> On Behalf Of Marc Linsner >>>> Sent: Thursday, October 29, 2009 12:32 PM >>>> To: Brian Rosen >>>> Cc: ecrit@ietf.org >>>> Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>> considered >>>> >>>> Brian, >>>> >>>> Please define what you consider to be a service provider. >>>> >>>> Is Skype a service? >>>> Is Jabber a service? >>>> Is Google Voice a service? >>>> Is mydomain.com hosted on a commercial site a service? >>>> Is mydomain.com hosted on a home server a service? >>>> Is myEnterpriseVoIP.com a service? >>>> >>>> So, what you are saying that if I can make calls via all of >>>> the above, it's OK for all of the above to contact an ESRP? >>>> >>>> Are you requiring that I have a full-time proxy on-line for >>>> mydomain.com or can I simply run a transient UA and dynamic DNS? >>>> >>>> -Marc- >>>> >>>> >>>> >>>> On 10/28/09 11:17 PM, "Brian Rosen" wrote: >>>> >>>>> I'm not worried about security by obscurity. I don't want >>>> phones (or >>>>> other >>>>> devices) built to call directly. >>>>> >>>>> -phonebcp says "send the call on your normal outbound call path". >>>>> That's what I want it to say, and I don't want it to say "send it >>>>> direct, bypass your service provider. >>>>> >>>>> I'm not stopping attack, I am stopping abuse. >>>>> >>>>> I don't want devices that are not subscribed to services to >>>> be able to >>>>> make emergency calls (that is, if they can't make "normal" >>>> calls, they >>>>> should not be able to make emergency calls). >>>>> >>>>> Brian >>>>> >>>>> >>>>> On 10/28/09 6:51 PM, "Marc Linsner" wrote: >>>>> >>>>>> Brian, >>>>>> >>>>>> What I hear you saying: 'if we don't document how to spoof a PSAP, >>>>>> then nobody will figure it out.' Isn't that a little >>>> short sighted? >>>>>> >>>>>> Joey@miscreant.org will figure out how to establish a SIP session >>>>>> with any PSAP in the world within 10 minutes of that PSAP being >>>>>> accessible via the Internet, regardless of documentation. >>>>>> >>>>>> I believe there's more harm created in not documenting this for >>>>>> John.Q.Public@ordinary_citizen.com. >>>>>> >>>>>> Granted, nobody here is looking to cause harm to a PSAP. But >>>>>> Joey@miscreant.org can certainly expend public safety resources by >>>>>> reporting a bomb threat to a local school. Should we require that >>>>>> all SIP calls to the local school come from a trusted SP? >>>> Where does it end? >>>>>> >>>>>> This isn't the way to deal with spam. >>>>>> >>>>>> -Marc- >>>>>> >>>>>> >>>>>> >>>>>> On 10/27/09 11:00 AM, "Brian Rosen" wrote: >>>>>> >>>>>>> The first goal is to prevent bad calls. >>>>>>> >>>>>>> The second goal is to indentify the source of the bad calls. >>>>>>> >>>>>>> I'm starting with the first goal. I don't want you to be able to >>>>>>> take a device out of a box, plug it into a network, and have the >>>>>>> only call you can make be an emergency call. I want the >>>> device to >>>>>>> actually "work" (as in be able to place calls to all the entities >>>>>>> that it was intended to) first, and then be able to place >>>> emergency calls. >>>>>>> >>>>>>> Please spend some time in a PSAP while a kid with a >>>> simless phone has "fun" >>>>>>> with it. Imagine how much fun the test mechanism is as >>>> opposed to >>>>>>> placing real calls. >>>>>>> >>>>>>> If we somehow get a bad call, we need to send the cops. >>>> That means >>>>>>> we need an identity (and a location). >>>>>>> >>>>>>> I think a good cert could be the basis of a good identity, if we >>>>>>> could get one. I don't see how we do that. >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>> >>>>>>> On 10/27/09 10:39 AM, "Richard Barnes" wrote: >>>>>>> >>>>>>>> Brian, >>>>>>>> >>>>>>>> Is the security goal here more access control (i.e., controlling >>>>>>>> who can send calls to a PSAP) or attribution/identification for >>>>>>>> post-hoc action. >>>>>>>> >>>>>>>> If it's the latter, then ISTM that the problem can largely be >>>>>>>> reduced to having a certificate infrastructure that binds >>>>>>>> authenticated identities to real-world entities. The >>>> "extended validation" >>>>>>>> certificates that current commercial CAs issue seem to largely >>>>>>>> satisfy this requirement. >>>>>>>> >>>>>>>> --Richard >>>>>>>> >>>>>>>> >>>>>>>> On Oct 27, 2009, at 4:31 PM, Brian Rosen wrote: >>>>>>>> >>>>>>>>> Of course not all VSPs will have trust relationships with all >>>>>>>>> PSAPs. One can hope that long term, we can evolve to >>>> transitive >>>>>>>>> trust relationships that work pretty well cross border. >>>>>>>>> >>>>>>>>> The emergency guys are actually terrified of private/individual >>>>>>>>> domains sending them calls, and we're telling them we >>>> expect that >>>>>>>>> to be possible, but rare, and we're giving them mechanisms that >>>>>>>>> will effectively allow them to turn off calls >>>> selectively, based >>>>>>>>> on factors including what domain the call comes from. >>>> They expect >>>>>>>>> that such calls will be one of the loopholes where they get >>>>>>>>> equivalents to sim-less calls, which drive them nuts. >>>> They don't >>>>>>>>> want ANY calls that don't come from service providers, although >>>>>>>>> they seem to be okay with the notion that the SP may not have >>>>>>>>> great identity (AOL being a poster child). So, while >>>> indeed they >>>>>>>>> understand, and have concerns about having to take calls from >>>>>>>>> Sierra Leone VoIP services Pty, they would much rather >>>> have a call >>>>>>>>> that went through them then a call that went through no service >>>>>>>>> provider at all. >>>>>>>>> >>>>>>>>> I'm not trying to make calls direct from devices or private >>>>>>>>> domains impossible, but I think the notion that we're promoting >>>>>>>>> them is a very bad idea until we have effective mechanisms to >>>>>>>>> prevent abuse. >>>>>>>>> >>>>>>>>> Brian >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/27/09 9:02 AM, "Marc Linsner" wrote: >>>>>>>>> >>>>>>>>>> Brian, >>>>>>>>>> >>>>>>>>>> I'm a little confused. I don't remember you objecting to >>>>>>>>>> requirement RE1 from RFC5012 and I remember your use >>>> case about a >>>>>>>>>> Sierra Leone VSP. >>>>>>>>>> >>>>>>>>>> Are you implying that *all* VSPs will have a trust >>>> relationships >>>>>>>>>> with *all* PSAPs? >>>>>>>>>> >>>>>>>>>> What is the difference between a call coming from a private/ >>>>>>>>>> individual domain (as in not a commercial VSP) and a >>>> VSP on the >>>>>>>>>> other side of the world (outside the jurisdiction)? >>>>>>>>>> >>>>>>>>>> I'm trying to figure out whether you're objecting to anonymous >>>>>>>>>> calls to the PSAP or the mechanisms proposed in this draft? >>>>>>>>>> >>>>>>>>>> [Don't take this as my endorsement of the draft, as >>>> I'm not sure >>>>>>>>>> I agree with UAs registering with the ESRP.] >>>>>>>>>> >>>>>>>>>> -Marc- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 10/26/09 8:59 PM, "Brian Rosen" wrote: >>>>>>>>>> >>>>>>>>>>> First of all, I put it on the wrong email list, sorry >>>> about that. >>>>>>>>>>> >>>>>>>>>>> Then, we have carefully arranged it so that there is >>>> no identity >>>>>>>>>>> coming from the access network provider, and because the >>>>>>>>>>> location is coming from that provider, we really >>>> don't want to. >>>>>>>>>>> But even if we did, we would need a really good >>>> identifier, and >>>>>>>>>>> there isn't one. >>>>>>>>>>> >>>>>>>>>>> The problem we have with -direct is anonymous callers, and if >>>>>>>>>>> they have any option, they would also be >>>> location-less. Until >>>>>>>>>>> and unless we get rid of anonymity, we can't >>>> encourage service >>>>>>>>>>> provider-less calls. The draft does not make any >>>> provision to >>>>>>>>>>> provide any kind of identity. Many networks (think free wifi >>>>>>>>>>> for example) would make providing good identity difficult. >>>>>>>>>>> >>>>>>>>>>> The fact is that there is a SERVICE provider in >>>> nearly all of the >>>>>>>>>>> communications systems. The SERVICE provider is in >>>> a position to >>>>>>>>>>> assist >>>>>>>>>>> the emergency calling system when it needs more information. >>>>>>>>>>> That's what a >>>>>>>>>>> good SERVICE provider does. Cutting them out is not a great >>>>>>>>>>> idea. Most of the attempts to provide real time >>>> communications >>>>>>>>>>> between people have evolved to using service providers, even >>>>>>>>>>> when there were alternatives. File transfer via >>>> something like >>>>>>>>>>> Torrent is a counterexample (which isn't real time), but even >>>>>>>>>>> there, you end up with service providers like The Pirate Bay >>>>>>>>>>> (R.I.P) to provide introduction services. I don't >>>> think we're >>>>>>>>>>> going to see changes that eliminate service providers, and in >>>>>>>>>>> this case, they provide value to the emergency >>>> calling systems. >>>>>>>>>>> All of the emergency professionals I know have issues with >>>>>>>>>>> service providers, but they would react with horror if you >>>>>>>>>>> suggested cutting them out. Ask them, please. >>>>>>>>>>> >>>>>>>>>>> So, I claim you have a solution in search of a >>>> problem. We have >>>>>>>>>>> solved the "calling network isn't the access network" problem >>>>>>>>>>> already. Service providers ARE in the path now, in >>>> nearly every >>>>>>>>>>> case (in fact a counter example escapes me, although there >>>>>>>>>>> probably are some). There is no movement I can detect which >>>>>>>>>>> would change that any time soon; quite the opposite. >>>> We have a >>>>>>>>>>> known killer problem without some kind of subscription to a >>>>>>>>>>> service that provides a good identity, for which you >>>> provide no >>>>>>>>>>> answers. >>>>>>>>>>> We have >>>>>>>>>>> experience with the killer problem: sim-less calling was >>>>>>>>>>> supposed to provide a way to make an emergency call >>>> in exactly >>>>>>>>>>> the kinds of circumstances you are describing. Our >>>> real world >>>>>>>>>>> experience is that you create a huge problem that diverts >>>>>>>>>>> resources from helping people to chasing scammers and >>>>>>>>>>> flea-market sellers. >>>>>>>>>>> >>>>>>>>>>> Nothing is perfect: you can get a AIM screen name >>>> without a very >>>>>>>>>>> good identity for example. However, the notion that >>>> we're going >>>>>>>>>>> to provide direct access without a service provider >>>>>>>>>>> deliberately, especially without really good identity >>>> from the >>>>>>>>>>> access network is, in my opinion not only a no, it's >>>> a heck no. >>>>>>>>>>> I'll line up as many emergency service professionals as you >>>>>>>>>>> would like to tell you this is a harmful idea. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 10/26/09 7:56 PM, "Dawson, Martin" >>>> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> I am glad this has come up. It's a debate that has >>>> to happen if >>>>>>>>>>>> we are to move beyond a long standing legacy misconception. >>>>>>>>>>>> >>>>>>>>>>>> In the circuit service world - whether it was POTS >>>> or mobile, >>>>>>>>>>>> the access network had full responsibility for >>>> delivering the >>>>>>>>>>>> emergency call. In that world, routing an emergency >>>> call meant >>>>>>>>>>>> getting a circuit established to the correct call center. In >>>>>>>>>>>> most parts of the world, this was done using the >>>> regional part >>>>>>>>>>>> of the PSTN to switch the circuit to a call center >>>> on the PSTN. >>>>>>>>>>>> In some jurisdictions, such as the US, it was done directly >>>>>>>>>>>> from the local exchange carrier to the call center. >>>> Either way, >>>>>>>>>>>> there was no third party involved. >>>>>>>>>>>> >>>>>>>>>>>> Now we have the Internet. We still have public >>>> access network >>>>>>>>>>>> providers. >>>>>>>>>>>> They >>>>>>>>>>>> switch packets onto the Internet for their subscribers. They >>>>>>>>>>>> can similarly ensure that packets reach the local emergency >>>>>>>>>>>> call centers. >>>>>>>>>>>> >>>>>>>>>>>> The fact is that there was no equivalent of a VSP in the >>>>>>>>>>>> traditional environment. VoIP is a presence service, >>>> and it had >>>>>>>>>>>> no common equivalent in the PSTN world. It could >>>> have, but the >>>>>>>>>>>> narrowband state of technology and the common market >>>> use cases >>>>>>>>>>>> didn't support its development. By the time ISDN >>>> arrived, the >>>>>>>>>>>> PSTN had already slipped into its palliative stage without >>>>>>>>>>>> realizing it. >>>>>>>>>>>> >>>>>>>>>>>> It's an entrenched misconception that because the circuit >>>>>>>>>>>> service provided by exchange carriers was most commonly used >>>>>>>>>>>> for "voice" (but, it should be noted, also for fax, >>>> telex, tty, >>>>>>>>>>>> security system monitoring and, even, IP data) that VSPs are >>>>>>>>>>>> somehow equivalent to exchange carriers. They are not. >>>>>>>>>>>> >>>>>>>>>>>> Indeed, involving VSPs in emergency calls is the Internet >>>>>>>>>>>> equivalent of involving long distance providers in POTS >>>>>>>>>>>> emergency calls. They are neither necessary nor particularly >>>>>>>>>>>> helpful; they can't be guaranteed to be within the emergency >>>>>>>>>>>> jurisdiction; depending on them actually diminishes the >>>>>>>>>>>> efficacy of emergency service access. It does not help the >>>>>>>>>>>> caller, the emergency service, nor the third party >>>> to insist on >>>>>>>>>>>> the third party's involvement. >>>>>>>>>>>> >>>>>>>>>>>> It can't be helped if you have over sold the benefits of VSP >>>>>>>>>>>> involvement to yourself and others Brian. It is time >>>> to have a >>>>>>>>>>>> reasoned debate. >>>>>>>>>>>> From my >>>>>>>>>>>> perspective, the argument that there is no "subscription" >>>>>>>>>>>> involved is >>>>>>>>>>>> patently >>>>>>>>>>>> false. There has to be a subscription of some description in >>>>>>>>>>>> order to get to the Internet. Yes, there is free public >>>>>>>>>>>> Internet access (just as there are free courtesy >>>> phones on the >>>>>>>>>>>> PSTN and free access to emergency services from pay >>>> phones. All >>>>>>>>>>>> these services are still connected to the public Internet >>>>>>>>>>>> infrastructure and they all represent an "operator" >>>> with some >>>>>>>>>>>> level of information about the caller. >>>>>>>>>>>> >>>>>>>>>>>> With the over-emphasis on VSPs, what is missing from >>>> the ECRIT >>>>>>>>>>>> and i3 models is the direct interface for querying >>>> the access >>>>>>>>>>>> network for subscriber data (should it prove >>>> necessary). These >>>>>>>>>>>> models need to take the long view of how emergency >>>> calling is >>>>>>>>>>>> done in the Internet age; they should not be protracting an >>>>>>>>>>>> unnecessary reliance on VSPs. >>>>>>>>>>>> >>>>>>>>>>>> I have deleted the premature and prejudicial text from the >>>>>>>>>>>> subject heading. >>>>>>>>>>>> And I'll leave this on ECRIT as the most appropriate WG. >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> Martin >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: ecrit-bounces@ietf.org >>>> [mailto:ecrit-bounces@ietf.org] On >>>>>>>>>>>> Behalf Of Hannes Tschofenig >>>>>>>>>>>> Sent: Tuesday, 27 October 2009 8:23 AM >>>>>>>>>>>> To: ecrit@ietf.org >>>>>>>>>>>> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>>>>>>>>>> considered harmful, at least given our current experiences >>>>>>>>>>>> >>>>>>>>>>>> FYI: feedback from Brian regarding a recent ECRIT >>>> contribution. >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: geopriv-bounces@ietf.org >>>>>>>>>>>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian >>>>>>>>>>>> Sent: 26 October, 2009 23:10 >>>>>>>>>>>> To: geopriv@ietf.org >>>>>>>>>>>> Subject: [Geopriv] Winterbottom-ecrit-direct considered >>>>>>>>>>>> harmful, at least given our current experiences >>>>>>>>>>>> >>>>>>>>>>>> The notion behind -direct is to not use a service >>>> provider to >>>>>>>>>>>> place an emergency call. Instead, the device >>>> registers with >>>>>>>>>>>> an Emergency Services Routing Proxy immediately before the >>>>>>>>>>>> call and the call is routed directly from the >>>> device to the ESRP. >>>>>>>>>>>> >>>>>>>>>>>> At least at the moment, this is an exceedingly bad idea. >>>>>>>>>>>> >>>>>>>>>>>> Emergency calling authorities like service providers, a lot. >>>>>>>>>>>> They like them because they can hold them >>>> accountable, and the >>>>>>>>>>>> service providers don't like theft of service, which is >>>>>>>>>>>> something the emergency call guys have an analog to. >>>>>>>>>>>> >>>>>>>>>>>> The facts are that where unaccountable access to emergency >>>>>>>>>>>> calling is allowed, huge numbers of false calls >>>> occur, with no >>>>>>>>>>>> way to stop them, and no way to tell the good ones from the >>>>>>>>>>>> bad ones. This has been seen multiple times where >>>> so called >>>>>>>>>>>> "simless" or "unauthenticated" calls are allowed. >>>>>>>>>>>> >>>>>>>>>>>> -direct precisely duplicates simless calling. The only >>>>>>>>>>>> "registration" is an emergency registration, only emergency >>>>>>>>>>>> calls are allowed, any device can make an emergency call if >>>>>>>>>>>> all it has is a (radio) connection to any network. >>>>>>>>>>>> We can predict, with a very high degree of >>>> certainty, that the >>>>>>>>>>>> feature will be horribly abused: for example to test that a >>>>>>>>>>>> phone without a service plan works. >>>>>>>>>>>> >>>>>>>>>>>> There have been studies which show tens of thousands of bad >>>>>>>>>>>> calls with zero good ones. Nearly every authority I know >>>>>>>>>>>> where the regulator has insisted on simless calling >>>> wants it >>>>>>>>>>>> repealed. There is one counter example I know >>>> where the fact >>>>>>>>>>>> that they got a couple, literally, of good calls among the >>>>>>>>>>>> tens of thousands of bad calls was considered >>>> enough reason to >>>>>>>>>>>> put up with the problem. >>>>>>>>>>>> >>>>>>>>>>>> Service providers give us information that may be useful: a >>>>>>>>>>>> subscriber name and address for example, which is not >>>>>>>>>>>> spoofable by the caller. They have ways to trace callers, >>>>>>>>>>>> especially bad callers. They don't want their >>>> systems abused >>>>>>>>>>>> any more than the emergency calling authorities do. >>>>>>>>>>>> >>>>>>>>>>>> This is a bad idea. A very bad idea. Please stop it. >>>>>>>>>>>> >>>>>>>>>>>> Someday, we may have better ways to prevent abuse. Until we >>>>>>>>>>>> do, service providers are a good thing on an emergency call. >>>>>>>>>>>> We don't want them cut out. >>>>>>>>>>>> >>>>>>>>>>>> Brian >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Geopriv mailing list >>>>>>>>>>>> Geopriv@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 mlinsner@cisco.com Thu Oct 29 14:46:33 2009 Return-Path: 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 3F88F3A6A6B for ; Thu, 29 Oct 2009 14:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.424 X-Spam-Level: X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 NV1h6JoR29z5 for ; Thu, 29 Oct 2009 14:46:30 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 4A1C93A6A21 for ; Thu, 29 Oct 2009 14:46:30 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAG+q6UpAZnwN/2dsb2JhbADHXpgdgjkGgX4EgmeJDA X-IronPort-AV: E=Sophos;i="4.44,648,1249257600"; d="scan'208";a="65608739" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 29 Oct 2009 21:46:45 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9TLkjp6010767; Thu, 29 Oct 2009 21:46:45 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.3959); Thu, 29 Oct 2009 17:46:45 -0400 Received: from [10.116.195.121] ([10.116.195.121]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 17:46:44 -0400 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Thu, 29 Oct 2009 17:46:41 -0400 From: Marc Linsner To: Brian Rosen Message-ID: Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4AE1y5CAAGs5+wAAX4z4UAAdMnZQACY9dzAAJ55ZE= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 29 Oct 2009 21:46:44.0488 (UTC) FILETIME=[4EB57080:01CA58E1] Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Thu, 29 Oct 2009 21:46:33 -0000 Brian, I didn't read anything in the draft that stated devices 'should' use this mechanism (if it's there, it needs removed). I read it more as a device 'could' use this mechanism (as in an alternative to other mechanisms). Further, since the ESRP is controlled by the PSAP, it certainly would be a PSAP policy decision whether to support this mechanism. As without the ESRP support of unknown UA registrations, the mechanism doesn't work. BTW, the term 'unregistered' is not in phonebcp. I think your are stretching the 'normal call path' to include registration with something(?). I find nothing in phonebcp that disallows 'direct' calls to an ESRP. If I contact an ESRP from my UA 'directly', as long as the PSAP can call-back using the Contact header I sent in the invite and my AOR leads back to my UA, I've satisfied phonebcp. What am I missing? -Marc- On 10/29/09 4:35 PM, "Brian Rosen" wrote: > The IETF writing standards that describe how devices should bypass their > service provider and place emergency calls direct is not a PSAP policy > issue. > > I'm satisfied with the current -phonebcp dictum to send calls on the normal > call path. For an "unregistered" device, that will not allow any "calls" > including emergency calls. > > I discussed this draft on the NENA LTD meeting this morning. That may > generate some list discussion from some PSAP people who are subscribed. I > would also like to hear from more PSAP folks on this subject. > > Brian > > > On 10/29/09 3:27 PM, "Marc Linsner" wrote: > >> These are all PSAP policy decisions. Just as it's a PSAP policy decision to >> support the suggested mechanism in the draft. Existence of the document >> describing the mechanism doesn't force PSAP policy. >> >> I personally would like to see some PSAPs and/or PS jurisdictions line up >> behind the draft before it proceeds, but I don't see any harm in it going >> forward. >> >> Of course, I'm dreaming about this special place where a PSAP actually wants >> to enable communication with all their customers and not force them to be a >> member of a special club. >> >> [non-chair hat on] >> >> -Marc- >> >> >> On 10/29/09 2:35 PM, "Brian Rosen" wrote: >> >>> Thank you. That is what I meant, and you said it better than I was going >>> to. >>> >>> We may also have some transitive relationships: that is, if there is a >>> "local" PSAP that trusts that they have done so, other PSAPs may trust that >>> they have done so. >>> >>> Brian >>> >>> On 10/29/09 11:48 AM, "DRAGE, Keith (Keith)" >>> wrote: >>> >>>> I suspect that what Brian is saying is that anyone can be a service >>>> provider >>>> (or whatever else you want to call it) in this case provided that: >>>> >>>> 1) they make that agreement with the PSAP providers they route calls >>>> to; >>>> >>>> 2) they authenticate the calls requests to a level of security that >>>> meets >>>> the PSAPs (and any legal) requirements; >>>> >>>> 3) the PSAP trusts that they have done so. >>>> >>>> While this would normally be what we would understand as public >>>> telecommuncation operators, it doesn't mean they have to be. >>>> >>>> regards >>>> >>>> Keith >>>> >>>>> -----Original Message----- >>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>>>> On Behalf Of Marc Linsner >>>>> Sent: Thursday, October 29, 2009 12:32 PM >>>>> To: Brian Rosen >>>>> Cc: ecrit@ietf.org >>>>> Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>>> considered >>>>> >>>>> Brian, >>>>> >>>>> Please define what you consider to be a service provider. >>>>> >>>>> Is Skype a service? >>>>> Is Jabber a service? >>>>> Is Google Voice a service? >>>>> Is mydomain.com hosted on a commercial site a service? >>>>> Is mydomain.com hosted on a home server a service? >>>>> Is myEnterpriseVoIP.com a service? >>>>> >>>>> So, what you are saying that if I can make calls via all of >>>>> the above, it's OK for all of the above to contact an ESRP? >>>>> >>>>> Are you requiring that I have a full-time proxy on-line for >>>>> mydomain.com or can I simply run a transient UA and dynamic DNS? >>>>> >>>>> -Marc- >>>>> >>>>> >>>>> >>>>> On 10/28/09 11:17 PM, "Brian Rosen" wrote: >>>>> >>>>>> I'm not worried about security by obscurity. I don't want >>>>> phones (or >>>>>> other >>>>>> devices) built to call directly. >>>>>> >>>>>> -phonebcp says "send the call on your normal outbound call path". >>>>>> That's what I want it to say, and I don't want it to say "send it >>>>>> direct, bypass your service provider. >>>>>> >>>>>> I'm not stopping attack, I am stopping abuse. >>>>>> >>>>>> I don't want devices that are not subscribed to services to >>>>> be able to >>>>>> make emergency calls (that is, if they can't make "normal" >>>>> calls, they >>>>>> should not be able to make emergency calls). >>>>>> >>>>>> Brian >>>>>> >>>>>> >>>>>> On 10/28/09 6:51 PM, "Marc Linsner" wrote: >>>>>> >>>>>>> Brian, >>>>>>> >>>>>>> What I hear you saying: 'if we don't document how to spoof a PSAP, >>>>>>> then nobody will figure it out.' Isn't that a little >>>>> short sighted? >>>>>>> >>>>>>> Joey@miscreant.org will figure out how to establish a SIP session >>>>>>> with any PSAP in the world within 10 minutes of that PSAP being >>>>>>> accessible via the Internet, regardless of documentation. >>>>>>> >>>>>>> I believe there's more harm created in not documenting this for >>>>>>> John.Q.Public@ordinary_citizen.com. >>>>>>> >>>>>>> Granted, nobody here is looking to cause harm to a PSAP. But >>>>>>> Joey@miscreant.org can certainly expend public safety resources by >>>>>>> reporting a bomb threat to a local school. Should we require that >>>>>>> all SIP calls to the local school come from a trusted SP? >>>>> Where does it end? >>>>>>> >>>>>>> This isn't the way to deal with spam. >>>>>>> >>>>>>> -Marc- >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 10/27/09 11:00 AM, "Brian Rosen" wrote: >>>>>>> >>>>>>>> The first goal is to prevent bad calls. >>>>>>>> >>>>>>>> The second goal is to indentify the source of the bad calls. >>>>>>>> >>>>>>>> I'm starting with the first goal. I don't want you to be able to >>>>>>>> take a device out of a box, plug it into a network, and have the >>>>>>>> only call you can make be an emergency call. I want the >>>>> device to >>>>>>>> actually "work" (as in be able to place calls to all the entities >>>>>>>> that it was intended to) first, and then be able to place >>>>> emergency calls. >>>>>>>> >>>>>>>> Please spend some time in a PSAP while a kid with a >>>>> simless phone has "fun" >>>>>>>> with it. Imagine how much fun the test mechanism is as >>>>> opposed to >>>>>>>> placing real calls. >>>>>>>> >>>>>>>> If we somehow get a bad call, we need to send the cops. >>>>> That means >>>>>>>> we need an identity (and a location). >>>>>>>> >>>>>>>> I think a good cert could be the basis of a good identity, if we >>>>>>>> could get one. I don't see how we do that. >>>>>>>> >>>>>>>> Brian >>>>>>>> >>>>>>>> >>>>>>>> On 10/27/09 10:39 AM, "Richard Barnes" wrote: >>>>>>>> >>>>>>>>> Brian, >>>>>>>>> >>>>>>>>> Is the security goal here more access control (i.e., controlling >>>>>>>>> who can send calls to a PSAP) or attribution/identification for >>>>>>>>> post-hoc action. >>>>>>>>> >>>>>>>>> If it's the latter, then ISTM that the problem can largely be >>>>>>>>> reduced to having a certificate infrastructure that binds >>>>>>>>> authenticated identities to real-world entities. The >>>>> "extended validation" >>>>>>>>> certificates that current commercial CAs issue seem to largely >>>>>>>>> satisfy this requirement. >>>>>>>>> >>>>>>>>> --Richard >>>>>>>>> >>>>>>>>> >>>>>>>>> On Oct 27, 2009, at 4:31 PM, Brian Rosen wrote: >>>>>>>>> >>>>>>>>>> Of course not all VSPs will have trust relationships with all >>>>>>>>>> PSAPs. One can hope that long term, we can evolve to >>>>> transitive >>>>>>>>>> trust relationships that work pretty well cross border. >>>>>>>>>> >>>>>>>>>> The emergency guys are actually terrified of private/individual >>>>>>>>>> domains sending them calls, and we're telling them we >>>>> expect that >>>>>>>>>> to be possible, but rare, and we're giving them mechanisms that >>>>>>>>>> will effectively allow them to turn off calls >>>>> selectively, based >>>>>>>>>> on factors including what domain the call comes from. >>>>> They expect >>>>>>>>>> that such calls will be one of the loopholes where they get >>>>>>>>>> equivalents to sim-less calls, which drive them nuts. >>>>> They don't >>>>>>>>>> want ANY calls that don't come from service providers, although >>>>>>>>>> they seem to be okay with the notion that the SP may not have >>>>>>>>>> great identity (AOL being a poster child). So, while >>>>> indeed they >>>>>>>>>> understand, and have concerns about having to take calls from >>>>>>>>>> Sierra Leone VoIP services Pty, they would much rather >>>>> have a call >>>>>>>>>> that went through them then a call that went through no service >>>>>>>>>> provider at all. >>>>>>>>>> >>>>>>>>>> I'm not trying to make calls direct from devices or private >>>>>>>>>> domains impossible, but I think the notion that we're promoting >>>>>>>>>> them is a very bad idea until we have effective mechanisms to >>>>>>>>>> prevent abuse. >>>>>>>>>> >>>>>>>>>> Brian >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 10/27/09 9:02 AM, "Marc Linsner" wrote: >>>>>>>>>> >>>>>>>>>>> Brian, >>>>>>>>>>> >>>>>>>>>>> I'm a little confused. I don't remember you objecting to >>>>>>>>>>> requirement RE1 from RFC5012 and I remember your use >>>>> case about a >>>>>>>>>>> Sierra Leone VSP. >>>>>>>>>>> >>>>>>>>>>> Are you implying that *all* VSPs will have a trust >>>>> relationships >>>>>>>>>>> with *all* PSAPs? >>>>>>>>>>> >>>>>>>>>>> What is the difference between a call coming from a private/ >>>>>>>>>>> individual domain (as in not a commercial VSP) and a >>>>> VSP on the >>>>>>>>>>> other side of the world (outside the jurisdiction)? >>>>>>>>>>> >>>>>>>>>>> I'm trying to figure out whether you're objecting to anonymous >>>>>>>>>>> calls to the PSAP or the mechanisms proposed in this draft? >>>>>>>>>>> >>>>>>>>>>> [Don't take this as my endorsement of the draft, as >>>>> I'm not sure >>>>>>>>>>> I agree with UAs registering with the ESRP.] >>>>>>>>>>> >>>>>>>>>>> -Marc- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 10/26/09 8:59 PM, "Brian Rosen" wrote: >>>>>>>>>>> >>>>>>>>>>>> First of all, I put it on the wrong email list, sorry >>>>> about that. >>>>>>>>>>>> >>>>>>>>>>>> Then, we have carefully arranged it so that there is >>>>> no identity >>>>>>>>>>>> coming from the access network provider, and because the >>>>>>>>>>>> location is coming from that provider, we really >>>>> don't want to. >>>>>>>>>>>> But even if we did, we would need a really good >>>>> identifier, and >>>>>>>>>>>> there isn't one. >>>>>>>>>>>> >>>>>>>>>>>> The problem we have with -direct is anonymous callers, and if >>>>>>>>>>>> they have any option, they would also be >>>>> location-less. Until >>>>>>>>>>>> and unless we get rid of anonymity, we can't >>>>> encourage service >>>>>>>>>>>> provider-less calls. The draft does not make any >>>>> provision to >>>>>>>>>>>> provide any kind of identity. Many networks (think free wifi >>>>>>>>>>>> for example) would make providing good identity difficult. >>>>>>>>>>>> >>>>>>>>>>>> The fact is that there is a SERVICE provider in >>>>> nearly all of the >>>>>>>>>>>> communications systems. The SERVICE provider is in >>>>> a position to >>>>>>>>>>>> assist >>>>>>>>>>>> the emergency calling system when it needs more information. >>>>>>>>>>>> That's what a >>>>>>>>>>>> good SERVICE provider does. Cutting them out is not a great >>>>>>>>>>>> idea. Most of the attempts to provide real time >>>>> communications >>>>>>>>>>>> between people have evolved to using service providers, even >>>>>>>>>>>> when there were alternatives. File transfer via >>>>> something like >>>>>>>>>>>> Torrent is a counterexample (which isn't real time), but even >>>>>>>>>>>> there, you end up with service providers like The Pirate Bay >>>>>>>>>>>> (R.I.P) to provide introduction services. I don't >>>>> think we're >>>>>>>>>>>> going to see changes that eliminate service providers, and in >>>>>>>>>>>> this case, they provide value to the emergency >>>>> calling systems. >>>>>>>>>>>> All of the emergency professionals I know have issues with >>>>>>>>>>>> service providers, but they would react with horror if you >>>>>>>>>>>> suggested cutting them out. Ask them, please. >>>>>>>>>>>> >>>>>>>>>>>> So, I claim you have a solution in search of a >>>>> problem. We have >>>>>>>>>>>> solved the "calling network isn't the access network" problem >>>>>>>>>>>> already. Service providers ARE in the path now, in >>>>> nearly every >>>>>>>>>>>> case (in fact a counter example escapes me, although there >>>>>>>>>>>> probably are some). There is no movement I can detect which >>>>>>>>>>>> would change that any time soon; quite the opposite. >>>>> We have a >>>>>>>>>>>> known killer problem without some kind of subscription to a >>>>>>>>>>>> service that provides a good identity, for which you >>>>> provide no >>>>>>>>>>>> answers. >>>>>>>>>>>> We have >>>>>>>>>>>> experience with the killer problem: sim-less calling was >>>>>>>>>>>> supposed to provide a way to make an emergency call >>>>> in exactly >>>>>>>>>>>> the kinds of circumstances you are describing. Our >>>>> real world >>>>>>>>>>>> experience is that you create a huge problem that diverts >>>>>>>>>>>> resources from helping people to chasing scammers and >>>>>>>>>>>> flea-market sellers. >>>>>>>>>>>> >>>>>>>>>>>> Nothing is perfect: you can get a AIM screen name >>>>> without a very >>>>>>>>>>>> good identity for example. However, the notion that >>>>> we're going >>>>>>>>>>>> to provide direct access without a service provider >>>>>>>>>>>> deliberately, especially without really good identity >>>>> from the >>>>>>>>>>>> access network is, in my opinion not only a no, it's >>>>> a heck no. >>>>>>>>>>>> I'll line up as many emergency service professionals as you >>>>>>>>>>>> would like to tell you this is a harmful idea. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/26/09 7:56 PM, "Dawson, Martin" >>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> I am glad this has come up. It's a debate that has >>>>> to happen if >>>>>>>>>>>> we are to move beyond a long standing legacy misconception. >>>>>>>>>>>> >>>>>>>>>>>> In the circuit service world - whether it was POTS >>>>> or mobile, >>>>>>>>>>>> the access network had full responsibility for >>>>> delivering the >>>>>>>>>>>> emergency call. In that world, routing an emergency >>>>> call meant >>>>>>>>>>>> getting a circuit established to the correct call center. In >>>>>>>>>>>> most parts of the world, this was done using the >>>>> regional part >>>>>>>>>>>> of the PSTN to switch the circuit to a call center >>>>> on the PSTN. >>>>>>>>>>>> In some jurisdictions, such as the US, it was done directly >>>>>>>>>>>> from the local exchange carrier to the call center. >>>>> Either way, >>>>>>>>>>>> there was no third party involved. >>>>>>>>>>>> >>>>>>>>>>>> Now we have the Internet. We still have public >>>>> access network >>>>>>>>>>>> providers. >>>>>>>>>>>> They >>>>>>>>>>>> switch packets onto the Internet for their subscribers. They >>>>>>>>>>>> can similarly ensure that packets reach the local emergency >>>>>>>>>>>> call centers. >>>>>>>>>>>> >>>>>>>>>>>> The fact is that there was no equivalent of a VSP in the >>>>>>>>>>>> traditional environment. VoIP is a presence service, >>>>> and it had >>>>>>>>>>>> no common equivalent in the PSTN world. It could >>>>> have, but the >>>>>>>>>>>> narrowband state of technology and the common market >>>>> use cases >>>>>>>>>>>> didn't support its development. By the time ISDN >>>>> arrived, the >>>>>>>>>>>> PSTN had already slipped into its palliative stage without >>>>>>>>>>>> realizing it. >>>>>>>>>>>> >>>>>>>>>>>> It's an entrenched misconception that because the circuit >>>>>>>>>>>> service provided by exchange carriers was most commonly used >>>>>>>>>>>> for "voice" (but, it should be noted, also for fax, >>>>> telex, tty, >>>>>>>>>>>> security system monitoring and, even, IP data) that VSPs are >>>>>>>>>>>> somehow equivalent to exchange carriers. They are not. >>>>>>>>>>>> >>>>>>>>>>>> Indeed, involving VSPs in emergency calls is the Internet >>>>>>>>>>>> equivalent of involving long distance providers in POTS >>>>>>>>>>>> emergency calls. They are neither necessary nor particularly >>>>>>>>>>>> helpful; they can't be guaranteed to be within the emergency >>>>>>>>>>>> jurisdiction; depending on them actually diminishes the >>>>>>>>>>>> efficacy of emergency service access. It does not help the >>>>>>>>>>>> caller, the emergency service, nor the third party >>>>> to insist on >>>>>>>>>>>> the third party's involvement. >>>>>>>>>>>> >>>>>>>>>>>> It can't be helped if you have over sold the benefits of VSP >>>>>>>>>>>> involvement to yourself and others Brian. It is time >>>>> to have a >>>>>>>>>>>> reasoned debate. >>>>>>>>>>>> From my >>>>>>>>>>>> perspective, the argument that there is no "subscription" >>>>>>>>>>>> involved is >>>>>>>>>>>> patently >>>>>>>>>>>> false. There has to be a subscription of some description in >>>>>>>>>>>> order to get to the Internet. Yes, there is free public >>>>>>>>>>>> Internet access (just as there are free courtesy >>>>> phones on the >>>>>>>>>>>> PSTN and free access to emergency services from pay >>>>> phones. All >>>>>>>>>>>> these services are still connected to the public Internet >>>>>>>>>>>> infrastructure and they all represent an "operator" >>>>> with some >>>>>>>>>>>> level of information about the caller. >>>>>>>>>>>> >>>>>>>>>>>> With the over-emphasis on VSPs, what is missing from >>>>> the ECRIT >>>>>>>>>>>> and i3 models is the direct interface for querying >>>>> the access >>>>>>>>>>>> network for subscriber data (should it prove >>>>> necessary). These >>>>>>>>>>>> models need to take the long view of how emergency >>>>> calling is >>>>>>>>>>>> done in the Internet age; they should not be protracting an >>>>>>>>>>>> unnecessary reliance on VSPs. >>>>>>>>>>>> >>>>>>>>>>>> I have deleted the premature and prejudicial text from the >>>>>>>>>>>> subject heading. >>>>>>>>>>>> And I'll leave this on ECRIT as the most appropriate WG. >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> Martin >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: ecrit-bounces@ietf.org >>>>> [mailto:ecrit-bounces@ietf.org] On >>>>>>>>>>>> Behalf Of Hannes Tschofenig >>>>>>>>>>>> Sent: Tuesday, 27 October 2009 8:23 AM >>>>>>>>>>>> To: ecrit@ietf.org >>>>>>>>>>>> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>>>>>>>>>> considered harmful, at least given our current experiences >>>>>>>>>>>> >>>>>>>>>>>> FYI: feedback from Brian regarding a recent ECRIT >>>>> contribution. >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: geopriv-bounces@ietf.org >>>>>>>>>>>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian >>>>>>>>>>>> Sent: 26 October, 2009 23:10 >>>>>>>>>>>> To: geopriv@ietf.org >>>>>>>>>>>> Subject: [Geopriv] Winterbottom-ecrit-direct considered >>>>>>>>>>>> harmful, at least given our current experiences >>>>>>>>>>>> >>>>>>>>>>>> The notion behind -direct is to not use a service >>>>> provider to >>>>>>>>>>>> place an emergency call. Instead, the device >>>>> registers with >>>>>>>>>>>> an Emergency Services Routing Proxy immediately before the >>>>>>>>>>>> call and the call is routed directly from the >>>>> device to the ESRP. >>>>>>>>>>>> >>>>>>>>>>>> At least at the moment, this is an exceedingly bad idea. >>>>>>>>>>>> >>>>>>>>>>>> Emergency calling authorities like service providers, a lot. >>>>>>>>>>>> They like them because they can hold them >>>>> accountable, and the >>>>>>>>>>>> service providers don't like theft of service, which is >>>>>>>>>>>> something the emergency call guys have an analog to. >>>>>>>>>>>> >>>>>>>>>>>> The facts are that where unaccountable access to emergency >>>>>>>>>>>> calling is allowed, huge numbers of false calls >>>>> occur, with no >>>>>>>>>>>> way to stop them, and no way to tell the good ones from the >>>>>>>>>>>> bad ones. This has been seen multiple times where >>>>> so called >>>>>>>>>>>> "simless" or "unauthenticated" calls are allowed. >>>>>>>>>>>> >>>>>>>>>>>> -direct precisely duplicates simless calling. The only >>>>>>>>>>>> "registration" is an emergency registration, only emergency >>>>>>>>>>>> calls are allowed, any device can make an emergency call if >>>>>>>>>>>> all it has is a (radio) connection to any network. >>>>>>>>>>>> We can predict, with a very high degree of >>>>> certainty, that the >>>>>>>>>>>> feature will be horribly abused: for example to test that a >>>>>>>>>>>> phone without a service plan works. >>>>>>>>>>>> >>>>>>>>>>>> There have been studies which show tens of thousands of bad >>>>>>>>>>>> calls with zero good ones. Nearly every authority I know >>>>>>>>>>>> where the regulator has insisted on simless calling >>>>> wants it >>>>>>>>>>>> repealed. There is one counter example I know >>>>> where the fact >>>>>>>>>>>> that they got a couple, literally, of good calls among the >>>>>>>>>>>> tens of thousands of bad calls was considered >>>>> enough reason to >>>>>>>>>>>> put up with the problem. >>>>>>>>>>>> >>>>>>>>>>>> Service providers give us information that may be useful: a >>>>>>>>>>>> subscriber name and address for example, which is not >>>>>>>>>>>> spoofable by the caller. They have ways to trace callers, >>>>>>>>>>>> especially bad callers. They don't want their >>>>> systems abused >>>>>>>>>>>> any more than the emergency calling authorities do. >>>>>>>>>>>> >>>>>>>>>>>> This is a bad idea. A very bad idea. Please stop it. >>>>>>>>>>>> >>>>>>>>>>>> Someday, we may have better ways to prevent abuse. Until we >>>>>>>>>>>> do, service providers are a good thing on an emergency call. >>>>>>>>>>>> We don't want them cut out. >>>>>>>>>>>> >>>>>>>>>>>> Brian >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Geopriv mailing list >>>>>>>>>>>> Geopriv@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 hgs@cs.columbia.edu Thu Oct 29 15:15:54 2009 Return-Path: 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 99B9128C0F0 for ; Thu, 29 Oct 2009 15:15:54 -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 1NfTeGkdwznc for ; Thu, 29 Oct 2009 15:15:52 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id DA9D03A67ED for ; Thu, 29 Oct 2009 15:15:51 -0700 (PDT) Received: from [10.10.11.1] (armoursquare.rice.iit.edu [64.131.110.238]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id n9TMFwTG017800 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 29 Oct 2009 18:15:59 -0400 (EDT) References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Date: Thu, 29 Oct 2009 18:15:58 -0400 To: Brian Rosen X-Mailer: Apple Mail (2.1076) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.6 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Thu, 29 Oct 2009 22:15:54 -0000 I think we should not be too constrained by the arrangements today, where the VSP or possibly ISP provides caller authentication. There are other models; for example, I just heard a talk about the Austrian (cryptographic) identity card that is leveraged by lots of other institutions, including private entities (banks, health clubs, ...). For SIP, this could be used for RFC 4474. Thus, you could imagine that the authentication is done individually, at higher strength than typical carrier authentication with semi-anonymous accounts. As per the example, this may be viable in certain jurisdictions before it's feasible elsewhere. There's a lot of activity in the identity space, so we should be allowing for a variety of future options, rather than just what's happening today. Henning On Oct 29, 2009, at 4:35 PM, Brian Rosen wrote: > The IETF writing standards that describe how devices should bypass > their > service provider and place emergency calls direct is not a PSAP policy > issue. > > I'm satisfied with the current -phonebcp dictum to send calls on the > normal > call path. For an "unregistered" device, that will not allow any > "calls" > including emergency calls. > > I discussed this draft on the NENA LTD meeting this morning. That may > generate some list discussion from some PSAP people who are > subscribed. I > would also like to hear from more PSAP folks on this subject. > > Brian > > > On 10/29/09 3:27 PM, "Marc Linsner" wrote: > >> These are all PSAP policy decisions. Just as it's a PSAP policy >> decision to >> support the suggested mechanism in the draft. Existence of the >> document >> describing the mechanism doesn't force PSAP policy. >> >> I personally would like to see some PSAPs and/or PS jurisdictions >> line up >> behind the draft before it proceeds, but I don't see any harm in it >> going >> forward. >> >> Of course, I'm dreaming about this special place where a PSAP >> actually wants >> to enable communication with all their customers and not force them >> to be a >> member of a special club. >> >> [non-chair hat on] >> >> -Marc- >> >> >> On 10/29/09 2:35 PM, "Brian Rosen" wrote: >> >>> Thank you. That is what I meant, and you said it better than I >>> was going >>> to. >>> >>> We may also have some transitive relationships: that is, if there >>> is a >>> "local" PSAP that trusts that they have done so, other PSAPs may >>> trust that >>> they have done so. >>> >>> Brian >>> >>> On 10/29/09 11:48 AM, "DRAGE, Keith (Keith)" >> > >>> wrote: >>> >>>> I suspect that what Brian is saying is that anyone can be a >>>> service provider >>>> (or whatever else you want to call it) in this case provided that: >>>> >>>> 1) they make that agreement with the PSAP providers they >>>> route calls >>>> to; >>>> >>>> 2) they authenticate the calls requests to a level of >>>> security that >>>> meets >>>> the PSAPs (and any legal) requirements; >>>> >>>> 3) the PSAP trusts that they have done so. >>>> >>>> While this would normally be what we would understand as public >>>> telecommuncation operators, it doesn't mean they have to be. >>>> >>>> regards >>>> >>>> Keith >>>> >>>>> -----Original Message----- >>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>>>> On Behalf Of Marc Linsner >>>>> Sent: Thursday, October 29, 2009 12:32 PM >>>>> To: Brian Rosen >>>>> Cc: ecrit@ietf.org >>>>> Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>>> considered >>>>> >>>>> Brian, >>>>> >>>>> Please define what you consider to be a service provider. >>>>> >>>>> Is Skype a service? >>>>> Is Jabber a service? >>>>> Is Google Voice a service? >>>>> Is mydomain.com hosted on a commercial site a service? >>>>> Is mydomain.com hosted on a home server a service? >>>>> Is myEnterpriseVoIP.com a service? >>>>> >>>>> So, what you are saying that if I can make calls via all of >>>>> the above, it's OK for all of the above to contact an ESRP? >>>>> >>>>> Are you requiring that I have a full-time proxy on-line for >>>>> mydomain.com or can I simply run a transient UA and dynamic DNS? >>>>> >>>>> -Marc- >>>>> >>>>> >>>>> >>>>> On 10/28/09 11:17 PM, "Brian Rosen" wrote: >>>>> >>>>>> I'm not worried about security by obscurity. I don't want >>>>> phones (or >>>>>> other >>>>>> devices) built to call directly. >>>>>> >>>>>> -phonebcp says "send the call on your normal outbound call path". >>>>>> That's what I want it to say, and I don't want it to say "send it >>>>>> direct, bypass your service provider. >>>>>> >>>>>> I'm not stopping attack, I am stopping abuse. >>>>>> >>>>>> I don't want devices that are not subscribed to services to >>>>> be able to >>>>>> make emergency calls (that is, if they can't make "normal" >>>>> calls, they >>>>>> should not be able to make emergency calls). >>>>>> >>>>>> Brian >>>>>> >>>>>> >>>>>> On 10/28/09 6:51 PM, "Marc Linsner" wrote: >>>>>> >>>>>>> Brian, >>>>>>> >>>>>>> What I hear you saying: 'if we don't document how to spoof a >>>>>>> PSAP, >>>>>>> then nobody will figure it out.' Isn't that a little >>>>> short sighted? >>>>>>> >>>>>>> Joey@miscreant.org will figure out how to establish a SIP >>>>>>> session >>>>>>> with any PSAP in the world within 10 minutes of that PSAP being >>>>>>> accessible via the Internet, regardless of documentation. >>>>>>> >>>>>>> I believe there's more harm created in not documenting this for >>>>>>> John.Q.Public@ordinary_citizen.com. >>>>>>> >>>>>>> Granted, nobody here is looking to cause harm to a PSAP. But >>>>>>> Joey@miscreant.org can certainly expend public safety >>>>>>> resources by >>>>>>> reporting a bomb threat to a local school. Should we require >>>>>>> that >>>>>>> all SIP calls to the local school come from a trusted SP? >>>>> Where does it end? >>>>>>> >>>>>>> This isn't the way to deal with spam. >>>>>>> >>>>>>> -Marc- >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 10/27/09 11:00 AM, "Brian Rosen" wrote: >>>>>>> >>>>>>>> The first goal is to prevent bad calls. >>>>>>>> >>>>>>>> The second goal is to indentify the source of the bad calls. >>>>>>>> >>>>>>>> I'm starting with the first goal. I don't want you to be >>>>>>>> able to >>>>>>>> take a device out of a box, plug it into a network, and have >>>>>>>> the >>>>>>>> only call you can make be an emergency call. I want the >>>>> device to >>>>>>>> actually "work" (as in be able to place calls to all the >>>>>>>> entities >>>>>>>> that it was intended to) first, and then be able to place >>>>> emergency calls. >>>>>>>> >>>>>>>> Please spend some time in a PSAP while a kid with a >>>>> simless phone has "fun" >>>>>>>> with it. Imagine how much fun the test mechanism is as >>>>> opposed to >>>>>>>> placing real calls. >>>>>>>> >>>>>>>> If we somehow get a bad call, we need to send the cops. >>>>> That means >>>>>>>> we need an identity (and a location). >>>>>>>> >>>>>>>> I think a good cert could be the basis of a good identity, if >>>>>>>> we >>>>>>>> could get one. I don't see how we do that. >>>>>>>> >>>>>>>> Brian >>>>>>>> >>>>>>>> >>>>>>>> On 10/27/09 10:39 AM, "Richard Barnes" wrote: >>>>>>>> >>>>>>>>> Brian, >>>>>>>>> >>>>>>>>> Is the security goal here more access control (i.e., >>>>>>>>> controlling >>>>>>>>> who can send calls to a PSAP) or attribution/identification >>>>>>>>> for >>>>>>>>> post-hoc action. >>>>>>>>> >>>>>>>>> If it's the latter, then ISTM that the problem can largely be >>>>>>>>> reduced to having a certificate infrastructure that binds >>>>>>>>> authenticated identities to real-world entities. The >>>>> "extended validation" >>>>>>>>> certificates that current commercial CAs issue seem to largely >>>>>>>>> satisfy this requirement. >>>>>>>>> >>>>>>>>> --Richard >>>>>>>>> >>>>>>>>> >>>>>>>>> On Oct 27, 2009, at 4:31 PM, Brian Rosen wrote: >>>>>>>>> >>>>>>>>>> Of course not all VSPs will have trust relationships with all >>>>>>>>>> PSAPs. One can hope that long term, we can evolve to >>>>> transitive >>>>>>>>>> trust relationships that work pretty well cross border. >>>>>>>>>> >>>>>>>>>> The emergency guys are actually terrified of private/ >>>>>>>>>> individual >>>>>>>>>> domains sending them calls, and we're telling them we >>>>> expect that >>>>>>>>>> to be possible, but rare, and we're giving them mechanisms >>>>>>>>>> that >>>>>>>>>> will effectively allow them to turn off calls >>>>> selectively, based >>>>>>>>>> on factors including what domain the call comes from. >>>>> They expect >>>>>>>>>> that such calls will be one of the loopholes where they get >>>>>>>>>> equivalents to sim-less calls, which drive them nuts. >>>>> They don't >>>>>>>>>> want ANY calls that don't come from service providers, >>>>>>>>>> although >>>>>>>>>> they seem to be okay with the notion that the SP may not have >>>>>>>>>> great identity (AOL being a poster child). So, while >>>>> indeed they >>>>>>>>>> understand, and have concerns about having to take calls from >>>>>>>>>> Sierra Leone VoIP services Pty, they would much rather >>>>> have a call >>>>>>>>>> that went through them then a call that went through no >>>>>>>>>> service >>>>>>>>>> provider at all. >>>>>>>>>> >>>>>>>>>> I'm not trying to make calls direct from devices or private >>>>>>>>>> domains impossible, but I think the notion that we're >>>>>>>>>> promoting >>>>>>>>>> them is a very bad idea until we have effective mechanisms to >>>>>>>>>> prevent abuse. >>>>>>>>>> >>>>>>>>>> Brian >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 10/27/09 9:02 AM, "Marc Linsner" >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Brian, >>>>>>>>>>> >>>>>>>>>>> I'm a little confused. I don't remember you objecting to >>>>>>>>>>> requirement RE1 from RFC5012 and I remember your use >>>>> case about a >>>>>>>>>>> Sierra Leone VSP. >>>>>>>>>>> >>>>>>>>>>> Are you implying that *all* VSPs will have a trust >>>>> relationships >>>>>>>>>>> with *all* PSAPs? >>>>>>>>>>> >>>>>>>>>>> What is the difference between a call coming from a private/ >>>>>>>>>>> individual domain (as in not a commercial VSP) and a >>>>> VSP on the >>>>>>>>>>> other side of the world (outside the jurisdiction)? >>>>>>>>>>> >>>>>>>>>>> I'm trying to figure out whether you're objecting to >>>>>>>>>>> anonymous >>>>>>>>>>> calls to the PSAP or the mechanisms proposed in this draft? >>>>>>>>>>> >>>>>>>>>>> [Don't take this as my endorsement of the draft, as >>>>> I'm not sure >>>>>>>>>>> I agree with UAs registering with the ESRP.] >>>>>>>>>>> >>>>>>>>>>> -Marc- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 10/26/09 8:59 PM, "Brian Rosen" >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> First of all, I put it on the wrong email list, sorry >>>>> about that. >>>>>>>>>>>> >>>>>>>>>>>> Then, we have carefully arranged it so that there is >>>>> no identity >>>>>>>>>>>> coming from the access network provider, and because the >>>>>>>>>>>> location is coming from that provider, we really >>>>> don't want to. >>>>>>>>>>>> But even if we did, we would need a really good >>>>> identifier, and >>>>>>>>>>>> there isn't one. >>>>>>>>>>>> >>>>>>>>>>>> The problem we have with -direct is anonymous callers, >>>>>>>>>>>> and if >>>>>>>>>>>> they have any option, they would also be >>>>> location-less. Until >>>>>>>>>>>> and unless we get rid of anonymity, we can't >>>>> encourage service >>>>>>>>>>>> provider-less calls. The draft does not make any >>>>> provision to >>>>>>>>>>>> provide any kind of identity. Many networks (think free >>>>>>>>>>>> wifi >>>>>>>>>>>> for example) would make providing good identity difficult. >>>>>>>>>>>> >>>>>>>>>>>> The fact is that there is a SERVICE provider in >>>>> nearly all of the >>>>>>>>>>>> communications systems. The SERVICE provider is in >>>>> a position to >>>>>>>>>>>> assist >>>>>>>>>>>> the emergency calling system when it needs more >>>>>>>>>>>> information. >>>>>>>>>>>> That's what a >>>>>>>>>>>> good SERVICE provider does. Cutting them out is not a >>>>>>>>>>>> great >>>>>>>>>>>> idea. Most of the attempts to provide real time >>>>> communications >>>>>>>>>>>> between people have evolved to using service providers, >>>>>>>>>>>> even >>>>>>>>>>>> when there were alternatives. File transfer via >>>>> something like >>>>>>>>>>>> Torrent is a counterexample (which isn't real time), but >>>>>>>>>>>> even >>>>>>>>>>>> there, you end up with service providers like The Pirate >>>>>>>>>>>> Bay >>>>>>>>>>>> (R.I.P) to provide introduction services. I don't >>>>> think we're >>>>>>>>>>>> going to see changes that eliminate service providers, >>>>>>>>>>>> and in >>>>>>>>>>>> this case, they provide value to the emergency >>>>> calling systems. >>>>>>>>>>>> All of the emergency professionals I know have issues with >>>>>>>>>>>> service providers, but they would react with horror if you >>>>>>>>>>>> suggested cutting them out. Ask them, please. >>>>>>>>>>>> >>>>>>>>>>>> So, I claim you have a solution in search of a >>>>> problem. We have >>>>>>>>>>>> solved the "calling network isn't the access network" >>>>>>>>>>>> problem >>>>>>>>>>>> already. Service providers ARE in the path now, in >>>>> nearly every >>>>>>>>>>>> case (in fact a counter example escapes me, although there >>>>>>>>>>>> probably are some). There is no movement I can detect >>>>>>>>>>>> which >>>>>>>>>>>> would change that any time soon; quite the opposite. >>>>> We have a >>>>>>>>>>>> known killer problem without some kind of subscription to a >>>>>>>>>>>> service that provides a good identity, for which you >>>>> provide no >>>>>>>>>>>> answers. >>>>>>>>>>>> We have >>>>>>>>>>>> experience with the killer problem: sim-less calling was >>>>>>>>>>>> supposed to provide a way to make an emergency call >>>>> in exactly >>>>>>>>>>>> the kinds of circumstances you are describing. Our >>>>> real world >>>>>>>>>>>> experience is that you create a huge problem that diverts >>>>>>>>>>>> resources from helping people to chasing scammers and >>>>>>>>>>>> flea-market sellers. >>>>>>>>>>>> >>>>>>>>>>>> Nothing is perfect: you can get a AIM screen name >>>>> without a very >>>>>>>>>>>> good identity for example. However, the notion that >>>>> we're going >>>>>>>>>>>> to provide direct access without a service provider >>>>>>>>>>>> deliberately, especially without really good identity >>>>> from the >>>>>>>>>>>> access network is, in my opinion not only a no, it's >>>>> a heck no. >>>>>>>>>>>> I'll line up as many emergency service professionals as you >>>>>>>>>>>> would like to tell you this is a harmful idea. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/26/09 7:56 PM, "Dawson, Martin" >>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I am glad this has come up. It's a debate that has >>>>> to happen if >>>>>>>>>>>>> we are to move beyond a long standing legacy >>>>>>>>>>>>> misconception. >>>>>>>>>>>>> >>>>>>>>>>>>> In the circuit service world - whether it was POTS >>>>> or mobile, >>>>>>>>>>>>> the access network had full responsibility for >>>>> delivering the >>>>>>>>>>>>> emergency call. In that world, routing an emergency >>>>> call meant >>>>>>>>>>>>> getting a circuit established to the correct call >>>>>>>>>>>>> center. In >>>>>>>>>>>>> most parts of the world, this was done using the >>>>> regional part >>>>>>>>>>>>> of the PSTN to switch the circuit to a call center >>>>> on the PSTN. >>>>>>>>>>>>> In some jurisdictions, such as the US, it was done >>>>>>>>>>>>> directly >>>>>>>>>>>>> from the local exchange carrier to the call center. >>>>> Either way, >>>>>>>>>>>>> there was no third party involved. >>>>>>>>>>>>> >>>>>>>>>>>>> Now we have the Internet. We still have public >>>>> access network >>>>>>>>>>>>> providers. >>>>>>>>>>>>> They >>>>>>>>>>>>> switch packets onto the Internet for their subscribers. >>>>>>>>>>>>> They >>>>>>>>>>>>> can similarly ensure that packets reach the local >>>>>>>>>>>>> emergency >>>>>>>>>>>>> call centers. >>>>>>>>>>>>> >>>>>>>>>>>>> The fact is that there was no equivalent of a VSP in the >>>>>>>>>>>>> traditional environment. VoIP is a presence service, >>>>> and it had >>>>>>>>>>>>> no common equivalent in the PSTN world. It could >>>>> have, but the >>>>>>>>>>>>> narrowband state of technology and the common market >>>>> use cases >>>>>>>>>>>>> didn't support its development. By the time ISDN >>>>> arrived, the >>>>>>>>>>>>> PSTN had already slipped into its palliative stage without >>>>>>>>>>>>> realizing it. >>>>>>>>>>>>> >>>>>>>>>>>>> It's an entrenched misconception that because the circuit >>>>>>>>>>>>> service provided by exchange carriers was most commonly >>>>>>>>>>>>> used >>>>>>>>>>>>> for "voice" (but, it should be noted, also for fax, >>>>> telex, tty, >>>>>>>>>>>>> security system monitoring and, even, IP data) that VSPs >>>>>>>>>>>>> are >>>>>>>>>>>>> somehow equivalent to exchange carriers. They are not. >>>>>>>>>>>>> >>>>>>>>>>>>> Indeed, involving VSPs in emergency calls is the Internet >>>>>>>>>>>>> equivalent of involving long distance providers in POTS >>>>>>>>>>>>> emergency calls. They are neither necessary nor >>>>>>>>>>>>> particularly >>>>>>>>>>>>> helpful; they can't be guaranteed to be within the >>>>>>>>>>>>> emergency >>>>>>>>>>>>> jurisdiction; depending on them actually diminishes the >>>>>>>>>>>>> efficacy of emergency service access. It does not help the >>>>>>>>>>>>> caller, the emergency service, nor the third party >>>>> to insist on >>>>>>>>>>>>> the third party's involvement. >>>>>>>>>>>>> >>>>>>>>>>>>> It can't be helped if you have over sold the benefits of >>>>>>>>>>>>> VSP >>>>>>>>>>>>> involvement to yourself and others Brian. It is time >>>>> to have a >>>>>>>>>>>>> reasoned debate. >>>>>>>>>>>>> From my >>>>>>>>>>>>> perspective, the argument that there is no "subscription" >>>>>>>>>>>>> involved is >>>>>>>>>>>>> patently >>>>>>>>>>>>> false. There has to be a subscription of some >>>>>>>>>>>>> description in >>>>>>>>>>>>> order to get to the Internet. Yes, there is free public >>>>>>>>>>>>> Internet access (just as there are free courtesy >>>>> phones on the >>>>>>>>>>>>> PSTN and free access to emergency services from pay >>>>> phones. All >>>>>>>>>>>>> these services are still connected to the public Internet >>>>>>>>>>>>> infrastructure and they all represent an "operator" >>>>> with some >>>>>>>>>>>>> level of information about the caller. >>>>>>>>>>>>> >>>>>>>>>>>>> With the over-emphasis on VSPs, what is missing from >>>>> the ECRIT >>>>>>>>>>>>> and i3 models is the direct interface for querying >>>>> the access >>>>>>>>>>>>> network for subscriber data (should it prove >>>>> necessary). These >>>>>>>>>>>>> models need to take the long view of how emergency >>>>> calling is >>>>>>>>>>>>> done in the Internet age; they should not be protracting >>>>>>>>>>>>> an >>>>>>>>>>>>> unnecessary reliance on VSPs. >>>>>>>>>>>>> >>>>>>>>>>>>> I have deleted the premature and prejudicial text from the >>>>>>>>>>>>> subject heading. >>>>>>>>>>>>> And I'll leave this on ECRIT as the most appropriate WG. >>>>>>>>>>>>> >>>>>>>>>>>>> Cheers, >>>>>>>>>>>>> Martin >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: ecrit-bounces@ietf.org >>>>> [mailto:ecrit-bounces@ietf.org] On >>>>>>>>>>>>> Behalf Of Hannes Tschofenig >>>>>>>>>>>>> Sent: Tuesday, 27 October 2009 8:23 AM >>>>>>>>>>>>> To: ecrit@ietf.org >>>>>>>>>>>>> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>>>>>>>>>>> considered harmful, at least given our current experiences >>>>>>>>>>>>> >>>>>>>>>>>>> FYI: feedback from Brian regarding a recent ECRIT >>>>> contribution. >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: geopriv-bounces@ietf.org >>>>>>>>>>>>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, >>>>>>>>>>>>> Brian >>>>>>>>>>>>> Sent: 26 October, 2009 23:10 >>>>>>>>>>>>> To: geopriv@ietf.org >>>>>>>>>>>>> Subject: [Geopriv] Winterbottom-ecrit-direct considered >>>>>>>>>>>>> harmful, at least given our current experiences >>>>>>>>>>>>> >>>>>>>>>>>>> The notion behind -direct is to not use a service >>>>> provider to >>>>>>>>>>>>> place an emergency call. Instead, the device >>>>> registers with >>>>>>>>>>>>> an Emergency Services Routing Proxy immediately before the >>>>>>>>>>>>> call and the call is routed directly from the >>>>> device to the ESRP. >>>>>>>>>>>>> >>>>>>>>>>>>> At least at the moment, this is an exceedingly bad idea. >>>>>>>>>>>>> >>>>>>>>>>>>> Emergency calling authorities like service providers, a >>>>>>>>>>>>> lot. >>>>>>>>>>>>> They like them because they can hold them >>>>> accountable, and the >>>>>>>>>>>>> service providers don't like theft of service, which is >>>>>>>>>>>>> something the emergency call guys have an analog to. >>>>>>>>>>>>> >>>>>>>>>>>>> The facts are that where unaccountable access to emergency >>>>>>>>>>>>> calling is allowed, huge numbers of false calls >>>>> occur, with no >>>>>>>>>>>>> way to stop them, and no way to tell the good ones from >>>>>>>>>>>>> the >>>>>>>>>>>>> bad ones. This has been seen multiple times where >>>>> so called >>>>>>>>>>>>> "simless" or "unauthenticated" calls are allowed. >>>>>>>>>>>>> >>>>>>>>>>>>> -direct precisely duplicates simless calling. The only >>>>>>>>>>>>> "registration" is an emergency registration, only >>>>>>>>>>>>> emergency >>>>>>>>>>>>> calls are allowed, any device can make an emergency call >>>>>>>>>>>>> if >>>>>>>>>>>>> all it has is a (radio) connection to any network. >>>>>>>>>>>>> We can predict, with a very high degree of >>>>> certainty, that the >>>>>>>>>>>>> feature will be horribly abused: for example to test >>>>>>>>>>>>> that a >>>>>>>>>>>>> phone without a service plan works. >>>>>>>>>>>>> >>>>>>>>>>>>> There have been studies which show tens of thousands of >>>>>>>>>>>>> bad >>>>>>>>>>>>> calls with zero good ones. Nearly every authority I know >>>>>>>>>>>>> where the regulator has insisted on simless calling >>>>> wants it >>>>>>>>>>>>> repealed. There is one counter example I know >>>>> where the fact >>>>>>>>>>>>> that they got a couple, literally, of good calls among the >>>>>>>>>>>>> tens of thousands of bad calls was considered >>>>> enough reason to >>>>>>>>>>>>> put up with the problem. >>>>>>>>>>>>> >>>>>>>>>>>>> Service providers give us information that may be >>>>>>>>>>>>> useful: a >>>>>>>>>>>>> subscriber name and address for example, which is not >>>>>>>>>>>>> spoofable by the caller. They have ways to trace callers, >>>>>>>>>>>>> especially bad callers. They don't want their >>>>> systems abused >>>>>>>>>>>>> any more than the emergency calling authorities do. >>>>>>>>>>>>> >>>>>>>>>>>>> This is a bad idea. A very bad idea. Please stop it. >>>>>>>>>>>>> >>>>>>>>>>>>> Someday, we may have better ways to prevent abuse. Until >>>>>>>>>>>>> we >>>>>>>>>>>>> do, service providers are a good thing on an emergency >>>>>>>>>>>>> call. >>>>>>>>>>>>> We don't want them cut out. >>>>>>>>>>>>> >>>>>>>>>>>>> Brian >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Geopriv mailing list >>>>>>>>>>>>> Geopriv@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 Hannes.Tschofenig@gmx.net Thu Oct 29 18:35:06 2009 Return-Path: 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 E88AE3A67FC for ; Thu, 29 Oct 2009 18:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 e9DcCBA8T2Av for ; Thu, 29 Oct 2009 18:35:06 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id BF8A73A67A2 for ; Thu, 29 Oct 2009 18:35:05 -0700 (PDT) Received: (qmail invoked by alias); 30 Oct 2009 01:35:20 -0000 Received: from 72-255-125-40.client.stsn.net (EHLO 4FIL42860) [72.255.125.40] by mail.gmx.net (mp057) with SMTP; 30 Oct 2009 02:35:20 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX180X8sSlwo0S0svUuUq8ulA7HJ7dmaZKoDg10ex11 Sg1mcWT4O+bWxp From: "Hannes Tschofenig" To: Date: Fri, 30 Oct 2009 03:38:35 +0200 Message-ID: <064301ca5901$b40cd660$98221f80@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpZAbItVRa7qaRdRmSLPaSKlZvKKA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.78 Subject: [Ecrit] Agenda proposal 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: , X-List-Received-Date: Fri, 30 Oct 2009 01:35:07 -0000 Hi all, I have just crafted an agenda proposal and you can find it here: http://www.ietf.org/proceedings/09nov/agenda/ecrit.txt Please let me know what you think about it. Ciao Hannes From Martin.Dawson@andrew.com Thu Oct 29 18:45:19 2009 Return-Path: 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 2A4103A67A2 for ; Thu, 29 Oct 2009 18:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 0j3VcwpGXcZJ for ; Thu, 29 Oct 2009 18:45:16 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.243]) by core3.amsl.com (Postfix) with ESMTP id 774903A68EC for ; Thu, 29 Oct 2009 18:45:16 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:6083 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S4847762AbZJ3Bpb convert rfc822-to-8bit (ORCPT ); Thu, 29 Oct 2009 20:45:31 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.393.1; Thu, 29 Oct 2009 20:45:30 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Fri, 30 Oct 2009 09:45:27 +0800 From: "Dawson, Martin" To: Brian Rosen , Marc Linsner Date: Fri, 30 Oct 2009 09:45:25 +0800 Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4AE1y5CAAGs5+wAAX4z4UAAdMnZQACY9dzAAoyaeA= Message-ID: <8B0A9FCBB9832F43971E38010638454F0F251A78@SISPE7MB1.commscope.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Dawson@andrew.com Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Fri, 30 Oct 2009 01:45:19 -0000 Hi Brian, The significance of "VSPs" is twofold: 1. They are a presence service (long term significance) 2. They provide a bridging service to the circuit service world (temporary significance) You are taking the temporary significance and attempting to hard code it into a long term role. You have been using the term "service" as if it means something quite specific (it does not). Focussing on the following comment: " The IETF writing standards that describe how devices should bypass their service provider and place emergency calls direct is not a PSAP policy issue." It seems presumptious. You appear to want to prevent the IETF from saying how an Internet connected device can establish communication with an Internet connected emergency service. You appear to be saying that there is some "official service provider" that has to be in the middle for this to happen. The phrase "bypass their service provider" implies presumption of some formal role that I don't think exists. I travel to the US frequently; if I subscribe to T-Mobile's hotspot network for example, then I want to be able to make an emergency call from that point of connection. I don't want to have to previously ensure that I have a subscription with some or other "service" through whom I have to go if I want emergency service. I am subscribed to a service - "TMO's hotspot network" - that's the real subscriber information and point of regulatory control that is relevant. If I have a MiFi device in my car connected to Verizon's 3G service and there are a variety of devices connected to the Internet through that device, then I want those devices to be valid options to make an emergency call. If my child has their PSP connected via it then I want them to be able to call help without the presumption that there also has to be some sort of VoIP subscription on that PSP. I am subscribed to a service in this context - "Verizon's 3G service" - that's the real subscriber information and point of regulatory control in that use case. I don't know where this "edict" comes from that only devices that are normally used to "make calls" should be able to make emergency calls. Time and technology makes the whole presumption of what constitutes "making calls" a pretty fuzzy concept. You seem to have invented a problem, then invented a solution which... ironically... doesn't address the invented problem anyway. Either access to LoST emergency routing requests and to PSAP URIs is going to be blocked to all but a privileged set of VoIP providers or there's a hole in the "solution" that can have a truck driven through it. The draft proposed provides excellent guidance for a general and reference Internet emergency calling client that is consistent with ECRIT. It provides excellent guidance for jurisdictions that want to provide emergency access from the Internet, isolated to their jurisdiction, and without presumption of, potentially foreign, VSP involvement. Personally I think it's what Phone BCP always could have been but, regardless, it's neither dangerous nor useless as you seem to be suggesting. Cheers, Martin -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Friday, 30 October 2009 7:36 AM To: Marc Linsner Cc: ecrit@ietf.org Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered The IETF writing standards that describe how devices should bypass their service provider and place emergency calls direct is not a PSAP policy issue. I'm satisfied with the current -phonebcp dictum to send calls on the normal call path. For an "unregistered" device, that will not allow any "calls" including emergency calls. I discussed this draft on the NENA LTD meeting this morning. That may generate some list discussion from some PSAP people who are subscribed. I would also like to hear from more PSAP folks on this subject. Brian On 10/29/09 3:27 PM, "Marc Linsner" wrote: > These are all PSAP policy decisions. Just as it's a PSAP policy decision to > support the suggested mechanism in the draft. Existence of the document > describing the mechanism doesn't force PSAP policy. > > I personally would like to see some PSAPs and/or PS jurisdictions line up > behind the draft before it proceeds, but I don't see any harm in it going > forward. > > Of course, I'm dreaming about this special place where a PSAP actually wants > to enable communication with all their customers and not force them to be a > member of a special club. > > [non-chair hat on] > > -Marc- > > > On 10/29/09 2:35 PM, "Brian Rosen" wrote: > >> Thank you. That is what I meant, and you said it better than I was going >> to. >> >> We may also have some transitive relationships: that is, if there is a >> "local" PSAP that trusts that they have done so, other PSAPs may trust that >> they have done so. >> >> Brian >> >> On 10/29/09 11:48 AM, "DRAGE, Keith (Keith)" >> wrote: >> >>> I suspect that what Brian is saying is that anyone can be a service provider >>> (or whatever else you want to call it) in this case provided that: >>> >>> 1) they make that agreement with the PSAP providers they route calls >>> to; >>> >>> 2) they authenticate the calls requests to a level of security that >>> meets >>> the PSAPs (and any legal) requirements; >>> >>> 3) the PSAP trusts that they have done so. >>> >>> While this would normally be what we would understand as public >>> telecommuncation operators, it doesn't mean they have to be. >>> >>> regards >>> >>> Keith >>> >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>>> On Behalf Of Marc Linsner >>>> Sent: Thursday, October 29, 2009 12:32 PM >>>> To: Brian Rosen >>>> Cc: ecrit@ietf.org >>>> Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>> considered >>>> >>>> Brian, >>>> >>>> Please define what you consider to be a service provider. >>>> >>>> Is Skype a service? >>>> Is Jabber a service? >>>> Is Google Voice a service? >>>> Is mydomain.com hosted on a commercial site a service? >>>> Is mydomain.com hosted on a home server a service? >>>> Is myEnterpriseVoIP.com a service? >>>> >>>> So, what you are saying that if I can make calls via all of >>>> the above, it's OK for all of the above to contact an ESRP? >>>> >>>> Are you requiring that I have a full-time proxy on-line for >>>> mydomain.com or can I simply run a transient UA and dynamic DNS? >>>> >>>> -Marc- >>>> >>>> >>>> >>>> On 10/28/09 11:17 PM, "Brian Rosen" wrote: >>>> >>>>> I'm not worried about security by obscurity. I don't want >>>> phones (or >>>>> other >>>>> devices) built to call directly. >>>>> >>>>> -phonebcp says "send the call on your normal outbound call path". >>>>> That's what I want it to say, and I don't want it to say "send it >>>>> direct, bypass your service provider. >>>>> >>>>> I'm not stopping attack, I am stopping abuse. >>>>> >>>>> I don't want devices that are not subscribed to services to >>>> be able to >>>>> make emergency calls (that is, if they can't make "normal" >>>> calls, they >>>>> should not be able to make emergency calls). >>>>> >>>>> Brian >>>>> >>>>> >>>>> On 10/28/09 6:51 PM, "Marc Linsner" wrote: >>>>> >>>>>> Brian, >>>>>> >>>>>> What I hear you saying: 'if we don't document how to spoof a PSAP, >>>>>> then nobody will figure it out.' Isn't that a little >>>> short sighted? >>>>>> >>>>>> Joey@miscreant.org will figure out how to establish a SIP session >>>>>> with any PSAP in the world within 10 minutes of that PSAP being >>>>>> accessible via the Internet, regardless of documentation. >>>>>> >>>>>> I believe there's more harm created in not documenting this for >>>>>> John.Q.Public@ordinary_citizen.com. >>>>>> >>>>>> Granted, nobody here is looking to cause harm to a PSAP. But >>>>>> Joey@miscreant.org can certainly expend public safety resources by >>>>>> reporting a bomb threat to a local school. Should we require that >>>>>> all SIP calls to the local school come from a trusted SP? >>>> Where does it end? >>>>>> >>>>>> This isn't the way to deal with spam. >>>>>> >>>>>> -Marc- >>>>>> >>>>>> >>>>>> >>>>>> On 10/27/09 11:00 AM, "Brian Rosen" wrote: >>>>>> >>>>>>> The first goal is to prevent bad calls. >>>>>>> >>>>>>> The second goal is to indentify the source of the bad calls. >>>>>>> >>>>>>> I'm starting with the first goal. I don't want you to be able to >>>>>>> take a device out of a box, plug it into a network, and have the >>>>>>> only call you can make be an emergency call. I want the >>>> device to >>>>>>> actually "work" (as in be able to place calls to all the entities >>>>>>> that it was intended to) first, and then be able to place >>>> emergency calls. >>>>>>> >>>>>>> Please spend some time in a PSAP while a kid with a >>>> simless phone has "fun" >>>>>>> with it. Imagine how much fun the test mechanism is as >>>> opposed to >>>>>>> placing real calls. >>>>>>> >>>>>>> If we somehow get a bad call, we need to send the cops. >>>> That means >>>>>>> we need an identity (and a location). >>>>>>> >>>>>>> I think a good cert could be the basis of a good identity, if we >>>>>>> could get one. I don't see how we do that. >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>> >>>>>>> On 10/27/09 10:39 AM, "Richard Barnes" wrote: >>>>>>> >>>>>>>> Brian, >>>>>>>> >>>>>>>> Is the security goal here more access control (i.e., controlling >>>>>>>> who can send calls to a PSAP) or attribution/identification for >>>>>>>> post-hoc action. >>>>>>>> >>>>>>>> If it's the latter, then ISTM that the problem can largely be >>>>>>>> reduced to having a certificate infrastructure that binds >>>>>>>> authenticated identities to real-world entities. The >>>> "extended validation" >>>>>>>> certificates that current commercial CAs issue seem to largely >>>>>>>> satisfy this requirement. >>>>>>>> >>>>>>>> --Richard >>>>>>>> >>>>>>>> >>>>>>>> On Oct 27, 2009, at 4:31 PM, Brian Rosen wrote: >>>>>>>> >>>>>>>>> Of course not all VSPs will have trust relationships with all >>>>>>>>> PSAPs. One can hope that long term, we can evolve to >>>> transitive >>>>>>>>> trust relationships that work pretty well cross border. >>>>>>>>> >>>>>>>>> The emergency guys are actually terrified of private/individual >>>>>>>>> domains sending them calls, and we're telling them we >>>> expect that >>>>>>>>> to be possible, but rare, and we're giving them mechanisms that >>>>>>>>> will effectively allow them to turn off calls >>>> selectively, based >>>>>>>>> on factors including what domain the call comes from. >>>> They expect >>>>>>>>> that such calls will be one of the loopholes where they get >>>>>>>>> equivalents to sim-less calls, which drive them nuts. >>>> They don't >>>>>>>>> want ANY calls that don't come from service providers, although >>>>>>>>> they seem to be okay with the notion that the SP may not have >>>>>>>>> great identity (AOL being a poster child). So, while >>>> indeed they >>>>>>>>> understand, and have concerns about having to take calls from >>>>>>>>> Sierra Leone VoIP services Pty, they would much rather >>>> have a call >>>>>>>>> that went through them then a call that went through no service >>>>>>>>> provider at all. >>>>>>>>> >>>>>>>>> I'm not trying to make calls direct from devices or private >>>>>>>>> domains impossible, but I think the notion that we're promoting >>>>>>>>> them is a very bad idea until we have effective mechanisms to >>>>>>>>> prevent abuse. >>>>>>>>> >>>>>>>>> Brian >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/27/09 9:02 AM, "Marc Linsner" wrote: >>>>>>>>> >>>>>>>>>> Brian, >>>>>>>>>> >>>>>>>>>> I'm a little confused. I don't remember you objecting to >>>>>>>>>> requirement RE1 from RFC5012 and I remember your use >>>> case about a >>>>>>>>>> Sierra Leone VSP. >>>>>>>>>> >>>>>>>>>> Are you implying that *all* VSPs will have a trust >>>> relationships >>>>>>>>>> with *all* PSAPs? >>>>>>>>>> >>>>>>>>>> What is the difference between a call coming from a private/ >>>>>>>>>> individual domain (as in not a commercial VSP) and a >>>> VSP on the >>>>>>>>>> other side of the world (outside the jurisdiction)? >>>>>>>>>> >>>>>>>>>> I'm trying to figure out whether you're objecting to anonymous >>>>>>>>>> calls to the PSAP or the mechanisms proposed in this draft? >>>>>>>>>> >>>>>>>>>> [Don't take this as my endorsement of the draft, as >>>> I'm not sure >>>>>>>>>> I agree with UAs registering with the ESRP.] >>>>>>>>>> >>>>>>>>>> -Marc- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 10/26/09 8:59 PM, "Brian Rosen" wrote: >>>>>>>>>> >>>>>>>>>>> First of all, I put it on the wrong email list, sorry >>>> about that. >>>>>>>>>>> >>>>>>>>>>> Then, we have carefully arranged it so that there is >>>> no identity >>>>>>>>>>> coming from the access network provider, and because the >>>>>>>>>>> location is coming from that provider, we really >>>> don't want to. >>>>>>>>>>> But even if we did, we would need a really good >>>> identifier, and >>>>>>>>>>> there isn't one. >>>>>>>>>>> >>>>>>>>>>> The problem we have with -direct is anonymous callers, and if >>>>>>>>>>> they have any option, they would also be >>>> location-less. Until >>>>>>>>>>> and unless we get rid of anonymity, we can't >>>> encourage service >>>>>>>>>>> provider-less calls. The draft does not make any >>>> provision to >>>>>>>>>>> provide any kind of identity. Many networks (think free wifi >>>>>>>>>>> for example) would make providing good identity difficult. >>>>>>>>>>> >>>>>>>>>>> The fact is that there is a SERVICE provider in >>>> nearly all of the >>>>>>>>>>> communications systems. The SERVICE provider is in >>>> a position to >>>>>>>>>>> assist >>>>>>>>>>> the emergency calling system when it needs more information. >>>>>>>>>>> That's what a >>>>>>>>>>> good SERVICE provider does. Cutting them out is not a great >>>>>>>>>>> idea. Most of the attempts to provide real time >>>> communications >>>>>>>>>>> between people have evolved to using service providers, even >>>>>>>>>>> when there were alternatives. File transfer via >>>> something like >>>>>>>>>>> Torrent is a counterexample (which isn't real time), but even >>>>>>>>>>> there, you end up with service providers like The Pirate Bay >>>>>>>>>>> (R.I.P) to provide introduction services. I don't >>>> think we're >>>>>>>>>>> going to see changes that eliminate service providers, and in >>>>>>>>>>> this case, they provide value to the emergency >>>> calling systems. >>>>>>>>>>> All of the emergency professionals I know have issues with >>>>>>>>>>> service providers, but they would react with horror if you >>>>>>>>>>> suggested cutting them out. Ask them, please. >>>>>>>>>>> >>>>>>>>>>> So, I claim you have a solution in search of a >>>> problem. We have >>>>>>>>>>> solved the "calling network isn't the access network" problem >>>>>>>>>>> already. Service providers ARE in the path now, in >>>> nearly every >>>>>>>>>>> case (in fact a counter example escapes me, although there >>>>>>>>>>> probably are some). There is no movement I can detect which >>>>>>>>>>> would change that any time soon; quite the opposite. >>>> We have a >>>>>>>>>>> known killer problem without some kind of subscription to a >>>>>>>>>>> service that provides a good identity, for which you >>>> provide no >>>>>>>>>>> answers. >>>>>>>>>>> We have >>>>>>>>>>> experience with the killer problem: sim-less calling was >>>>>>>>>>> supposed to provide a way to make an emergency call >>>> in exactly >>>>>>>>>>> the kinds of circumstances you are describing. Our >>>> real world >>>>>>>>>>> experience is that you create a huge problem that diverts >>>>>>>>>>> resources from helping people to chasing scammers and >>>>>>>>>>> flea-market sellers. >>>>>>>>>>> >>>>>>>>>>> Nothing is perfect: you can get a AIM screen name >>>> without a very >>>>>>>>>>> good identity for example. However, the notion that >>>> we're going >>>>>>>>>>> to provide direct access without a service provider >>>>>>>>>>> deliberately, especially without really good identity >>>> from the >>>>>>>>>>> access network is, in my opinion not only a no, it's >>>> a heck no. >>>>>>>>>>> I'll line up as many emergency service professionals as you >>>>>>>>>>> would like to tell you this is a harmful idea. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 10/26/09 7:56 PM, "Dawson, Martin" >>>> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> I am glad this has come up. It's a debate that has >>>> to happen if >>>>>>>>>>>> we are to move beyond a long standing legacy misconception. >>>>>>>>>>>> >>>>>>>>>>>> In the circuit service world - whether it was POTS >>>> or mobile, >>>>>>>>>>>> the access network had full responsibility for >>>> delivering the >>>>>>>>>>>> emergency call. In that world, routing an emergency >>>> call meant >>>>>>>>>>>> getting a circuit established to the correct call center. In >>>>>>>>>>>> most parts of the world, this was done using the >>>> regional part >>>>>>>>>>>> of the PSTN to switch the circuit to a call center >>>> on the PSTN. >>>>>>>>>>>> In some jurisdictions, such as the US, it was done directly >>>>>>>>>>>> from the local exchange carrier to the call center. >>>> Either way, >>>>>>>>>>>> there was no third party involved. >>>>>>>>>>>> >>>>>>>>>>>> Now we have the Internet. We still have public >>>> access network >>>>>>>>>>>> providers. >>>>>>>>>>>> They >>>>>>>>>>>> switch packets onto the Internet for their subscribers. They >>>>>>>>>>>> can similarly ensure that packets reach the local emergency >>>>>>>>>>>> call centers. >>>>>>>>>>>> >>>>>>>>>>>> The fact is that there was no equivalent of a VSP in the >>>>>>>>>>>> traditional environment. VoIP is a presence service, >>>> and it had >>>>>>>>>>>> no common equivalent in the PSTN world. It could >>>> have, but the >>>>>>>>>>>> narrowband state of technology and the common market >>>> use cases >>>>>>>>>>>> didn't support its development. By the time ISDN >>>> arrived, the >>>>>>>>>>>> PSTN had already slipped into its palliative stage without >>>>>>>>>>>> realizing it. >>>>>>>>>>>> >>>>>>>>>>>> It's an entrenched misconception that because the circuit >>>>>>>>>>>> service provided by exchange carriers was most commonly used >>>>>>>>>>>> for "voice" (but, it should be noted, also for fax, >>>> telex, tty, >>>>>>>>>>>> security system monitoring and, even, IP data) that VSPs are >>>>>>>>>>>> somehow equivalent to exchange carriers. They are not. >>>>>>>>>>>> >>>>>>>>>>>> Indeed, involving VSPs in emergency calls is the Internet >>>>>>>>>>>> equivalent of involving long distance providers in POTS >>>>>>>>>>>> emergency calls. They are neither necessary nor particularly >>>>>>>>>>>> helpful; they can't be guaranteed to be within the emergency >>>>>>>>>>>> jurisdiction; depending on them actually diminishes the >>>>>>>>>>>> efficacy of emergency service access. It does not help the >>>>>>>>>>>> caller, the emergency service, nor the third party >>>> to insist on >>>>>>>>>>>> the third party's involvement. >>>>>>>>>>>> >>>>>>>>>>>> It can't be helped if you have over sold the benefits of VSP >>>>>>>>>>>> involvement to yourself and others Brian. It is time >>>> to have a >>>>>>>>>>>> reasoned debate. >>>>>>>>>>>> From my >>>>>>>>>>>> perspective, the argument that there is no "subscription" >>>>>>>>>>>> involved is >>>>>>>>>>>> patently >>>>>>>>>>>> false. There has to be a subscription of some description in >>>>>>>>>>>> order to get to the Internet. Yes, there is free public >>>>>>>>>>>> Internet access (just as there are free courtesy >>>> phones on the >>>>>>>>>>>> PSTN and free access to emergency services from pay >>>> phones. All >>>>>>>>>>>> these services are still connected to the public Internet >>>>>>>>>>>> infrastructure and they all represent an "operator" >>>> with some >>>>>>>>>>>> level of information about the caller. >>>>>>>>>>>> >>>>>>>>>>>> With the over-emphasis on VSPs, what is missing from >>>> the ECRIT >>>>>>>>>>>> and i3 models is the direct interface for querying >>>> the access >>>>>>>>>>>> network for subscriber data (should it prove >>>> necessary). These >>>>>>>>>>>> models need to take the long view of how emergency >>>> calling is >>>>>>>>>>>> done in the Internet age; they should not be protracting an >>>>>>>>>>>> unnecessary reliance on VSPs. >>>>>>>>>>>> >>>>>>>>>>>> I have deleted the premature and prejudicial text from the >>>>>>>>>>>> subject heading. >>>>>>>>>>>> And I'll leave this on ECRIT as the most appropriate WG. >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> Martin >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: ecrit-bounces@ietf.org >>>> [mailto:ecrit-bounces@ietf.org] On >>>>>>>>>>>> Behalf Of Hannes Tschofenig >>>>>>>>>>>> Sent: Tuesday, 27 October 2009 8:23 AM >>>>>>>>>>>> To: ecrit@ietf.org >>>>>>>>>>>> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>>>>>>>>>> considered harmful, at least given our current experiences >>>>>>>>>>>> >>>>>>>>>>>> FYI: feedback from Brian regarding a recent ECRIT >>>> contribution. >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: geopriv-bounces@ietf.org >>>>>>>>>>>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian >>>>>>>>>>>> Sent: 26 October, 2009 23:10 >>>>>>>>>>>> To: geopriv@ietf.org >>>>>>>>>>>> Subject: [Geopriv] Winterbottom-ecrit-direct considered >>>>>>>>>>>> harmful, at least given our current experiences >>>>>>>>>>>> >>>>>>>>>>>> The notion behind -direct is to not use a service >>>> provider to >>>>>>>>>>>> place an emergency call. Instead, the device >>>> registers with >>>>>>>>>>>> an Emergency Services Routing Proxy immediately before the >>>>>>>>>>>> call and the call is routed directly from the >>>> device to the ESRP. >>>>>>>>>>>> >>>>>>>>>>>> At least at the moment, this is an exceedingly bad idea. >>>>>>>>>>>> >>>>>>>>>>>> Emergency calling authorities like service providers, a lot. >>>>>>>>>>>> They like them because they can hold them >>>> accountable, and the >>>>>>>>>>>> service providers don't like theft of service, which is >>>>>>>>>>>> something the emergency call guys have an analog to. >>>>>>>>>>>> >>>>>>>>>>>> The facts are that where unaccountable access to emergency >>>>>>>>>>>> calling is allowed, huge numbers of false calls >>>> occur, with no >>>>>>>>>>>> way to stop them, and no way to tell the good ones from the >>>>>>>>>>>> bad ones. This has been seen multiple times where >>>> so called >>>>>>>>>>>> "simless" or "unauthenticated" calls are allowed. >>>>>>>>>>>> >>>>>>>>>>>> -direct precisely duplicates simless calling. The only >>>>>>>>>>>> "registration" is an emergency registration, only emergency >>>>>>>>>>>> calls are allowed, any device can make an emergency call if >>>>>>>>>>>> all it has is a (radio) connection to any network. >>>>>>>>>>>> We can predict, with a very high degree of >>>> certainty, that the >>>>>>>>>>>> feature will be horribly abused: for example to test that a >>>>>>>>>>>> phone without a service plan works. >>>>>>>>>>>> >>>>>>>>>>>> There have been studies which show tens of thousands of bad >>>>>>>>>>>> calls with zero good ones. Nearly every authority I know >>>>>>>>>>>> where the regulator has insisted on simless calling >>>> wants it >>>>>>>>>>>> repealed. There is one counter example I know >>>> where the fact >>>>>>>>>>>> that they got a couple, literally, of good calls among the >>>>>>>>>>>> tens of thousands of bad calls was considered >>>> enough reason to >>>>>>>>>>>> put up with the problem. >>>>>>>>>>>> >>>>>>>>>>>> Service providers give us information that may be useful: a >>>>>>>>>>>> subscriber name and address for example, which is not >>>>>>>>>>>> spoofable by the caller. They have ways to trace callers, >>>>>>>>>>>> especially bad callers. They don't want their >>>> systems abused >>>>>>>>>>>> any more than the emergency calling authorities do. >>>>>>>>>>>> >>>>>>>>>>>> This is a bad idea. A very bad idea. Please stop it. >>>>>>>>>>>> >>>>>>>>>>>> Someday, we may have better ways to prevent abuse. Until we >>>>>>>>>>>> do, service providers are a good thing on an emergency call. >>>>>>>>>>>> We don't want them cut out. >>>>>>>>>>>> >>>>>>>>>>>> Brian >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Geopriv mailing list >>>>>>>>>>>> Geopriv@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 br@brianrosen.net Fri Oct 30 06:17:05 2009 Return-Path: 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 CBFFB3A69D2 for ; Fri, 30 Oct 2009 06:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.444, 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 GTBNyfdm8ynH for ; Fri, 30 Oct 2009 06:17:03 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 122373A68DA for ; Fri, 30 Oct 2009 06:17:03 -0700 (PDT) Received: from [209.173.57.233] (helo=[192.168.130.13]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1N3rLp-0005pd-Fl; Fri, 30 Oct 2009 08:17:09 -0500 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Fri, 30 Oct 2009 09:17:11 -0400 From: Brian Rosen To: "Dawson, Martin" , Marc Linsner Message-ID: Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4AE1y5CAAGs5+wAAX4z4UAAdMnZQACY9dzAAoyaeAAGMbO1g== In-Reply-To: <8B0A9FCBB9832F43971E38010638454F0F251A78@SISPE7MB1.commscope.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Fri, 30 Oct 2009 13:17:05 -0000 Martin Show me a popular two way real time communications system where there is not a middleman providing a service deemed important enough to the users that they don't mind having the service in the path one way or another. If nothing else, the service provider provides a consistent naming mechanism used as identities for establishing communication. That's a service provider, and their aren't any interesting real time two way communications services that don't have a service provider. It may be that some day in the future, we have such entities, but even in things like P2PSIP, there is an enrollment server that issues credentials, and unless you have such a credential, you can't get into the overlay. That's a good enough service provider for me, especially if the callers on such an overlay send calls to emergency services the same way they send any other call. I don't want the ESRP providing an alternate path to make calls. I don't want a device, like a P2PSIP device, having a way to make an emergency call if they can't make a regular call. I claim you have re-invented a problem we explicitly don't want to solve. Put another way, if you are in the circumstance that your solution helps, we don't want your call. That is because we already have a similar situation, and we have serious problems with it. Until and unless you solve that problem, and I think it's pretty unsolvable without a much better identity system, then we can't tolerate your "solution". If there are really good identity systems then I suspect we could use them to avoid the abuse problem. But even so, I think that the emergency call community would still prefer that callers use their normal call path, and that if they can't make "normal" calls, then they can't make emergency calls. I'll ask about that. They like service providers, even though they often have difficulties with them. On 10/29/09 9:45 PM, "Dawson, Martin" wrote: > Hi Brian, > > The significance of "VSPs" is twofold: > > 1. They are a presence service (long term significance) > 2. They provide a bridging service to the circuit service world (temporary > significance) > > You are taking the temporary significance and attempting to hard code it into > a long term role. > > You have been using the term "service" as if it means something quite specific > (it does not). Focussing on the following comment: > > " The IETF writing standards that describe how devices should bypass their > service provider and place emergency calls direct is not a PSAP policy > issue." > > It seems presumptious. You appear to want to prevent the IETF from saying how > an Internet connected device can establish communication with an Internet > connected emergency service. You appear to be saying that there is some > "official service provider" that has to be in the middle for this to happen. > The phrase "bypass their service provider" implies presumption of some formal > role that I don't think exists. > > I travel to the US frequently; if I subscribe to T-Mobile's hotspot network > for example, then I want to be able to make an emergency call from that point > of connection. I don't want to have to previously ensure that I have a > subscription with some or other "service" through whom I have to go if I want > emergency service. I am subscribed to a service - "TMO's hotspot network" - > that's the real subscriber information and point of regulatory control that is > relevant. > > If I have a MiFi device in my car connected to Verizon's 3G service and there > are a variety of devices connected to the Internet through that device, then I > want those devices to be valid options to make an emergency call. If my child > has their PSP connected via it then I want them to be able to call help > without the presumption that there also has to be some sort of VoIP > subscription on that PSP. I am subscribed to a service in this context - > "Verizon's 3G service" - that's the real subscriber information and point of > regulatory control in that use case. > > I don't know where this "edict" comes from that only devices that are normally > used to "make calls" should be able to make emergency calls. Time and > technology makes the whole presumption of what constitutes "making calls" a > pretty fuzzy concept. > > You seem to have invented a problem, then invented a solution which... > ironically... doesn't address the invented problem anyway. Either access to > LoST emergency routing requests and to PSAP URIs is going to be blocked to all > but a privileged set of VoIP providers or there's a hole in the "solution" > that can have a truck driven through it. > > The draft proposed provides excellent guidance for a general and reference > Internet emergency calling client that is consistent with ECRIT. It provides > excellent guidance for jurisdictions that want to provide emergency access > from the Internet, isolated to their jurisdiction, and without presumption of, > potentially foreign, VSP involvement. Personally I think it's what Phone BCP > always could have been but, regardless, it's neither dangerous nor useless as > you seem to be suggesting. > > Cheers, > Martin > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Brian Rosen > Sent: Friday, 30 October 2009 7:36 AM > To: Marc Linsner > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered > > The IETF writing standards that describe how devices should bypass their > service provider and place emergency calls direct is not a PSAP policy > issue. > > I'm satisfied with the current -phonebcp dictum to send calls on the normal > call path. For an "unregistered" device, that will not allow any "calls" > including emergency calls. > > I discussed this draft on the NENA LTD meeting this morning. That may > generate some list discussion from some PSAP people who are subscribed. I > would also like to hear from more PSAP folks on this subject. > > Brian > > > On 10/29/09 3:27 PM, "Marc Linsner" wrote: > >> These are all PSAP policy decisions. Just as it's a PSAP policy decision to >> support the suggested mechanism in the draft. Existence of the document >> describing the mechanism doesn't force PSAP policy. >> >> I personally would like to see some PSAPs and/or PS jurisdictions line up >> behind the draft before it proceeds, but I don't see any harm in it going >> forward. >> >> Of course, I'm dreaming about this special place where a PSAP actually wants >> to enable communication with all their customers and not force them to be a >> member of a special club. >> >> [non-chair hat on] >> >> -Marc- >> >> >> On 10/29/09 2:35 PM, "Brian Rosen" wrote: >> >>> Thank you. That is what I meant, and you said it better than I was going >>> to. >>> >>> We may also have some transitive relationships: that is, if there is a >>> "local" PSAP that trusts that they have done so, other PSAPs may trust that >>> they have done so. >>> >>> Brian >>> >>> On 10/29/09 11:48 AM, "DRAGE, Keith (Keith)" >>> wrote: >>> >>>> I suspect that what Brian is saying is that anyone can be a service >>>> provider >>>> (or whatever else you want to call it) in this case provided that: >>>> >>>> 1) they make that agreement with the PSAP providers they route calls >>>> to; >>>> >>>> 2) they authenticate the calls requests to a level of security that >>>> meets >>>> the PSAPs (and any legal) requirements; >>>> >>>> 3) the PSAP trusts that they have done so. >>>> >>>> While this would normally be what we would understand as public >>>> telecommuncation operators, it doesn't mean they have to be. >>>> >>>> regards >>>> >>>> Keith >>>> >>>>> -----Original Message----- >>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>>>> On Behalf Of Marc Linsner >>>>> Sent: Thursday, October 29, 2009 12:32 PM >>>>> To: Brian Rosen >>>>> Cc: ecrit@ietf.org >>>>> Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>>> considered >>>>> >>>>> Brian, >>>>> >>>>> Please define what you consider to be a service provider. >>>>> >>>>> Is Skype a service? >>>>> Is Jabber a service? >>>>> Is Google Voice a service? >>>>> Is mydomain.com hosted on a commercial site a service? >>>>> Is mydomain.com hosted on a home server a service? >>>>> Is myEnterpriseVoIP.com a service? >>>>> >>>>> So, what you are saying that if I can make calls via all of >>>>> the above, it's OK for all of the above to contact an ESRP? >>>>> >>>>> Are you requiring that I have a full-time proxy on-line for >>>>> mydomain.com or can I simply run a transient UA and dynamic DNS? >>>>> >>>>> -Marc- >>>>> >>>>> >>>>> >>>>> On 10/28/09 11:17 PM, "Brian Rosen" wrote: >>>>> >>>>>> I'm not worried about security by obscurity. I don't want >>>>> phones (or >>>>>> other >>>>>> devices) built to call directly. >>>>>> >>>>>> -phonebcp says "send the call on your normal outbound call path". >>>>>> That's what I want it to say, and I don't want it to say "send it >>>>>> direct, bypass your service provider. >>>>>> >>>>>> I'm not stopping attack, I am stopping abuse. >>>>>> >>>>>> I don't want devices that are not subscribed to services to >>>>> be able to >>>>>> make emergency calls (that is, if they can't make "normal" >>>>> calls, they >>>>>> should not be able to make emergency calls). >>>>>> >>>>>> Brian >>>>>> >>>>>> >>>>>> On 10/28/09 6:51 PM, "Marc Linsner" wrote: >>>>>> >>>>>>> Brian, >>>>>>> >>>>>>> What I hear you saying: 'if we don't document how to spoof a PSAP, >>>>>>> then nobody will figure it out.' Isn't that a little >>>>> short sighted? >>>>>>> >>>>>>> Joey@miscreant.org will figure out how to establish a SIP session >>>>>>> with any PSAP in the world within 10 minutes of that PSAP being >>>>>>> accessible via the Internet, regardless of documentation. >>>>>>> >>>>>>> I believe there's more harm created in not documenting this for >>>>>>> John.Q.Public@ordinary_citizen.com. >>>>>>> >>>>>>> Granted, nobody here is looking to cause harm to a PSAP. But >>>>>>> Joey@miscreant.org can certainly expend public safety resources by >>>>>>> reporting a bomb threat to a local school. Should we require that >>>>>>> all SIP calls to the local school come from a trusted SP? >>>>> Where does it end? >>>>>>> >>>>>>> This isn't the way to deal with spam. >>>>>>> >>>>>>> -Marc- >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 10/27/09 11:00 AM, "Brian Rosen" wrote: >>>>>>> >>>>>>>> The first goal is to prevent bad calls. >>>>>>>> >>>>>>>> The second goal is to indentify the source of the bad calls. >>>>>>>> >>>>>>>> I'm starting with the first goal. I don't want you to be able to >>>>>>>> take a device out of a box, plug it into a network, and have the >>>>>>>> only call you can make be an emergency call. I want the >>>>> device to >>>>>>>> actually "work" (as in be able to place calls to all the entities >>>>>>>> that it was intended to) first, and then be able to place >>>>> emergency calls. >>>>>>>> >>>>>>>> Please spend some time in a PSAP while a kid with a >>>>> simless phone has "fun" >>>>>>>> with it. Imagine how much fun the test mechanism is as >>>>> opposed to >>>>>>>> placing real calls. >>>>>>>> >>>>>>>> If we somehow get a bad call, we need to send the cops. >>>>> That means >>>>>>>> we need an identity (and a location). >>>>>>>> >>>>>>>> I think a good cert could be the basis of a good identity, if we >>>>>>>> could get one. I don't see how we do that. >>>>>>>> >>>>>>>> Brian >>>>>>>> >>>>>>>> >>>>>>>> On 10/27/09 10:39 AM, "Richard Barnes" wrote: >>>>>>>> >>>>>>>>> Brian, >>>>>>>>> >>>>>>>>> Is the security goal here more access control (i.e., controlling >>>>>>>>> who can send calls to a PSAP) or attribution/identification for >>>>>>>>> post-hoc action. >>>>>>>>> >>>>>>>>> If it's the latter, then ISTM that the problem can largely be >>>>>>>>> reduced to having a certificate infrastructure that binds >>>>>>>>> authenticated identities to real-world entities. The >>>>> "extended validation" >>>>>>>>> certificates that current commercial CAs issue seem to largely >>>>>>>>> satisfy this requirement. >>>>>>>>> >>>>>>>>> --Richard >>>>>>>>> >>>>>>>>> >>>>>>>>> On Oct 27, 2009, at 4:31 PM, Brian Rosen wrote: >>>>>>>>> >>>>>>>>>> Of course not all VSPs will have trust relationships with all >>>>>>>>>> PSAPs. One can hope that long term, we can evolve to >>>>> transitive >>>>>>>>>> trust relationships that work pretty well cross border. >>>>>>>>>> >>>>>>>>>> The emergency guys are actually terrified of private/individual >>>>>>>>>> domains sending them calls, and we're telling them we >>>>> expect that >>>>>>>>>> to be possible, but rare, and we're giving them mechanisms that >>>>>>>>>> will effectively allow them to turn off calls >>>>> selectively, based >>>>>>>>>> on factors including what domain the call comes from. >>>>> They expect >>>>>>>>>> that such calls will be one of the loopholes where they get >>>>>>>>>> equivalents to sim-less calls, which drive them nuts. >>>>> They don't >>>>>>>>>> want ANY calls that don't come from service providers, although >>>>>>>>>> they seem to be okay with the notion that the SP may not have >>>>>>>>>> great identity (AOL being a poster child). So, while >>>>> indeed they >>>>>>>>>> understand, and have concerns about having to take calls from >>>>>>>>>> Sierra Leone VoIP services Pty, they would much rather >>>>> have a call >>>>>>>>>> that went through them then a call that went through no service >>>>>>>>>> provider at all. >>>>>>>>>> >>>>>>>>>> I'm not trying to make calls direct from devices or private >>>>>>>>>> domains impossible, but I think the notion that we're promoting >>>>>>>>>> them is a very bad idea until we have effective mechanisms to >>>>>>>>>> prevent abuse. >>>>>>>>>> >>>>>>>>>> Brian >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 10/27/09 9:02 AM, "Marc Linsner" wrote: >>>>>>>>>> >>>>>>>>>>> Brian, >>>>>>>>>>> >>>>>>>>>>> I'm a little confused. I don't remember you objecting to >>>>>>>>>>> requirement RE1 from RFC5012 and I remember your use >>>>> case about a >>>>>>>>>>> Sierra Leone VSP. >>>>>>>>>>> >>>>>>>>>>> Are you implying that *all* VSPs will have a trust >>>>> relationships >>>>>>>>>>> with *all* PSAPs? >>>>>>>>>>> >>>>>>>>>>> What is the difference between a call coming from a private/ >>>>>>>>>>> individual domain (as in not a commercial VSP) and a >>>>> VSP on the >>>>>>>>>>> other side of the world (outside the jurisdiction)? >>>>>>>>>>> >>>>>>>>>>> I'm trying to figure out whether you're objecting to anonymous >>>>>>>>>>> calls to the PSAP or the mechanisms proposed in this draft? >>>>>>>>>>> >>>>>>>>>>> [Don't take this as my endorsement of the draft, as >>>>> I'm not sure >>>>>>>>>>> I agree with UAs registering with the ESRP.] >>>>>>>>>>> >>>>>>>>>>> -Marc- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 10/26/09 8:59 PM, "Brian Rosen" wrote: >>>>>>>>>>> >>>>>>>>>>>> First of all, I put it on the wrong email list, sorry >>>>> about that. >>>>>>>>>>>> >>>>>>>>>>>> Then, we have carefully arranged it so that there is >>>>> no identity >>>>>>>>>>>> coming from the access network provider, and because the >>>>>>>>>>>> location is coming from that provider, we really >>>>> don't want to. >>>>>>>>>>>> But even if we did, we would need a really good >>>>> identifier, and >>>>>>>>>>>> there isn't one. >>>>>>>>>>>> >>>>>>>>>>>> The problem we have with -direct is anonymous callers, and if >>>>>>>>>>>> they have any option, they would also be >>>>> location-less. Until >>>>>>>>>>>> and unless we get rid of anonymity, we can't >>>>> encourage service >>>>>>>>>>>> provider-less calls. The draft does not make any >>>>> provision to >>>>>>>>>>>> provide any kind of identity. Many networks (think free wifi >>>>>>>>>>>> for example) would make providing good identity difficult. >>>>>>>>>>>> >>>>>>>>>>>> The fact is that there is a SERVICE provider in >>>>> nearly all of the >>>>>>>>>>>> communications systems. The SERVICE provider is in >>>>> a position to >>>>>>>>>>>> assist >>>>>>>>>>>> the emergency calling system when it needs more information. >>>>>>>>>>>> That's what a >>>>>>>>>>>> good SERVICE provider does. Cutting them out is not a great >>>>>>>>>>>> idea. Most of the attempts to provide real time >>>>> communications >>>>>>>>>>>> between people have evolved to using service providers, even >>>>>>>>>>>> when there were alternatives. File transfer via >>>>> something like >>>>>>>>>>>> Torrent is a counterexample (which isn't real time), but even >>>>>>>>>>>> there, you end up with service providers like The Pirate Bay >>>>>>>>>>>> (R.I.P) to provide introduction services. I don't >>>>> think we're >>>>>>>>>>>> going to see changes that eliminate service providers, and in >>>>>>>>>>>> this case, they provide value to the emergency >>>>> calling systems. >>>>>>>>>>>> All of the emergency professionals I know have issues with >>>>>>>>>>>> service providers, but they would react with horror if you >>>>>>>>>>>> suggested cutting them out. Ask them, please. >>>>>>>>>>>> >>>>>>>>>>>> So, I claim you have a solution in search of a >>>>> problem. We have >>>>>>>>>>>> solved the "calling network isn't the access network" problem >>>>>>>>>>>> already. Service providers ARE in the path now, in >>>>> nearly every >>>>>>>>>>>> case (in fact a counter example escapes me, although there >>>>>>>>>>>> probably are some). There is no movement I can detect which >>>>>>>>>>>> would change that any time soon; quite the opposite. >>>>> We have a >>>>>>>>>>>> known killer problem without some kind of subscription to a >>>>>>>>>>>> service that provides a good identity, for which you >>>>> provide no >>>>>>>>>>>> answers. >>>>>>>>>>>> We have >>>>>>>>>>>> experience with the killer problem: sim-less calling was >>>>>>>>>>>> supposed to provide a way to make an emergency call >>>>> in exactly >>>>>>>>>>>> the kinds of circumstances you are describing. Our >>>>> real world >>>>>>>>>>>> experience is that you create a huge problem that diverts >>>>>>>>>>>> resources from helping people to chasing scammers and >>>>>>>>>>>> flea-market sellers. >>>>>>>>>>>> >>>>>>>>>>>> Nothing is perfect: you can get a AIM screen name >>>>> without a very >>>>>>>>>>>> good identity for example. However, the notion that >>>>> we're going >>>>>>>>>>>> to provide direct access without a service provider >>>>>>>>>>>> deliberately, especially without really good identity >>>>> from the >>>>>>>>>>>> access network is, in my opinion not only a no, it's >>>>> a heck no. >>>>>>>>>>>> I'll line up as many emergency service professionals as you >>>>>>>>>>>> would like to tell you this is a harmful idea. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/26/09 7:56 PM, "Dawson, Martin" >>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> I am glad this has come up. It's a debate that has >>>>> to happen if >>>>>>>>>>>> we are to move beyond a long standing legacy misconception. >>>>>>>>>>>> >>>>>>>>>>>> In the circuit service world - whether it was POTS >>>>> or mobile, >>>>>>>>>>>> the access network had full responsibility for >>>>> delivering the >>>>>>>>>>>> emergency call. In that world, routing an emergency >>>>> call meant >>>>>>>>>>>> getting a circuit established to the correct call center. In >>>>>>>>>>>> most parts of the world, this was done using the >>>>> regional part >>>>>>>>>>>> of the PSTN to switch the circuit to a call center >>>>> on the PSTN. >>>>>>>>>>>> In some jurisdictions, such as the US, it was done directly >>>>>>>>>>>> from the local exchange carrier to the call center. >>>>> Either way, >>>>>>>>>>>> there was no third party involved. >>>>>>>>>>>> >>>>>>>>>>>> Now we have the Internet. We still have public >>>>> access network >>>>>>>>>>>> providers. >>>>>>>>>>>> They >>>>>>>>>>>> switch packets onto the Internet for their subscribers. They >>>>>>>>>>>> can similarly ensure that packets reach the local emergency >>>>>>>>>>>> call centers. >>>>>>>>>>>> >>>>>>>>>>>> The fact is that there was no equivalent of a VSP in the >>>>>>>>>>>> traditional environment. VoIP is a presence service, >>>>> and it had >>>>>>>>>>>> no common equivalent in the PSTN world. It could >>>>> have, but the >>>>>>>>>>>> narrowband state of technology and the common market >>>>> use cases >>>>>>>>>>>> didn't support its development. By the time ISDN >>>>> arrived, the >>>>>>>>>>>> PSTN had already slipped into its palliative stage without >>>>>>>>>>>> realizing it. >>>>>>>>>>>> >>>>>>>>>>>> It's an entrenched misconception that because the circuit >>>>>>>>>>>> service provided by exchange carriers was most commonly used >>>>>>>>>>>> for "voice" (but, it should be noted, also for fax, >>>>> telex, tty, >>>>>>>>>>>> security system monitoring and, even, IP data) that VSPs are >>>>>>>>>>>> somehow equivalent to exchange carriers. They are not. >>>>>>>>>>>> >>>>>>>>>>>> Indeed, involving VSPs in emergency calls is the Internet >>>>>>>>>>>> equivalent of involving long distance providers in POTS >>>>>>>>>>>> emergency calls. They are neither necessary nor particularly >>>>>>>>>>>> helpful; they can't be guaranteed to be within the emergency >>>>>>>>>>>> jurisdiction; depending on them actually diminishes the >>>>>>>>>>>> efficacy of emergency service access. It does not help the >>>>>>>>>>>> caller, the emergency service, nor the third party >>>>> to insist on >>>>>>>>>>>> the third party's involvement. >>>>>>>>>>>> >>>>>>>>>>>> It can't be helped if you have over sold the benefits of VSP >>>>>>>>>>>> involvement to yourself and others Brian. It is time >>>>> to have a >>>>>>>>>>>> reasoned debate. >>>>>>>>>>>> From my >>>>>>>>>>>> perspective, the argument that there is no "subscription" >>>>>>>>>>>> involved is >>>>>>>>>>>> patently >>>>>>>>>>>> false. There has to be a subscription of some description in >>>>>>>>>>>> order to get to the Internet. Yes, there is free public >>>>>>>>>>>> Internet access (just as there are free courtesy >>>>> phones on the >>>>>>>>>>>> PSTN and free access to emergency services from pay >>>>> phones. All >>>>>>>>>>>> these services are still connected to the public Internet >>>>>>>>>>>> infrastructure and they all represent an "operator" >>>>> with some >>>>>>>>>>>> level of information about the caller. >>>>>>>>>>>> >>>>>>>>>>>> With the over-emphasis on VSPs, what is missing from >>>>> the ECRIT >>>>>>>>>>>> and i3 models is the direct interface for querying >>>>> the access >>>>>>>>>>>> network for subscriber data (should it prove >>>>> necessary). These >>>>>>>>>>>> models need to take the long view of how emergency >>>>> calling is >>>>>>>>>>>> done in the Internet age; they should not be protracting an >>>>>>>>>>>> unnecessary reliance on VSPs. >>>>>>>>>>>> >>>>>>>>>>>> I have deleted the premature and prejudicial text from the >>>>>>>>>>>> subject heading. >>>>>>>>>>>> And I'll leave this on ECRIT as the most appropriate WG. >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> Martin >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: ecrit-bounces@ietf.org >>>>> [mailto:ecrit-bounces@ietf.org] On >>>>>>>>>>>> Behalf Of Hannes Tschofenig >>>>>>>>>>>> Sent: Tuesday, 27 October 2009 8:23 AM >>>>>>>>>>>> To: ecrit@ietf.org >>>>>>>>>>>> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>>>>>>>>>> considered harmful, at least given our current experiences >>>>>>>>>>>> >>>>>>>>>>>> FYI: feedback from Brian regarding a recent ECRIT >>>>> contribution. >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: geopriv-bounces@ietf.org >>>>>>>>>>>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian >>>>>>>>>>>> Sent: 26 October, 2009 23:10 >>>>>>>>>>>> To: geopriv@ietf.org >>>>>>>>>>>> Subject: [Geopriv] Winterbottom-ecrit-direct considered >>>>>>>>>>>> harmful, at least given our current experiences >>>>>>>>>>>> >>>>>>>>>>>> The notion behind -direct is to not use a service >>>>> provider to >>>>>>>>>>>> place an emergency call. Instead, the device >>>>> registers with >>>>>>>>>>>> an Emergency Services Routing Proxy immediately before the >>>>>>>>>>>> call and the call is routed directly from the >>>>> device to the ESRP. >>>>>>>>>>>> >>>>>>>>>>>> At least at the moment, this is an exceedingly bad idea. >>>>>>>>>>>> >>>>>>>>>>>> Emergency calling authorities like service providers, a lot. >>>>>>>>>>>> They like them because they can hold them >>>>> accountable, and the >>>>>>>>>>>> service providers don't like theft of service, which is >>>>>>>>>>>> something the emergency call guys have an analog to. >>>>>>>>>>>> >>>>>>>>>>>> The facts are that where unaccountable access to emergency >>>>>>>>>>>> calling is allowed, huge numbers of false calls >>>>> occur, with no >>>>>>>>>>>> way to stop them, and no way to tell the good ones from the >>>>>>>>>>>> bad ones. This has been seen multiple times where >>>>> so called >>>>>>>>>>>> "simless" or "unauthenticated" calls are allowed. >>>>>>>>>>>> >>>>>>>>>>>> -direct precisely duplicates simless calling. The only >>>>>>>>>>>> "registration" is an emergency registration, only emergency >>>>>>>>>>>> calls are allowed, any device can make an emergency call if >>>>>>>>>>>> all it has is a (radio) connection to any network. >>>>>>>>>>>> We can predict, with a very high degree of >>>>> certainty, that the >>>>>>>>>>>> feature will be horribly abused: for example to test that a >>>>>>>>>>>> phone without a service plan works. >>>>>>>>>>>> >>>>>>>>>>>> There have been studies which show tens of thousands of bad >>>>>>>>>>>> calls with zero good ones. Nearly every authority I know >>>>>>>>>>>> where the regulator has insisted on simless calling >>>>> wants it >>>>>>>>>>>> repealed. There is one counter example I know >>>>> where the fact >>>>>>>>>>>> that they got a couple, literally, of good calls among the >>>>>>>>>>>> tens of thousands of bad calls was considered >>>>> enough reason to >>>>>>>>>>>> put up with the problem. >>>>>>>>>>>> >>>>>>>>>>>> Service providers give us information that may be useful: a >>>>>>>>>>>> subscriber name and address for example, which is not >>>>>>>>>>>> spoofable by the caller. They have ways to trace callers, >>>>>>>>>>>> especially bad callers. They don't want their >>>>> systems abused >>>>>>>>>>>> any more than the emergency calling authorities do. >>>>>>>>>>>> >>>>>>>>>>>> This is a bad idea. A very bad idea. Please stop it. >>>>>>>>>>>> >>>>>>>>>>>> Someday, we may have better ways to prevent abuse. Until we >>>>>>>>>>>> do, service providers are a good thing on an emergency call. >>>>>>>>>>>> We don't want them cut out. >>>>>>>>>>>> >>>>>>>>>>>> Brian >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Geopriv mailing list >>>>>>>>>>>> Geopriv@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 br@brianrosen.net Fri Oct 30 06:47:26 2009 Return-Path: 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 3F02E3A6ABB for ; Fri, 30 Oct 2009 06:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=0.418, 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 RR8T4z8WRhro for ; Fri, 30 Oct 2009 06:47:23 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 5ACA03A6ABA for ; Fri, 30 Oct 2009 06:47:23 -0700 (PDT) Received: from [209.173.57.233] (helo=[192.168.130.13]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1N3rpE-0007bw-QW; Fri, 30 Oct 2009 08:47:33 -0500 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Fri, 30 Oct 2009 09:47:33 -0400 From: Brian Rosen To: Marc Linsner Message-ID: Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4AE1y5CAAGs5+wAAX4z4UAAdMnZQACY9dzAAJ55ZEAIY7Szw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Fri, 30 Oct 2009 13:47:26 -0000 I want it to say MUST NOT use that mechanism :) I don't want alternative ways to make emergency calls. I want what phonebcp already says: send the call on the normal path and a normal identity and callback (which implies using a normal registration). I understand that the local authority can disable the ESRP registration mechanism. If this draft goes forward against my advice, then I will ask that there be text that says if the registration cannot be completed, the device MUST NOT send emergency calls direct to that ESRP, and must use its normal call path for emergency calls. We can't stop calls from entering the emergency services IP network without passing through a service provider. I have no wish to add any mechanism which would attempt to do so. If it would help, I would be happy to beef up language in framework that discusses this problem and what "normal call path" means. I would even be very happy to add a item to phonebcp that says "if you can't make normal calls, you can't make emergency calls", although we might get hung up on defining "normal", because if at some time when you need help the only number that could actually answer your call, sent down the same call path as you would normally send any call, is the emergency service, then we want that call. We frequently use you as an example. If you have a SIP Registrar and proxy server in your home (or boat) and you have a phone that registers with it, and you normally make calls to your family and friends with that setup, then I suspect that there is some service provider helping your proxy server connect to your family and friends. We would prefer your emergency calls go through that service provider. However, if for some reason, your proxy server forwarded an emergency call direct to the ESInet, it will normally go through. Unfortunately for you, if someone decides to attack the emergency call system, and it gets overloaded for some period of time until we can mitigate the attack, we may have to make choices on which calls we answer and which ones we don't. Your call sent through your proxy server to the ESInet direct may get lower priority than the same call sent through the service provider, if we notice that most of the attack calls are coming direct from the Internet, rather than going through a service provider we know about. We're building in explicit attack mitigation strategies like that. It's not unreasonable: if you have 5 sources entering your network, and one of them is the place where all (or most) of the attack is coming from, you shut off that source until you have a better filter. If a whole lot of devices assume the direct path is the preferred path, that would be bad for them. Furthermore, there is additional data sent to the emergency system (in the U.S.) with the call from the service provider. That information may be useful in helping you. The device can actually send the information, but while while we are pretty sure we can get most service providers to give it to us, we are pessimistic most devices will. Devices that have sensors, where the sensor data is useful for emergency calls may very well do it. Medical monitoring devices for example. NENA will be asking the IETF to standardize this soon, so that all service providers anywhere could provide it to all emergency services. It has things like subscriber (as opposed to caller) contact data, class of service information, SP contact data, etc. When things go wrong, the PSAP will often contact the SP and get help. The SP often has tools and mechanisms that CAN help. Brian On 10/29/09 5:46 PM, "Marc Linsner" wrote: > Brian, > > I didn't read anything in the draft that stated devices 'should' use this > mechanism (if it's there, it needs removed). I read it more as a device > 'could' use this mechanism (as in an alternative to other mechanisms). > > Further, since the ESRP is controlled by the PSAP, it certainly would be a > PSAP policy decision whether to support this mechanism. As without the ESRP > support of unknown UA registrations, the mechanism doesn't work. > > BTW, the term 'unregistered' is not in phonebcp. I think your are > stretching the 'normal call path' to include registration with something(?). > I find nothing in phonebcp that disallows 'direct' calls to an ESRP. If I > contact an ESRP from my UA 'directly', as long as the PSAP can call-back > using the Contact header I sent in the invite and my AOR leads back to my > UA, I've satisfied phonebcp. > > What am I missing? > > -Marc- > > > On 10/29/09 4:35 PM, "Brian Rosen" wrote: > >> The IETF writing standards that describe how devices should bypass their >> service provider and place emergency calls direct is not a PSAP policy >> issue. >> >> I'm satisfied with the current -phonebcp dictum to send calls on the normal >> call path. For an "unregistered" device, that will not allow any "calls" >> including emergency calls. >> >> I discussed this draft on the NENA LTD meeting this morning. That may >> generate some list discussion from some PSAP people who are subscribed. I >> would also like to hear from more PSAP folks on this subject. >> >> Brian >> >> >> On 10/29/09 3:27 PM, "Marc Linsner" wrote: >> >>> These are all PSAP policy decisions. Just as it's a PSAP policy decision to >>> support the suggested mechanism in the draft. Existence of the document >>> describing the mechanism doesn't force PSAP policy. >>> >>> I personally would like to see some PSAPs and/or PS jurisdictions line up >>> behind the draft before it proceeds, but I don't see any harm in it going >>> forward. >>> >>> Of course, I'm dreaming about this special place where a PSAP actually wants >>> to enable communication with all their customers and not force them to be a >>> member of a special club. >>> >>> [non-chair hat on] >>> >>> -Marc- >>> >>> >>> On 10/29/09 2:35 PM, "Brian Rosen" wrote: >>> >>>> Thank you. That is what I meant, and you said it better than I was going >>>> to. >>>> >>>> We may also have some transitive relationships: that is, if there is a >>>> "local" PSAP that trusts that they have done so, other PSAPs may trust that >>>> they have done so. >>>> >>>> Brian >>>> >>>> On 10/29/09 11:48 AM, "DRAGE, Keith (Keith)" >>>> wrote: >>>> >>>>> I suspect that what Brian is saying is that anyone can be a service >>>>> provider >>>>> (or whatever else you want to call it) in this case provided that: >>>>> >>>>> 1) they make that agreement with the PSAP providers they route calls >>>>> to; >>>>> >>>>> 2) they authenticate the calls requests to a level of security that >>>>> meets >>>>> the PSAPs (and any legal) requirements; >>>>> >>>>> 3) the PSAP trusts that they have done so. >>>>> >>>>> While this would normally be what we would understand as public >>>>> telecommuncation operators, it doesn't mean they have to be. >>>>> >>>>> regards >>>>> >>>>> Keith >>>>> >>>>>> -----Original Message----- >>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>>>>> On Behalf Of Marc Linsner >>>>>> Sent: Thursday, October 29, 2009 12:32 PM >>>>>> To: Brian Rosen >>>>>> Cc: ecrit@ietf.org >>>>>> Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>>>> considered >>>>>> >>>>>> Brian, >>>>>> >>>>>> Please define what you consider to be a service provider. >>>>>> >>>>>> Is Skype a service? >>>>>> Is Jabber a service? >>>>>> Is Google Voice a service? >>>>>> Is mydomain.com hosted on a commercial site a service? >>>>>> Is mydomain.com hosted on a home server a service? >>>>>> Is myEnterpriseVoIP.com a service? >>>>>> >>>>>> So, what you are saying that if I can make calls via all of >>>>>> the above, it's OK for all of the above to contact an ESRP? >>>>>> >>>>>> Are you requiring that I have a full-time proxy on-line for >>>>>> mydomain.com or can I simply run a transient UA and dynamic DNS? >>>>>> >>>>>> -Marc- >>>>>> >>>>>> >>>>>> >>>>>> On 10/28/09 11:17 PM, "Brian Rosen" wrote: >>>>>> >>>>>>> I'm not worried about security by obscurity. I don't want >>>>>> phones (or >>>>>>> other >>>>>>> devices) built to call directly. >>>>>>> >>>>>>> -phonebcp says "send the call on your normal outbound call path". >>>>>>> That's what I want it to say, and I don't want it to say "send it >>>>>>> direct, bypass your service provider. >>>>>>> >>>>>>> I'm not stopping attack, I am stopping abuse. >>>>>>> >>>>>>> I don't want devices that are not subscribed to services to >>>>>> be able to >>>>>>> make emergency calls (that is, if they can't make "normal" >>>>>> calls, they >>>>>>> should not be able to make emergency calls). >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>> >>>>>>> On 10/28/09 6:51 PM, "Marc Linsner" wrote: >>>>>>> >>>>>>>> Brian, >>>>>>>> >>>>>>>> What I hear you saying: 'if we don't document how to spoof a PSAP, >>>>>>>> then nobody will figure it out.' Isn't that a little >>>>>> short sighted? >>>>>>>> >>>>>>>> Joey@miscreant.org will figure out how to establish a SIP session >>>>>>>> with any PSAP in the world within 10 minutes of that PSAP being >>>>>>>> accessible via the Internet, regardless of documentation. >>>>>>>> >>>>>>>> I believe there's more harm created in not documenting this for >>>>>>>> John.Q.Public@ordinary_citizen.com. >>>>>>>> >>>>>>>> Granted, nobody here is looking to cause harm to a PSAP. But >>>>>>>> Joey@miscreant.org can certainly expend public safety resources by >>>>>>>> reporting a bomb threat to a local school. Should we require that >>>>>>>> all SIP calls to the local school come from a trusted SP? >>>>>> Where does it end? >>>>>>>> >>>>>>>> This isn't the way to deal with spam. >>>>>>>> >>>>>>>> -Marc- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 10/27/09 11:00 AM, "Brian Rosen" wrote: >>>>>>>> >>>>>>>>> The first goal is to prevent bad calls. >>>>>>>>> >>>>>>>>> The second goal is to indentify the source of the bad calls. >>>>>>>>> >>>>>>>>> I'm starting with the first goal. I don't want you to be able to >>>>>>>>> take a device out of a box, plug it into a network, and have the >>>>>>>>> only call you can make be an emergency call. I want the >>>>>> device to >>>>>>>>> actually "work" (as in be able to place calls to all the entities >>>>>>>>> that it was intended to) first, and then be able to place >>>>>> emergency calls. >>>>>>>>> >>>>>>>>> Please spend some time in a PSAP while a kid with a >>>>>> simless phone has "fun" >>>>>>>>> with it. Imagine how much fun the test mechanism is as >>>>>> opposed to >>>>>>>>> placing real calls. >>>>>>>>> >>>>>>>>> If we somehow get a bad call, we need to send the cops. >>>>>> That means >>>>>>>>> we need an identity (and a location). >>>>>>>>> >>>>>>>>> I think a good cert could be the basis of a good identity, if we >>>>>>>>> could get one. I don't see how we do that. >>>>>>>>> >>>>>>>>> Brian >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/27/09 10:39 AM, "Richard Barnes" wrote: >>>>>>>>> >>>>>>>>>> Brian, >>>>>>>>>> >>>>>>>>>> Is the security goal here more access control (i.e., controlling >>>>>>>>>> who can send calls to a PSAP) or attribution/identification for >>>>>>>>>> post-hoc action. >>>>>>>>>> >>>>>>>>>> If it's the latter, then ISTM that the problem can largely be >>>>>>>>>> reduced to having a certificate infrastructure that binds >>>>>>>>>> authenticated identities to real-world entities. The >>>>>> "extended validation" >>>>>>>>>> certificates that current commercial CAs issue seem to largely >>>>>>>>>> satisfy this requirement. >>>>>>>>>> >>>>>>>>>> --Richard >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Oct 27, 2009, at 4:31 PM, Brian Rosen wrote: >>>>>>>>>> >>>>>>>>>>> Of course not all VSPs will have trust relationships with all >>>>>>>>>>> PSAPs. One can hope that long term, we can evolve to >>>>>> transitive >>>>>>>>>>> trust relationships that work pretty well cross border. >>>>>>>>>>> >>>>>>>>>>> The emergency guys are actually terrified of private/individual >>>>>>>>>>> domains sending them calls, and we're telling them we >>>>>> expect that >>>>>>>>>>> to be possible, but rare, and we're giving them mechanisms that >>>>>>>>>>> will effectively allow them to turn off calls >>>>>> selectively, based >>>>>>>>>>> on factors including what domain the call comes from. >>>>>> They expect >>>>>>>>>>> that such calls will be one of the loopholes where they get >>>>>>>>>>> equivalents to sim-less calls, which drive them nuts. >>>>>> They don't >>>>>>>>>>> want ANY calls that don't come from service providers, although >>>>>>>>>>> they seem to be okay with the notion that the SP may not have >>>>>>>>>>> great identity (AOL being a poster child). So, while >>>>>> indeed they >>>>>>>>>>> understand, and have concerns about having to take calls from >>>>>>>>>>> Sierra Leone VoIP services Pty, they would much rather >>>>>> have a call >>>>>>>>>>> that went through them then a call that went through no service >>>>>>>>>>> provider at all. >>>>>>>>>>> >>>>>>>>>>> I'm not trying to make calls direct from devices or private >>>>>>>>>>> domains impossible, but I think the notion that we're promoting >>>>>>>>>>> them is a very bad idea until we have effective mechanisms to >>>>>>>>>>> prevent abuse. >>>>>>>>>>> >>>>>>>>>>> Brian >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 10/27/09 9:02 AM, "Marc Linsner" wrote: >>>>>>>>>>> >>>>>>>>>>>> Brian, >>>>>>>>>>>> >>>>>>>>>>>> I'm a little confused. I don't remember you objecting to >>>>>>>>>>>> requirement RE1 from RFC5012 and I remember your use >>>>>> case about a >>>>>>>>>>>> Sierra Leone VSP. >>>>>>>>>>>> >>>>>>>>>>>> Are you implying that *all* VSPs will have a trust >>>>>> relationships >>>>>>>>>>>> with *all* PSAPs? >>>>>>>>>>>> >>>>>>>>>>>> What is the difference between a call coming from a private/ >>>>>>>>>>>> individual domain (as in not a commercial VSP) and a >>>>>> VSP on the >>>>>>>>>>>> other side of the world (outside the jurisdiction)? >>>>>>>>>>>> >>>>>>>>>>>> I'm trying to figure out whether you're objecting to anonymous >>>>>>>>>>>> calls to the PSAP or the mechanisms proposed in this draft? >>>>>>>>>>>> >>>>>>>>>>>> [Don't take this as my endorsement of the draft, as >>>>>> I'm not sure >>>>>>>>>>>> I agree with UAs registering with the ESRP.] >>>>>>>>>>>> >>>>>>>>>>>> -Marc- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/26/09 8:59 PM, "Brian Rosen" wrote: >>>>>>>>>>>> >>>>>>>>>>>> First of all, I put it on the wrong email list, sorry >>>>>> about that. >>>>>>>>>>>> >>>>>>>>>>>> Then, we have carefully arranged it so that there is >>>>>> no identity >>>>>>>>>>>> coming from the access network provider, and because the >>>>>>>>>>>> location is coming from that provider, we really >>>>>> don't want to. >>>>>>>>>>>> But even if we did, we would need a really good >>>>>> identifier, and >>>>>>>>>>>> there isn't one. >>>>>>>>>>>> >>>>>>>>>>>> The problem we have with -direct is anonymous callers, and if >>>>>>>>>>>> they have any option, they would also be >>>>>> location-less. Until >>>>>>>>>>>> and unless we get rid of anonymity, we can't >>>>>> encourage service >>>>>>>>>>>> provider-less calls. The draft does not make any >>>>>> provision to >>>>>>>>>>>> provide any kind of identity. Many networks (think free wifi >>>>>>>>>>>> for example) would make providing good identity difficult. >>>>>>>>>>>> >>>>>>>>>>>> The fact is that there is a SERVICE provider in >>>>>> nearly all of the >>>>>>>>>>>> communications systems. The SERVICE provider is in >>>>>> a position to >>>>>>>>>>>> assist >>>>>>>>>>>> the emergency calling system when it needs more information. >>>>>>>>>>>> That's what a >>>>>>>>>>>> good SERVICE provider does. Cutting them out is not a great >>>>>>>>>>>> idea. Most of the attempts to provide real time >>>>>> communications >>>>>>>>>>>> between people have evolved to using service providers, even >>>>>>>>>>>> when there were alternatives. File transfer via >>>>>> something like >>>>>>>>>>>> Torrent is a counterexample (which isn't real time), but even >>>>>>>>>>>> there, you end up with service providers like The Pirate Bay >>>>>>>>>>>> (R.I.P) to provide introduction services. I don't >>>>>> think we're >>>>>>>>>>>> going to see changes that eliminate service providers, and in >>>>>>>>>>>> this case, they provide value to the emergency >>>>>> calling systems. >>>>>>>>>>>> All of the emergency professionals I know have issues with >>>>>>>>>>>> service providers, but they would react with horror if you >>>>>>>>>>>> suggested cutting them out. Ask them, please. >>>>>>>>>>>> >>>>>>>>>>>> So, I claim you have a solution in search of a >>>>>> problem. We have >>>>>>>>>>>> solved the "calling network isn't the access network" problem >>>>>>>>>>>> already. Service providers ARE in the path now, in >>>>>> nearly every >>>>>>>>>>>> case (in fact a counter example escapes me, although there >>>>>>>>>>>> probably are some). There is no movement I can detect which >>>>>>>>>>>> would change that any time soon; quite the opposite. >>>>>> We have a >>>>>>>>>>>> known killer problem without some kind of subscription to a >>>>>>>>>>>> service that provides a good identity, for which you >>>>>> provide no >>>>>>>>>>>> answers. >>>>>>>>>>>> We have >>>>>>>>>>>> experience with the killer problem: sim-less calling was >>>>>>>>>>>> supposed to provide a way to make an emergency call >>>>>> in exactly >>>>>>>>>>>> the kinds of circumstances you are describing. Our >>>>>> real world >>>>>>>>>>>> experience is that you create a huge problem that diverts >>>>>>>>>>>> resources from helping people to chasing scammers and >>>>>>>>>>>> flea-market sellers. >>>>>>>>>>>> >>>>>>>>>>>> Nothing is perfect: you can get a AIM screen name >>>>>> without a very >>>>>>>>>>>> good identity for example. However, the notion that >>>>>> we're going >>>>>>>>>>>> to provide direct access without a service provider >>>>>>>>>>>> deliberately, especially without really good identity >>>>>> from the >>>>>>>>>>>> access network is, in my opinion not only a no, it's >>>>>> a heck no. >>>>>>>>>>>> I'll line up as many emergency service professionals as you >>>>>>>>>>>> would like to tell you this is a harmful idea. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/26/09 7:56 PM, "Dawson, Martin" >>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> I am glad this has come up. It's a debate that has >>>>>> to happen if >>>>>>>>>>>> we are to move beyond a long standing legacy misconception. >>>>>>>>>>>> >>>>>>>>>>>> In the circuit service world - whether it was POTS >>>>>> or mobile, >>>>>>>>>>>> the access network had full responsibility for >>>>>> delivering the >>>>>>>>>>>> emergency call. In that world, routing an emergency >>>>>> call meant >>>>>>>>>>>> getting a circuit established to the correct call center. In >>>>>>>>>>>> most parts of the world, this was done using the >>>>>> regional part >>>>>>>>>>>> of the PSTN to switch the circuit to a call center >>>>>> on the PSTN. >>>>>>>>>>>> In some jurisdictions, such as the US, it was done directly >>>>>>>>>>>> from the local exchange carrier to the call center. >>>>>> Either way, >>>>>>>>>>>> there was no third party involved. >>>>>>>>>>>> >>>>>>>>>>>> Now we have the Internet. We still have public >>>>>> access network >>>>>>>>>>>> providers. >>>>>>>>>>>> They >>>>>>>>>>>> switch packets onto the Internet for their subscribers. They >>>>>>>>>>>> can similarly ensure that packets reach the local emergency >>>>>>>>>>>> call centers. >>>>>>>>>>>> >>>>>>>>>>>> The fact is that there was no equivalent of a VSP in the >>>>>>>>>>>> traditional environment. VoIP is a presence service, >>>>>> and it had >>>>>>>>>>>> no common equivalent in the PSTN world. It could >>>>>> have, but the >>>>>>>>>>>> narrowband state of technology and the common market >>>>>> use cases >>>>>>>>>>>> didn't support its development. By the time ISDN >>>>>> arrived, the >>>>>>>>>>>> PSTN had already slipped into its palliative stage without >>>>>>>>>>>> realizing it. >>>>>>>>>>>> >>>>>>>>>>>> It's an entrenched misconception that because the circuit >>>>>>>>>>>> service provided by exchange carriers was most commonly used >>>>>>>>>>>> for "voice" (but, it should be noted, also for fax, >>>>>> telex, tty, >>>>>>>>>>>> security system monitoring and, even, IP data) that VSPs are >>>>>>>>>>>> somehow equivalent to exchange carriers. They are not. >>>>>>>>>>>> >>>>>>>>>>>> Indeed, involving VSPs in emergency calls is the Internet >>>>>>>>>>>> equivalent of involving long distance providers in POTS >>>>>>>>>>>> emergency calls. They are neither necessary nor particularly >>>>>>>>>>>> helpful; they can't be guaranteed to be within the emergency >>>>>>>>>>>> jurisdiction; depending on them actually diminishes the >>>>>>>>>>>> efficacy of emergency service access. It does not help the >>>>>>>>>>>> caller, the emergency service, nor the third party >>>>>> to insist on >>>>>>>>>>>> the third party's involvement. >>>>>>>>>>>> >>>>>>>>>>>> It can't be helped if you have over sold the benefits of VSP >>>>>>>>>>>> involvement to yourself and others Brian. It is time >>>>>> to have a >>>>>>>>>>>> reasoned debate. >>>>>>>>>>>> From my >>>>>>>>>>>> perspective, the argument that there is no "subscription" >>>>>>>>>>>> involved is >>>>>>>>>>>> patently >>>>>>>>>>>> false. There has to be a subscription of some description in >>>>>>>>>>>> order to get to the Internet. Yes, there is free public >>>>>>>>>>>> Internet access (just as there are free courtesy >>>>>> phones on the >>>>>>>>>>>> PSTN and free access to emergency services from pay >>>>>> phones. All >>>>>>>>>>>> these services are still connected to the public Internet >>>>>>>>>>>> infrastructure and they all represent an "operator" >>>>>> with some >>>>>>>>>>>> level of information about the caller. >>>>>>>>>>>> >>>>>>>>>>>> With the over-emphasis on VSPs, what is missing from >>>>>> the ECRIT >>>>>>>>>>>> and i3 models is the direct interface for querying >>>>>> the access >>>>>>>>>>>> network for subscriber data (should it prove >>>>>> necessary). These >>>>>>>>>>>> models need to take the long view of how emergency >>>>>> calling is >>>>>>>>>>>> done in the Internet age; they should not be protracting an >>>>>>>>>>>> unnecessary reliance on VSPs. >>>>>>>>>>>> >>>>>>>>>>>> I have deleted the premature and prejudicial text from the >>>>>>>>>>>> subject heading. >>>>>>>>>>>> And I'll leave this on ECRIT as the most appropriate WG. >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> Martin >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: ecrit-bounces@ietf.org >>>>>> [mailto:ecrit-bounces@ietf.org] On >>>>>>>>>>>> Behalf Of Hannes Tschofenig >>>>>>>>>>>> Sent: Tuesday, 27 October 2009 8:23 AM >>>>>>>>>>>> To: ecrit@ietf.org >>>>>>>>>>>> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>>>>>>>>>> considered harmful, at least given our current experiences >>>>>>>>>>>> >>>>>>>>>>>> FYI: feedback from Brian regarding a recent ECRIT >>>>>> contribution. >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: geopriv-bounces@ietf.org >>>>>>>>>>>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian >>>>>>>>>>>> Sent: 26 October, 2009 23:10 >>>>>>>>>>>> To: geopriv@ietf.org >>>>>>>>>>>> Subject: [Geopriv] Winterbottom-ecrit-direct considered >>>>>>>>>>>> harmful, at least given our current experiences >>>>>>>>>>>> >>>>>>>>>>>> The notion behind -direct is to not use a service >>>>>> provider to >>>>>>>>>>>> place an emergency call. Instead, the device >>>>>> registers with >>>>>>>>>>>> an Emergency Services Routing Proxy immediately before the >>>>>>>>>>>> call and the call is routed directly from the >>>>>> device to the ESRP. >>>>>>>>>>>> >>>>>>>>>>>> At least at the moment, this is an exceedingly bad idea. >>>>>>>>>>>> >>>>>>>>>>>> Emergency calling authorities like service providers, a lot. >>>>>>>>>>>> They like them because they can hold them >>>>>> accountable, and the >>>>>>>>>>>> service providers don't like theft of service, which is >>>>>>>>>>>> something the emergency call guys have an analog to. >>>>>>>>>>>> >>>>>>>>>>>> The facts are that where unaccountable access to emergency >>>>>>>>>>>> calling is allowed, huge numbers of false calls >>>>>> occur, with no >>>>>>>>>>>> way to stop them, and no way to tell the good ones from the >>>>>>>>>>>> bad ones. This has been seen multiple times where >>>>>> so called >>>>>>>>>>>> "simless" or "unauthenticated" calls are allowed. >>>>>>>>>>>> >>>>>>>>>>>> -direct precisely duplicates simless calling. The only >>>>>>>>>>>> "registration" is an emergency registration, only emergency >>>>>>>>>>>> calls are allowed, any device can make an emergency call if >>>>>>>>>>>> all it has is a (radio) connection to any network. >>>>>>>>>>>> We can predict, with a very high degree of >>>>>> certainty, that the >>>>>>>>>>>> feature will be horribly abused: for example to test that a >>>>>>>>>>>> phone without a service plan works. >>>>>>>>>>>> >>>>>>>>>>>> There have been studies which show tens of thousands of bad >>>>>>>>>>>> calls with zero good ones. Nearly every authority I know >>>>>>>>>>>> where the regulator has insisted on simless calling >>>>>> wants it >>>>>>>>>>>> repealed. There is one counter example I know >>>>>> where the fact >>>>>>>>>>>> that they got a couple, literally, of good calls among the >>>>>>>>>>>> tens of thousands of bad calls was considered >>>>>> enough reason to >>>>>>>>>>>> put up with the problem. >>>>>>>>>>>> >>>>>>>>>>>> Service providers give us information that may be useful: a >>>>>>>>>>>> subscriber name and address for example, which is not >>>>>>>>>>>> spoofable by the caller. They have ways to trace callers, >>>>>>>>>>>> especially bad callers. They don't want their >>>>>> systems abused >>>>>>>>>>>> any more than the emergency calling authorities do. >>>>>>>>>>>> >>>>>>>>>>>> This is a bad idea. A very bad idea. Please stop it. >>>>>>>>>>>> >>>>>>>>>>>> Someday, we may have better ways to prevent abuse. Until we >>>>>>>>>>>> do, service providers are a good thing on an emergency call. >>>>>>>>>>>> We don't want them cut out. >>>>>>>>>>>> >>>>>>>>>>>> Brian >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Geopriv mailing list >>>>>>>>>>>> Geopriv@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 br@brianrosen.net Fri Oct 30 07:06:40 2009 Return-Path: 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 B93393A6903 for ; Fri, 30 Oct 2009 07:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=0.394, 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 QHegxsKbmM9A for ; Fri, 30 Oct 2009 07:06:38 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 91E873A67E9 for ; Fri, 30 Oct 2009 07:06:38 -0700 (PDT) Received: from [209.173.57.233] (helo=[192.168.130.13]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1N3s7r-0000F5-23; Fri, 30 Oct 2009 09:06:47 -0500 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Fri, 30 Oct 2009 10:06:42 -0400 From: Brian Rosen To: "Elwell, John" , Marc Linsner Message-ID: Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4ADN3iYAA8FjA5 In-Reply-To: <7402509E63C5A145A6095D46C179A5B7148B380D@DEMCHP99E35MSX.ww902.siemens.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Fri, 30 Oct 2009 14:06:40 -0000 Well, yes. Normally, your SIP-PBX would route calls outside the domain to some kind of carrier. That is what I want it to do, but I can foresee circumstances where the PBX sends calls to the ESRP. I would like the ESRP to know about the PBX (that is, have it's identity in some list it has, one way or another, so that when it lowers priority of calls from unknown sources, those calls are not lowered. I think such arrangements will be uncommon, but possible. Brian On 10/29/09 5:28 AM, "Elwell, John" wrote: > Brian, > > Just a question for clarification below: > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> On Behalf Of Brian Rosen >> Sent: 29 October 2009 03:18 >> To: Marc Linsner >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >> considered >> >> I'm not worried about security by obscurity. I don't want >> phones (or other >> devices) built to call directly. >> >> -phonebcp says "send the call on your normal outbound call >> path". That's >> what I want it to say, and I don't want it to say "send it >> direct, bypass >> your service provider. > [JRE] So if my normal outbound call path is my SIP-PBX, then the SIP-PBX can > route directly to the PSAP? > > John > > >> >> I'm not stopping attack, I am stopping abuse. >> >> I don't want devices that are not subscribed to services to >> be able to make >> emergency calls (that is, if they can't make "normal" calls, >> they should not >> be able to make emergency calls). >> >> Brian >> >> >> On 10/28/09 6:51 PM, "Marc Linsner" wrote: >> >>> Brian, >>> >>> What I hear you saying: 'if we don't document how to spoof >> a PSAP, then >>> nobody will figure it out.' Isn't that a little short sighted? >>> >>> Joey@miscreant.org will figure out how to establish a SIP >> session with any >>> PSAP in the world within 10 minutes of that PSAP being >> accessible via the >>> Internet, regardless of documentation. >>> >>> I believe there's more harm created in not documenting this for >>> John.Q.Public@ordinary_citizen.com. >>> >>> Granted, nobody here is looking to cause harm to a PSAP. But >>> Joey@miscreant.org can certainly expend public safety >> resources by reporting >>> a bomb threat to a local school. Should we require that >> all SIP calls to >>> the local school come from a trusted SP? Where does it end? >>> >>> This isn't the way to deal with spam. >>> >>> -Marc- >>> >>> >>> >>> On 10/27/09 11:00 AM, "Brian Rosen" wrote: >>> >>>> The first goal is to prevent bad calls. >>>> >>>> The second goal is to indentify the source of the bad calls. >>>> >>>> I'm starting with the first goal. I don't want you to be >> able to take a >>>> device out of a box, plug it into a network, and have the >> only call you can >>>> make be an emergency call. I want the device to actually >> "work" (as in be >>>> able to place calls to all the entities that it was >> intended to) first, and >>>> then be able to place emergency calls. >>>> >>>> Please spend some time in a PSAP while a kid with a >> simless phone has "fun" >>>> with it. Imagine how much fun the test mechanism is as >> opposed to placing >>>> real calls. >>>> >>>> If we somehow get a bad call, we need to send the cops. >> That means we need >>>> an identity (and a location). >>>> >>>> I think a good cert could be the basis of a good identity, >> if we could get >>>> one. I don't see how we do that. >>>> >>>> Brian >>>> >>>> >>>> On 10/27/09 10:39 AM, "Richard Barnes" wrote: >>>> >>>>> Brian, >>>>> >>>>> Is the security goal here more access control (i.e., >> controlling who >>>>> can send calls to a PSAP) or attribution/identification >> for post-hoc >>>>> action. >>>>> >>>>> If it's the latter, then ISTM that the problem can >> largely be reduced >>>>> to having a certificate infrastructure that binds authenticated >>>>> identities to real-world entities. The "extended validation" >>>>> certificates that current commercial CAs issue seem to >> largely satisfy >>>>> this requirement. >>>>> >>>>> --Richard >>>>> >>>>> >>>>> On Oct 27, 2009, at 4:31 PM, Brian Rosen wrote: >>>>> >>>>>> Of course not all VSPs will have trust relationships with all >>>>>> PSAPs. One >>>>>> can hope that long term, we can evolve to transitive trust >>>>>> relationships >>>>>> that work pretty well cross border. >>>>>> >>>>>> The emergency guys are actually terrified of private/individual >>>>>> domains >>>>>> sending them calls, and we're telling them we expect that to be >>>>>> possible, >>>>>> but rare, and we're giving them mechanisms that will effectively >>>>>> allow them >>>>>> to turn off calls selectively, based on factors including what >>>>>> domain the >>>>>> call comes from. They expect that such calls will be one of the >>>>>> loopholes >>>>>> where they get equivalents to sim-less calls, which drive them >>>>>> nuts. They >>>>>> don't want ANY calls that don't come from service providers, >>>>>> although they >>>>>> seem to be okay with the notion that the SP may not have great >>>>>> identity (AOL >>>>>> being a poster child). So, while indeed they >> understand, and have >>>>>> concerns >>>>>> about having to take calls from Sierra Leone VoIP >> services Pty, they >>>>>> would >>>>>> much rather have a call that went through them then a >> call that went >>>>>> through >>>>>> no service provider at all. >>>>>> >>>>>> I'm not trying to make calls direct from devices or >> private domains >>>>>> impossible, but I think the notion that we're promoting them is a >>>>>> very bad >>>>>> idea until we have effective mechanisms to prevent abuse. >>>>>> >>>>>> Brian >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 10/27/09 9:02 AM, "Marc Linsner" wrote: >>>>>> >>>>>>> Brian, >>>>>>> >>>>>>> I'm a little confused. I don't remember you objecting to >>>>>>> requirement RE1 >>>>>>> from RFC5012 and I remember your use case about a >> Sierra Leone VSP. >>>>>>> >>>>>>> Are you implying that *all* VSPs will have a trust relationships >>>>>>> with *all* >>>>>>> PSAPs? >>>>>>> >>>>>>> What is the difference between a call coming from a private/ >>>>>>> individual >>>>>>> domain (as in not a commercial VSP) and a VSP on the >> other side of >>>>>>> the world >>>>>>> (outside the jurisdiction)? >>>>>>> >>>>>>> I'm trying to figure out whether you're objecting to anonymous >>>>>>> calls to the >>>>>>> PSAP or the mechanisms proposed in this draft? >>>>>>> >>>>>>> [Don't take this as my endorsement of the draft, as I'm >> not sure I >>>>>>> agree >>>>>>> with UAs registering with the ESRP.] >>>>>>> >>>>>>> -Marc- >>>>>>> >>>>>>> >>>>>>> On 10/26/09 8:59 PM, "Brian Rosen" wrote: >>>>>>> >>>>>>>> First of all, I put it on the wrong email list, sorry >> about that. >>>>>>>> >>>>>>>> Then, we have carefully arranged it so that there is >> no identity >>>>>>>> coming from >>>>>>>> the access network provider, and because the location is coming >>>>>>>> from that >>>>>>>> provider, we really don't want to. But even if we >> did, we would >>>>>>>> need a >>>>>>>> really good identifier, and there isn't one. >>>>>>>> >>>>>>>> The problem we have with -direct is anonymous callers, >> and if they >>>>>>>> have any >>>>>>>> option, they would also be location-less. Until and >> unless we get >>>>>>>> rid of >>>>>>>> anonymity, we can't encourage service provider-less calls. The >>>>>>>> draft does >>>>>>>> not make any provision to provide any kind of identity. Many >>>>>>>> networks >>>>>>>> (think free wifi for example) would make providing >> good identity >>>>>>>> difficult. >>>>>>>> >>>>>>>> The fact is that there is a SERVICE provider in nearly >> all of the >>>>>>>> communications systems. The SERVICE provider is in a >> position to >>>>>>>> assist >>>>>>>> the emergency calling system when it needs more information. >>>>>>>> That's what a >>>>>>>> good SERVICE provider does. Cutting them out is not a great >>>>>>>> idea. Most of >>>>>>>> the attempts to provide real time communications between people >>>>>>>> have evolved >>>>>>>> to using service providers, even when there were >> alternatives. File >>>>>>>> transfer via something like Torrent is a counterexample (which >>>>>>>> isn't real >>>>>>>> time), but even there, you end up with service >> providers like The >>>>>>>> Pirate Bay >>>>>>>> (R.I.P) to provide introduction services. I don't think we're >>>>>>>> going to see >>>>>>>> changes that eliminate service providers, and in this >> case, they >>>>>>>> provide >>>>>>>> value to the emergency calling systems. All of the emergency >>>>>>>> professionals >>>>>>>> I know have issues with service providers, but they would react >>>>>>>> with horror >>>>>>>> if you suggested cutting them out. Ask them, please. >>>>>>>> >>>>>>>> So, I claim you have a solution in search of a >> problem. We have >>>>>>>> solved the >>>>>>>> "calling network isn't the access network" problem >> already. Service >>>>>>>> providers ARE in the path now, in nearly every case (in fact a >>>>>>>> counter >>>>>>>> example escapes me, although there probably are some). >> There is >>>>>>>> no movement >>>>>>>> I can detect which would change that any time soon; quite the >>>>>>>> opposite. We >>>>>>>> have a known killer problem without some kind of >> subscription to a >>>>>>>> service >>>>>>>> that provides a good identity, for which you provide >> no answers. >>>>>>>> We have >>>>>>>> experience with the killer problem: sim-less calling >> was supposed >>>>>>>> to provide >>>>>>>> a way to make an emergency call in exactly the kinds of >>>>>>>> circumstances you >>>>>>>> are describing. Our real world experience is that you create a >>>>>>>> huge problem >>>>>>>> that diverts resources from helping people to chasing >> scammers and >>>>>>>> flea-market sellers. >>>>>>>> >>>>>>>> Nothing is perfect: you can get a AIM screen name >> without a very >>>>>>>> good >>>>>>>> identity for example. However, the notion that we're going to >>>>>>>> provide >>>>>>>> direct access without a service provider deliberately, >> especially >>>>>>>> without >>>>>>>> really good identity from the access network is, in my >> opinion not >>>>>>>> only a >>>>>>>> no, it's a heck no. I'll line up as many emergency service >>>>>>>> professionals as >>>>>>>> you would like to tell you this is a harmful idea. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 10/26/09 7:56 PM, "Dawson, Martin" >> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I am glad this has come up. It's a debate that has to >> happen if >>>>>>>>> we are to >>>>>>>>> move >>>>>>>>> beyond a long standing legacy misconception. >>>>>>>>> >>>>>>>>> In the circuit service world - whether it was POTS or >> mobile, the >>>>>>>>> access >>>>>>>>> network had full responsibility for delivering the emergency >>>>>>>>> call. In that >>>>>>>>> world, routing an emergency call meant getting a circuit >>>>>>>>> established to the >>>>>>>>> correct call center. In most parts of the world, this was done >>>>>>>>> using the >>>>>>>>> regional part of the PSTN to switch the circuit to a >> call center >>>>>>>>> on the >>>>>>>>> PSTN. >>>>>>>>> In some jurisdictions, such as the US, it was done >> directly from >>>>>>>>> the local >>>>>>>>> exchange carrier to the call center. Either way, there was no >>>>>>>>> third party >>>>>>>>> involved. >>>>>>>>> >>>>>>>>> Now we have the Internet. We still have public access network >>>>>>>>> providers. >>>>>>>>> They >>>>>>>>> switch packets onto the Internet for their >> subscribers. They can >>>>>>>>> similarly >>>>>>>>> ensure that packets reach the local emergency call centers. >>>>>>>>> >>>>>>>>> The fact is that there was no equivalent of a VSP in the >>>>>>>>> traditional >>>>>>>>> environment. VoIP is a presence service, and it had no common >>>>>>>>> equivalent in >>>>>>>>> the PSTN world. It could have, but the narrowband state of >>>>>>>>> technology and >>>>>>>>> the >>>>>>>>> common market use cases didn't support its development. By the >>>>>>>>> time ISDN >>>>>>>>> arrived, the PSTN had already slipped into its >> palliative stage >>>>>>>>> without >>>>>>>>> realizing it. >>>>>>>>> >>>>>>>>> It's an entrenched misconception that because the >> circuit service >>>>>>>>> provided >>>>>>>>> by >>>>>>>>> exchange carriers was most commonly used for "voice" (but, it >>>>>>>>> should be >>>>>>>>> noted, >>>>>>>>> also for fax, telex, tty, security system monitoring >> and, even, >>>>>>>>> IP data) >>>>>>>>> that >>>>>>>>> VSPs are somehow equivalent to exchange carriers. >> They are not. >>>>>>>>> >>>>>>>>> Indeed, involving VSPs in emergency calls is the Internet >>>>>>>>> equivalent of >>>>>>>>> involving long distance providers in POTS emergency >> calls. They >>>>>>>>> are neither >>>>>>>>> necessary nor particularly helpful; they can't be >> guaranteed to >>>>>>>>> be within >>>>>>>>> the >>>>>>>>> emergency jurisdiction; depending on them actually >> diminishes the >>>>>>>>> efficacy >>>>>>>>> of >>>>>>>>> emergency service access. It does not help the caller, the >>>>>>>>> emergency >>>>>>>>> service, >>>>>>>>> nor the third party to insist on the third party's >> involvement. >>>>>>>>> >>>>>>>>> It can't be helped if you have over sold the benefits of VSP >>>>>>>>> involvement to >>>>>>>>> yourself and others Brian. It is time to have a >> reasoned debate. >>>>>>>>> From my >>>>>>>>> perspective, the argument that there is no "subscription" >>>>>>>>> involved is >>>>>>>>> patently >>>>>>>>> false. There has to be a subscription of some description in >>>>>>>>> order to get to >>>>>>>>> the Internet. Yes, there is free public Internet >> access (just as >>>>>>>>> there are >>>>>>>>> free courtesy phones on the PSTN and free access to emergency >>>>>>>>> services from >>>>>>>>> pay phones. All these services are still connected to >> the public >>>>>>>>> Internet >>>>>>>>> infrastructure and they all represent an "operator" with some >>>>>>>>> level of >>>>>>>>> information about the caller. >>>>>>>>> >>>>>>>>> With the over-emphasis on VSPs, what is missing from the ECRIT >>>>>>>>> and i3 models >>>>>>>>> is the direct interface for querying the access network for >>>>>>>>> subscriber data >>>>>>>>> (should it prove necessary). These models need to >> take the long >>>>>>>>> view of how >>>>>>>>> emergency calling is done in the Internet age; they >> should not be >>>>>>>>> protracting >>>>>>>>> an unnecessary reliance on VSPs. >>>>>>>>> >>>>>>>>> I have deleted the premature and prejudicial text from the >>>>>>>>> subject heading. >>>>>>>>> And I'll leave this on ECRIT as the most appropriate WG. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Martin >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: ecrit-bounces@ietf.org >> [mailto:ecrit-bounces@ietf.org] On >>>>>>>>> Behalf Of >>>>>>>>> Hannes Tschofenig >>>>>>>>> Sent: Tuesday, 27 October 2009 8:23 AM >>>>>>>>> To: ecrit@ietf.org >>>>>>>>> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>>>>>>> considered harmful, >>>>>>>>> at least given our current experiences >>>>>>>>> >>>>>>>>> FYI: feedback from Brian regarding a recent ECRIT >> contribution. >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: geopriv-bounces@ietf.org >>>>>>>>>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian >>>>>>>>>> Sent: 26 October, 2009 23:10 >>>>>>>>>> To: geopriv@ietf.org >>>>>>>>>> Subject: [Geopriv] Winterbottom-ecrit-direct considered >>>>>>>>>> harmful, at least given our current experiences >>>>>>>>>> >>>>>>>>>> The notion behind -direct is to not use a service provider to >>>>>>>>>> place an emergency call. Instead, the device registers with >>>>>>>>>> an Emergency Services Routing Proxy immediately before the >>>>>>>>>> call and the call is routed directly from the device >> to the ESRP. >>>>>>>>>> >>>>>>>>>> At least at the moment, this is an exceedingly bad idea. >>>>>>>>>> >>>>>>>>>> Emergency calling authorities like service providers, a lot. >>>>>>>>>> They like them because they can hold them >> accountable, and the >>>>>>>>>> service providers don't like theft of service, which is >>>>>>>>>> something the emergency call guys have an analog to. >>>>>>>>>> >>>>>>>>>> The facts are that where unaccountable access to emergency >>>>>>>>>> calling is allowed, huge numbers of false calls >> occur, with no >>>>>>>>>> way to stop them, and no way to tell the good ones from the >>>>>>>>>> bad ones. This has been seen multiple times where so called >>>>>>>>>> "simless" or "unauthenticated" calls are allowed. >>>>>>>>>> >>>>>>>>>> -direct precisely duplicates simless calling. The only >>>>>>>>>> "registration" is an emergency registration, only emergency >>>>>>>>>> calls are allowed, any device can make an emergency call if >>>>>>>>>> all it has is a (radio) connection to any network. >>>>>>>>>> We can predict, with a very high degree of >> certainty, that the >>>>>>>>>> feature will be horribly abused: for example to test that a >>>>>>>>>> phone without a service plan works. >>>>>>>>>> >>>>>>>>>> There have been studies which show tens of thousands of bad >>>>>>>>>> calls with zero good ones. Nearly every authority I know >>>>>>>>>> where the regulator has insisted on simless calling wants it >>>>>>>>>> repealed. There is one counter example I know where the fact >>>>>>>>>> that they got a couple, literally, of good calls among the >>>>>>>>>> tens of thousands of bad calls was considered enough >> reason to >>>>>>>>>> put up with the problem. >>>>>>>>>> >>>>>>>>>> Service providers give us information that may be useful: a >>>>>>>>>> subscriber name and address for example, which is not >>>>>>>>>> spoofable by the caller. They have ways to trace callers, >>>>>>>>>> especially bad callers. They don't want their systems abused >>>>>>>>>> any more than the emergency calling authorities do. >>>>>>>>>> >>>>>>>>>> This is a bad idea. A very bad idea. Please stop it. >>>>>>>>>> >>>>>>>>>> Someday, we may have better ways to prevent abuse. Until we >>>>>>>>>> do, service providers are a good thing on an emergency call. >>>>>>>>>> We don't want them cut out. >>>>>>>>>> >>>>>>>>>> Brian >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Geopriv mailing list >>>>>>>>>> Geopriv@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 john.elwell@siemens-enterprise.com Fri Oct 30 09:53:16 2009 Return-Path: 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 5E0C53A682B for ; Fri, 30 Oct 2009 09:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.056 X-Spam-Level: X-Spam-Status: No, score=-6.056 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 5ph+Mz4Q44kq for ; Fri, 30 Oct 2009 09:53:14 -0700 (PDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by core3.amsl.com (Postfix) with ESMTP id 865EB3A67D1 for ; Fri, 30 Oct 2009 09:53:13 -0700 (PDT) Received: from mail1.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id n9UGrL9R028080; Fri, 30 Oct 2009 17:53:21 +0100 Received: from DEMCHP99ET1MSX.ww902.siemens.net (demchp99et1msx.ww902.siemens.net [139.25.131.180]) by mail1.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9UGrLHo025918; Fri, 30 Oct 2009 17:53:21 +0100 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET1MSX.ww902.siemens.net ([139.25.131.180]) with mapi; Fri, 30 Oct 2009 17:53:20 +0100 From: "Elwell, John" To: Brian Rosen , Marc Linsner Date: Fri, 30 Oct 2009 17:53:18 +0100 Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4ADN3iYAA8FjA5AAPSv6A= Message-ID: <7402509E63C5A145A6095D46C179A5B7148B3ABF@DEMCHP99E35MSX.ww902.siemens.net> References: <7402509E63C5A145A6095D46C179A5B7148B380D@DEMCHP99E35MSX.ww902.siemens.net> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Fri, 30 Oct 2009 16:53:16 -0000 Brian, So suppose my SIP-PBX is in the UK and uses a VoIP service provider in the = UK. I am in a hotel in the US and make an emergency call using a device tha= t uses my SIP-PBX in the UK as its outbound proxy. From the location determ= ined by my device, the call needs to go to a PSAP in the US. Will routing v= ia the UK service provider really help? It seems unlikely that the UK servi= ce provider would have an arrangement with a US PSAP. So perhaps the UK pro= vider could route it on to a US provider, which hopefully would have such a= n arrangement. This round-about routing seems to increase the chances of fa= ilure. It seems what is really needed in this situation is either: - routing directly from the SIP-PBX in the UK to the US PSAP; or - my device sends the call directly to the US PSAP. John > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: 30 October 2009 14:07 > To: Elwell, John; Marc Linsner > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct > considered > > Well, yes. > > Normally, your SIP-PBX would route calls outside the domain > to some kind of > carrier. That is what I want it to do, but I can foresee > circumstances > where the PBX sends calls to the ESRP. I would like the ESRP > to know about > the PBX (that is, have it's identity in some list it has, one way or > another, so that when it lowers priority of calls from > unknown sources, > those calls are not lowered. I think such arrangements will > be uncommon, > but possible. > > Brian > > > On 10/29/09 5:28 AM, "Elwell, John" > > wrote: > > > Brian, > > > > Just a question for clarification below: > > > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >> On Behalf Of Brian Rosen > >> Sent: 29 October 2009 03:18 > >> To: Marc Linsner > >> Cc: ecrit@ietf.org > >> Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct > >> considered > >> > >> I'm not worried about security by obscurity. I don't want > >> phones (or other > >> devices) built to call directly. > >> > >> -phonebcp says "send the call on your normal outbound call > >> path". That's > >> what I want it to say, and I don't want it to say "send it > >> direct, bypass > >> your service provider. > > [JRE] So if my normal outbound call path is my SIP-PBX, > then the SIP-PBX can > > route directly to the PSAP? > > > > John > > > > > >> > >> I'm not stopping attack, I am stopping abuse. > >> > >> I don't want devices that are not subscribed to services to > >> be able to make > >> emergency calls (that is, if they can't make "normal" calls, > >> they should not > >> be able to make emergency calls). > >> > >> Brian > >> > >> > >> On 10/28/09 6:51 PM, "Marc Linsner" wrote: > >> > >>> Brian, > >>> > >>> What I hear you saying: 'if we don't document how to spoof > >> a PSAP, then > >>> nobody will figure it out.' Isn't that a little short sighted? > >>> > >>> Joey@miscreant.org will figure out how to establish a SIP > >> session with any > >>> PSAP in the world within 10 minutes of that PSAP being > >> accessible via the > >>> Internet, regardless of documentation. > >>> > >>> I believe there's more harm created in not documenting this for > >>> John.Q.Public@ordinary_citizen.com. > >>> > >>> Granted, nobody here is looking to cause harm to a PSAP. But > >>> Joey@miscreant.org can certainly expend public safety > >> resources by reporting > >>> a bomb threat to a local school. Should we require that > >> all SIP calls to > >>> the local school come from a trusted SP? Where does it end? > >>> > >>> This isn't the way to deal with spam. > >>> > >>> -Marc- > >>> > >>> > >>> > >>> On 10/27/09 11:00 AM, "Brian Rosen" wrote: > >>> > >>>> The first goal is to prevent bad calls. > >>>> > >>>> The second goal is to indentify the source of the bad calls. > >>>> > >>>> I'm starting with the first goal. I don't want you to be > >> able to take a > >>>> device out of a box, plug it into a network, and have the > >> only call you can > >>>> make be an emergency call. I want the device to actually > >> "work" (as in be > >>>> able to place calls to all the entities that it was > >> intended to) first, and > >>>> then be able to place emergency calls. > >>>> > >>>> Please spend some time in a PSAP while a kid with a > >> simless phone has "fun" > >>>> with it. Imagine how much fun the test mechanism is as > >> opposed to placing > >>>> real calls. > >>>> > >>>> If we somehow get a bad call, we need to send the cops. > >> That means we need > >>>> an identity (and a location). > >>>> > >>>> I think a good cert could be the basis of a good identity, > >> if we could get > >>>> one. I don't see how we do that. > >>>> > >>>> Brian > >>>> > >>>> > >>>> On 10/27/09 10:39 AM, "Richard Barnes" wrote: > >>>> > >>>>> Brian, > >>>>> > >>>>> Is the security goal here more access control (i.e., > >> controlling who > >>>>> can send calls to a PSAP) or attribution/identification > >> for post-hoc > >>>>> action. > >>>>> > >>>>> If it's the latter, then ISTM that the problem can > >> largely be reduced > >>>>> to having a certificate infrastructure that binds authenticated > >>>>> identities to real-world entities. The "extended validation" > >>>>> certificates that current commercial CAs issue seem to > >> largely satisfy > >>>>> this requirement. > >>>>> > >>>>> --Richard > >>>>> > >>>>> > >>>>> On Oct 27, 2009, at 4:31 PM, Brian Rosen wrote: > >>>>> > >>>>>> Of course not all VSPs will have trust relationships with all > >>>>>> PSAPs. One > >>>>>> can hope that long term, we can evolve to transitive trust > >>>>>> relationships > >>>>>> that work pretty well cross border. > >>>>>> > >>>>>> The emergency guys are actually terrified of private/individual > >>>>>> domains > >>>>>> sending them calls, and we're telling them we expect that to be > >>>>>> possible, > >>>>>> but rare, and we're giving them mechanisms that will > effectively > >>>>>> allow them > >>>>>> to turn off calls selectively, based on factors including what > >>>>>> domain the > >>>>>> call comes from. They expect that such calls will be > one of the > >>>>>> loopholes > >>>>>> where they get equivalents to sim-less calls, which drive them > >>>>>> nuts. They > >>>>>> don't want ANY calls that don't come from service providers, > >>>>>> although they > >>>>>> seem to be okay with the notion that the SP may not have great > >>>>>> identity (AOL > >>>>>> being a poster child). So, while indeed they > >> understand, and have > >>>>>> concerns > >>>>>> about having to take calls from Sierra Leone VoIP > >> services Pty, they > >>>>>> would > >>>>>> much rather have a call that went through them then a > >> call that went > >>>>>> through > >>>>>> no service provider at all. > >>>>>> > >>>>>> I'm not trying to make calls direct from devices or > >> private domains > >>>>>> impossible, but I think the notion that we're > promoting them is a > >>>>>> very bad > >>>>>> idea until we have effective mechanisms to prevent abuse. > >>>>>> > >>>>>> Brian > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> On 10/27/09 9:02 AM, "Marc Linsner" wrote: > >>>>>> > >>>>>>> Brian, > >>>>>>> > >>>>>>> I'm a little confused. I don't remember you objecting to > >>>>>>> requirement RE1 > >>>>>>> from RFC5012 and I remember your use case about a > >> Sierra Leone VSP. > >>>>>>> > >>>>>>> Are you implying that *all* VSPs will have a trust > relationships > >>>>>>> with *all* > >>>>>>> PSAPs? > >>>>>>> > >>>>>>> What is the difference between a call coming from a private/ > >>>>>>> individual > >>>>>>> domain (as in not a commercial VSP) and a VSP on the > >> other side of > >>>>>>> the world > >>>>>>> (outside the jurisdiction)? > >>>>>>> > >>>>>>> I'm trying to figure out whether you're objecting to anonymous > >>>>>>> calls to the > >>>>>>> PSAP or the mechanisms proposed in this draft? > >>>>>>> > >>>>>>> [Don't take this as my endorsement of the draft, as I'm > >> not sure I > >>>>>>> agree > >>>>>>> with UAs registering with the ESRP.] > >>>>>>> > >>>>>>> -Marc- > >>>>>>> > >>>>>>> > >>>>>>> On 10/26/09 8:59 PM, "Brian Rosen" wrote: > >>>>>>> > >>>>>>>> First of all, I put it on the wrong email list, sorry > >> about that. > >>>>>>>> > >>>>>>>> Then, we have carefully arranged it so that there is > >> no identity > >>>>>>>> coming from > >>>>>>>> the access network provider, and because the > location is coming > >>>>>>>> from that > >>>>>>>> provider, we really don't want to. But even if we > >> did, we would > >>>>>>>> need a > >>>>>>>> really good identifier, and there isn't one. > >>>>>>>> > >>>>>>>> The problem we have with -direct is anonymous callers, > >> and if they > >>>>>>>> have any > >>>>>>>> option, they would also be location-less. Until and > >> unless we get > >>>>>>>> rid of > >>>>>>>> anonymity, we can't encourage service provider-less > calls. The > >>>>>>>> draft does > >>>>>>>> not make any provision to provide any kind of identity. Many > >>>>>>>> networks > >>>>>>>> (think free wifi for example) would make providing > >> good identity > >>>>>>>> difficult. > >>>>>>>> > >>>>>>>> The fact is that there is a SERVICE provider in nearly > >> all of the > >>>>>>>> communications systems. The SERVICE provider is in a > >> position to > >>>>>>>> assist > >>>>>>>> the emergency calling system when it needs more information. > >>>>>>>> That's what a > >>>>>>>> good SERVICE provider does. Cutting them out is not a great > >>>>>>>> idea. Most of > >>>>>>>> the attempts to provide real time communications > between people > >>>>>>>> have evolved > >>>>>>>> to using service providers, even when there were > >> alternatives. File > >>>>>>>> transfer via something like Torrent is a > counterexample (which > >>>>>>>> isn't real > >>>>>>>> time), but even there, you end up with service > >> providers like The > >>>>>>>> Pirate Bay > >>>>>>>> (R.I.P) to provide introduction services. I don't > think we're > >>>>>>>> going to see > >>>>>>>> changes that eliminate service providers, and in this > >> case, they > >>>>>>>> provide > >>>>>>>> value to the emergency calling systems. All of the emergency > >>>>>>>> professionals > >>>>>>>> I know have issues with service providers, but they > would react > >>>>>>>> with horror > >>>>>>>> if you suggested cutting them out. Ask them, please. > >>>>>>>> > >>>>>>>> So, I claim you have a solution in search of a > >> problem. We have > >>>>>>>> solved the > >>>>>>>> "calling network isn't the access network" problem > >> already. Service > >>>>>>>> providers ARE in the path now, in nearly every case > (in fact a > >>>>>>>> counter > >>>>>>>> example escapes me, although there probably are some). > >> There is > >>>>>>>> no movement > >>>>>>>> I can detect which would change that any time soon; quite the > >>>>>>>> opposite. We > >>>>>>>> have a known killer problem without some kind of > >> subscription to a > >>>>>>>> service > >>>>>>>> that provides a good identity, for which you provide > >> no answers. > >>>>>>>> We have > >>>>>>>> experience with the killer problem: sim-less calling > >> was supposed > >>>>>>>> to provide > >>>>>>>> a way to make an emergency call in exactly the kinds of > >>>>>>>> circumstances you > >>>>>>>> are describing. Our real world experience is that > you create a > >>>>>>>> huge problem > >>>>>>>> that diverts resources from helping people to chasing > >> scammers and > >>>>>>>> flea-market sellers. > >>>>>>>> > >>>>>>>> Nothing is perfect: you can get a AIM screen name > >> without a very > >>>>>>>> good > >>>>>>>> identity for example. However, the notion that > we're going to > >>>>>>>> provide > >>>>>>>> direct access without a service provider deliberately, > >> especially > >>>>>>>> without > >>>>>>>> really good identity from the access network is, in my > >> opinion not > >>>>>>>> only a > >>>>>>>> no, it's a heck no. I'll line up as many emergency service > >>>>>>>> professionals as > >>>>>>>> you would like to tell you this is a harmful idea. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On 10/26/09 7:56 PM, "Dawson, Martin" > >> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> I am glad this has come up. It's a debate that has to > >> happen if > >>>>>>>>> we are to > >>>>>>>>> move > >>>>>>>>> beyond a long standing legacy misconception. > >>>>>>>>> > >>>>>>>>> In the circuit service world - whether it was POTS or > >> mobile, the > >>>>>>>>> access > >>>>>>>>> network had full responsibility for delivering the emergency > >>>>>>>>> call. In that > >>>>>>>>> world, routing an emergency call meant getting a circuit > >>>>>>>>> established to the > >>>>>>>>> correct call center. In most parts of the world, > this was done > >>>>>>>>> using the > >>>>>>>>> regional part of the PSTN to switch the circuit to a > >> call center > >>>>>>>>> on the > >>>>>>>>> PSTN. > >>>>>>>>> In some jurisdictions, such as the US, it was done > >> directly from > >>>>>>>>> the local > >>>>>>>>> exchange carrier to the call center. Either way, > there was no > >>>>>>>>> third party > >>>>>>>>> involved. > >>>>>>>>> > >>>>>>>>> Now we have the Internet. We still have public > access network > >>>>>>>>> providers. > >>>>>>>>> They > >>>>>>>>> switch packets onto the Internet for their > >> subscribers. They can > >>>>>>>>> similarly > >>>>>>>>> ensure that packets reach the local emergency call centers. > >>>>>>>>> > >>>>>>>>> The fact is that there was no equivalent of a VSP in the > >>>>>>>>> traditional > >>>>>>>>> environment. VoIP is a presence service, and it had > no common > >>>>>>>>> equivalent in > >>>>>>>>> the PSTN world. It could have, but the narrowband state of > >>>>>>>>> technology and > >>>>>>>>> the > >>>>>>>>> common market use cases didn't support its > development. By the > >>>>>>>>> time ISDN > >>>>>>>>> arrived, the PSTN had already slipped into its > >> palliative stage > >>>>>>>>> without > >>>>>>>>> realizing it. > >>>>>>>>> > >>>>>>>>> It's an entrenched misconception that because the > >> circuit service > >>>>>>>>> provided > >>>>>>>>> by > >>>>>>>>> exchange carriers was most commonly used for > "voice" (but, it > >>>>>>>>> should be > >>>>>>>>> noted, > >>>>>>>>> also for fax, telex, tty, security system monitoring > >> and, even, > >>>>>>>>> IP data) > >>>>>>>>> that > >>>>>>>>> VSPs are somehow equivalent to exchange carriers. > >> They are not. > >>>>>>>>> > >>>>>>>>> Indeed, involving VSPs in emergency calls is the Internet > >>>>>>>>> equivalent of > >>>>>>>>> involving long distance providers in POTS emergency > >> calls. They > >>>>>>>>> are neither > >>>>>>>>> necessary nor particularly helpful; they can't be > >> guaranteed to > >>>>>>>>> be within > >>>>>>>>> the > >>>>>>>>> emergency jurisdiction; depending on them actually > >> diminishes the > >>>>>>>>> efficacy > >>>>>>>>> of > >>>>>>>>> emergency service access. It does not help the caller, the > >>>>>>>>> emergency > >>>>>>>>> service, > >>>>>>>>> nor the third party to insist on the third party's > >> involvement. > >>>>>>>>> > >>>>>>>>> It can't be helped if you have over sold the benefits of VSP > >>>>>>>>> involvement to > >>>>>>>>> yourself and others Brian. It is time to have a > >> reasoned debate. > >>>>>>>>> From my > >>>>>>>>> perspective, the argument that there is no "subscription" > >>>>>>>>> involved is > >>>>>>>>> patently > >>>>>>>>> false. There has to be a subscription of some description in > >>>>>>>>> order to get to > >>>>>>>>> the Internet. Yes, there is free public Internet > >> access (just as > >>>>>>>>> there are > >>>>>>>>> free courtesy phones on the PSTN and free access to > emergency > >>>>>>>>> services from > >>>>>>>>> pay phones. All these services are still connected to > >> the public > >>>>>>>>> Internet > >>>>>>>>> infrastructure and they all represent an "operator" > with some > >>>>>>>>> level of > >>>>>>>>> information about the caller. > >>>>>>>>> > >>>>>>>>> With the over-emphasis on VSPs, what is missing > from the ECRIT > >>>>>>>>> and i3 models > >>>>>>>>> is the direct interface for querying the access network for > >>>>>>>>> subscriber data > >>>>>>>>> (should it prove necessary). These models need to > >> take the long > >>>>>>>>> view of how > >>>>>>>>> emergency calling is done in the Internet age; they > >> should not be > >>>>>>>>> protracting > >>>>>>>>> an unnecessary reliance on VSPs. > >>>>>>>>> > >>>>>>>>> I have deleted the premature and prejudicial text from the > >>>>>>>>> subject heading. > >>>>>>>>> And I'll leave this on ECRIT as the most appropriate WG. > >>>>>>>>> > >>>>>>>>> Cheers, > >>>>>>>>> Martin > >>>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: ecrit-bounces@ietf.org > >> [mailto:ecrit-bounces@ietf.org] On > >>>>>>>>> Behalf Of > >>>>>>>>> Hannes Tschofenig > >>>>>>>>> Sent: Tuesday, 27 October 2009 8:23 AM > >>>>>>>>> To: ecrit@ietf.org > >>>>>>>>> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct > >>>>>>>>> considered harmful, > >>>>>>>>> at least given our current experiences > >>>>>>>>> > >>>>>>>>> FYI: feedback from Brian regarding a recent ECRIT > >> contribution. > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: geopriv-bounces@ietf.org > >>>>>>>>>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian > >>>>>>>>>> Sent: 26 October, 2009 23:10 > >>>>>>>>>> To: geopriv@ietf.org > >>>>>>>>>> Subject: [Geopriv] Winterbottom-ecrit-direct considered > >>>>>>>>>> harmful, at least given our current experiences > >>>>>>>>>> > >>>>>>>>>> The notion behind -direct is to not use a service > provider to > >>>>>>>>>> place an emergency call. Instead, the device > registers with > >>>>>>>>>> an Emergency Services Routing Proxy immediately before the > >>>>>>>>>> call and the call is routed directly from the device > >> to the ESRP. > >>>>>>>>>> > >>>>>>>>>> At least at the moment, this is an exceedingly bad idea. > >>>>>>>>>> > >>>>>>>>>> Emergency calling authorities like service > providers, a lot. > >>>>>>>>>> They like them because they can hold them > >> accountable, and the > >>>>>>>>>> service providers don't like theft of service, which is > >>>>>>>>>> something the emergency call guys have an analog to. > >>>>>>>>>> > >>>>>>>>>> The facts are that where unaccountable access to emergency > >>>>>>>>>> calling is allowed, huge numbers of false calls > >> occur, with no > >>>>>>>>>> way to stop them, and no way to tell the good ones from the > >>>>>>>>>> bad ones. This has been seen multiple times where > so called > >>>>>>>>>> "simless" or "unauthenticated" calls are allowed. > >>>>>>>>>> > >>>>>>>>>> -direct precisely duplicates simless calling. The only > >>>>>>>>>> "registration" is an emergency registration, only emergency > >>>>>>>>>> calls are allowed, any device can make an emergency call if > >>>>>>>>>> all it has is a (radio) connection to any network. > >>>>>>>>>> We can predict, with a very high degree of > >> certainty, that the > >>>>>>>>>> feature will be horribly abused: for example to test that a > >>>>>>>>>> phone without a service plan works. > >>>>>>>>>> > >>>>>>>>>> There have been studies which show tens of thousands of bad > >>>>>>>>>> calls with zero good ones. Nearly every authority I know > >>>>>>>>>> where the regulator has insisted on simless > calling wants it > >>>>>>>>>> repealed. There is one counter example I know > where the fact > >>>>>>>>>> that they got a couple, literally, of good calls among the > >>>>>>>>>> tens of thousands of bad calls was considered enough > >> reason to > >>>>>>>>>> put up with the problem. > >>>>>>>>>> > >>>>>>>>>> Service providers give us information that may be useful: a > >>>>>>>>>> subscriber name and address for example, which is not > >>>>>>>>>> spoofable by the caller. They have ways to trace callers, > >>>>>>>>>> especially bad callers. They don't want their > systems abused > >>>>>>>>>> any more than the emergency calling authorities do. > >>>>>>>>>> > >>>>>>>>>> This is a bad idea. A very bad idea. Please stop it. > >>>>>>>>>> > >>>>>>>>>> Someday, we may have better ways to prevent abuse. Until we > >>>>>>>>>> do, service providers are a good thing on an > emergency call. > >>>>>>>>>> We don't want them cut out. > >>>>>>>>>> > >>>>>>>>>> Brian > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> Geopriv mailing list > >>>>>>>>>> Geopriv@ietf.org > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> 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 > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 br@brianrosen.net Fri Oct 30 10:36:33 2009 Return-Path: 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 B4B4D3A684E for ; Fri, 30 Oct 2009 10:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=0.374, 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 HMDpPrVEX4Lr for ; Fri, 30 Oct 2009 10:36:31 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 788C03A6768 for ; Fri, 30 Oct 2009 10:36:31 -0700 (PDT) Received: from [209.173.57.233] (helo=[192.168.130.13]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1N3vOv-0004Dy-MA; Fri, 30 Oct 2009 12:36:38 -0500 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Fri, 30 Oct 2009 13:36:38 -0400 From: Brian Rosen To: "Elwell, John" , Marc Linsner Message-ID: Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4ADN3iYAA8FjA5AAPSv6AAA4I1Tw== In-Reply-To: <7402509E63C5A145A6095D46C179A5B7148B3ABF@DEMCHP99E35MSX.ww902.siemens.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Fri, 30 Oct 2009 17:36:33 -0000 Nope, your UK provider can correctly route. Actually, if your phone is phonebcp compliant, all that means is the service provider forwards the call where the phone is trying to send it (to the ESRP learned from the ECRF). Assuming the UK provider gets the location from the phone (in the Geolocation header), it could route, or, perhaps more relevant, it can verify the route. There is no need to send it through a U.S. Service provider, who couldn't help us at all. And the UK provider may well be able to help. We want to know about them. They may have information that is useful. As was discussed a few messages ago, it may be that the UK service provider has an identity that the UK emergency call authorities trust. We may be able to arrange that the US emergency call authorities can figure out that the UK trust relationship is in place, and transitively trust the UK provider, even though it has no relationship with that provider. This might be as simple as a signature on a cert by the UK authorities that the US authorities can verify simply by having access to the (presumably well known) UK CA cert. I think we will have such certs available for US service providers if other emergency authorities wish to use similar mechanisms. Brian On 10/30/09 12:53 PM, "Elwell, John" wrote: > Brian, > > So suppose my SIP-PBX is in the UK and uses a VoIP service provider in the UK. > I am in a hotel in the US and make an emergency call using a device that uses > my SIP-PBX in the UK as its outbound proxy. From the location determined by my > device, the call needs to go to a PSAP in the US. Will routing via the UK > service provider really help? It seems unlikely that the UK service provider > would have an arrangement with a US PSAP. So perhaps the UK provider could > route it on to a US provider, which hopefully would have such an arrangement. > This round-about routing seems to increase the chances of failure. > > It seems what is really needed in this situation is either: > - routing directly from the SIP-PBX in the UK to the US PSAP; or > - my device sends the call directly to the US PSAP. > > John > >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Sent: 30 October 2009 14:07 >> To: Elwell, John; Marc Linsner >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >> considered >> >> Well, yes. >> >> Normally, your SIP-PBX would route calls outside the domain >> to some kind of >> carrier. That is what I want it to do, but I can foresee >> circumstances >> where the PBX sends calls to the ESRP. I would like the ESRP >> to know about >> the PBX (that is, have it's identity in some list it has, one way or >> another, so that when it lowers priority of calls from >> unknown sources, >> those calls are not lowered. I think such arrangements will >> be uncommon, >> but possible. >> >> Brian >> >> >> On 10/29/09 5:28 AM, "Elwell, John" >> >> wrote: >> >>> Brian, >>> >>> Just a question for clarification below: >>> >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>>> On Behalf Of Brian Rosen >>>> Sent: 29 October 2009 03:18 >>>> To: Marc Linsner >>>> Cc: ecrit@ietf.org >>>> Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>> considered >>>> >>>> I'm not worried about security by obscurity. I don't want >>>> phones (or other >>>> devices) built to call directly. >>>> >>>> -phonebcp says "send the call on your normal outbound call >>>> path". That's >>>> what I want it to say, and I don't want it to say "send it >>>> direct, bypass >>>> your service provider. >>> [JRE] So if my normal outbound call path is my SIP-PBX, >> then the SIP-PBX can >>> route directly to the PSAP? >>> >>> John >>> >>> >>>> >>>> I'm not stopping attack, I am stopping abuse. >>>> >>>> I don't want devices that are not subscribed to services to >>>> be able to make >>>> emergency calls (that is, if they can't make "normal" calls, >>>> they should not >>>> be able to make emergency calls). >>>> >>>> Brian >>>> >>>> >>>> On 10/28/09 6:51 PM, "Marc Linsner" wrote: >>>> >>>>> Brian, >>>>> >>>>> What I hear you saying: 'if we don't document how to spoof >>>> a PSAP, then >>>>> nobody will figure it out.' Isn't that a little short sighted? >>>>> >>>>> Joey@miscreant.org will figure out how to establish a SIP >>>> session with any >>>>> PSAP in the world within 10 minutes of that PSAP being >>>> accessible via the >>>>> Internet, regardless of documentation. >>>>> >>>>> I believe there's more harm created in not documenting this for >>>>> John.Q.Public@ordinary_citizen.com. >>>>> >>>>> Granted, nobody here is looking to cause harm to a PSAP. But >>>>> Joey@miscreant.org can certainly expend public safety >>>> resources by reporting >>>>> a bomb threat to a local school. Should we require that >>>> all SIP calls to >>>>> the local school come from a trusted SP? Where does it end? >>>>> >>>>> This isn't the way to deal with spam. >>>>> >>>>> -Marc- >>>>> >>>>> >>>>> >>>>> On 10/27/09 11:00 AM, "Brian Rosen" wrote: >>>>> >>>>>> The first goal is to prevent bad calls. >>>>>> >>>>>> The second goal is to indentify the source of the bad calls. >>>>>> >>>>>> I'm starting with the first goal. I don't want you to be >>>> able to take a >>>>>> device out of a box, plug it into a network, and have the >>>> only call you can >>>>>> make be an emergency call. I want the device to actually >>>> "work" (as in be >>>>>> able to place calls to all the entities that it was >>>> intended to) first, and >>>>>> then be able to place emergency calls. >>>>>> >>>>>> Please spend some time in a PSAP while a kid with a >>>> simless phone has "fun" >>>>>> with it. Imagine how much fun the test mechanism is as >>>> opposed to placing >>>>>> real calls. >>>>>> >>>>>> If we somehow get a bad call, we need to send the cops. >>>> That means we need >>>>>> an identity (and a location). >>>>>> >>>>>> I think a good cert could be the basis of a good identity, >>>> if we could get >>>>>> one. I don't see how we do that. >>>>>> >>>>>> Brian >>>>>> >>>>>> >>>>>> On 10/27/09 10:39 AM, "Richard Barnes" wrote: >>>>>> >>>>>>> Brian, >>>>>>> >>>>>>> Is the security goal here more access control (i.e., >>>> controlling who >>>>>>> can send calls to a PSAP) or attribution/identification >>>> for post-hoc >>>>>>> action. >>>>>>> >>>>>>> If it's the latter, then ISTM that the problem can >>>> largely be reduced >>>>>>> to having a certificate infrastructure that binds authenticated >>>>>>> identities to real-world entities. The "extended validation" >>>>>>> certificates that current commercial CAs issue seem to >>>> largely satisfy >>>>>>> this requirement. >>>>>>> >>>>>>> --Richard >>>>>>> >>>>>>> >>>>>>> On Oct 27, 2009, at 4:31 PM, Brian Rosen wrote: >>>>>>> >>>>>>>> Of course not all VSPs will have trust relationships with all >>>>>>>> PSAPs. One >>>>>>>> can hope that long term, we can evolve to transitive trust >>>>>>>> relationships >>>>>>>> that work pretty well cross border. >>>>>>>> >>>>>>>> The emergency guys are actually terrified of private/individual >>>>>>>> domains >>>>>>>> sending them calls, and we're telling them we expect that to be >>>>>>>> possible, >>>>>>>> but rare, and we're giving them mechanisms that will >> effectively >>>>>>>> allow them >>>>>>>> to turn off calls selectively, based on factors including what >>>>>>>> domain the >>>>>>>> call comes from. They expect that such calls will be >> one of the >>>>>>>> loopholes >>>>>>>> where they get equivalents to sim-less calls, which drive them >>>>>>>> nuts. They >>>>>>>> don't want ANY calls that don't come from service providers, >>>>>>>> although they >>>>>>>> seem to be okay with the notion that the SP may not have great >>>>>>>> identity (AOL >>>>>>>> being a poster child). So, while indeed they >>>> understand, and have >>>>>>>> concerns >>>>>>>> about having to take calls from Sierra Leone VoIP >>>> services Pty, they >>>>>>>> would >>>>>>>> much rather have a call that went through them then a >>>> call that went >>>>>>>> through >>>>>>>> no service provider at all. >>>>>>>> >>>>>>>> I'm not trying to make calls direct from devices or >>>> private domains >>>>>>>> impossible, but I think the notion that we're >> promoting them is a >>>>>>>> very bad >>>>>>>> idea until we have effective mechanisms to prevent abuse. >>>>>>>> >>>>>>>> Brian >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 10/27/09 9:02 AM, "Marc Linsner" wrote: >>>>>>>> >>>>>>>>> Brian, >>>>>>>>> >>>>>>>>> I'm a little confused. I don't remember you objecting to >>>>>>>>> requirement RE1 >>>>>>>>> from RFC5012 and I remember your use case about a >>>> Sierra Leone VSP. >>>>>>>>> >>>>>>>>> Are you implying that *all* VSPs will have a trust >> relationships >>>>>>>>> with *all* >>>>>>>>> PSAPs? >>>>>>>>> >>>>>>>>> What is the difference between a call coming from a private/ >>>>>>>>> individual >>>>>>>>> domain (as in not a commercial VSP) and a VSP on the >>>> other side of >>>>>>>>> the world >>>>>>>>> (outside the jurisdiction)? >>>>>>>>> >>>>>>>>> I'm trying to figure out whether you're objecting to anonymous >>>>>>>>> calls to the >>>>>>>>> PSAP or the mechanisms proposed in this draft? >>>>>>>>> >>>>>>>>> [Don't take this as my endorsement of the draft, as I'm >>>> not sure I >>>>>>>>> agree >>>>>>>>> with UAs registering with the ESRP.] >>>>>>>>> >>>>>>>>> -Marc- >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/26/09 8:59 PM, "Brian Rosen" wrote: >>>>>>>>> >>>>>>>>>> First of all, I put it on the wrong email list, sorry >>>> about that. >>>>>>>>>> >>>>>>>>>> Then, we have carefully arranged it so that there is >>>> no identity >>>>>>>>>> coming from >>>>>>>>>> the access network provider, and because the >> location is coming >>>>>>>>>> from that >>>>>>>>>> provider, we really don't want to. But even if we >>>> did, we would >>>>>>>>>> need a >>>>>>>>>> really good identifier, and there isn't one. >>>>>>>>>> >>>>>>>>>> The problem we have with -direct is anonymous callers, >>>> and if they >>>>>>>>>> have any >>>>>>>>>> option, they would also be location-less. Until and >>>> unless we get >>>>>>>>>> rid of >>>>>>>>>> anonymity, we can't encourage service provider-less >> calls. The >>>>>>>>>> draft does >>>>>>>>>> not make any provision to provide any kind of identity. Many >>>>>>>>>> networks >>>>>>>>>> (think free wifi for example) would make providing >>>> good identity >>>>>>>>>> difficult. >>>>>>>>>> >>>>>>>>>> The fact is that there is a SERVICE provider in nearly >>>> all of the >>>>>>>>>> communications systems. The SERVICE provider is in a >>>> position to >>>>>>>>>> assist >>>>>>>>>> the emergency calling system when it needs more information. >>>>>>>>>> That's what a >>>>>>>>>> good SERVICE provider does. Cutting them out is not a great >>>>>>>>>> idea. Most of >>>>>>>>>> the attempts to provide real time communications >> between people >>>>>>>>>> have evolved >>>>>>>>>> to using service providers, even when there were >>>> alternatives. File >>>>>>>>>> transfer via something like Torrent is a >> counterexample (which >>>>>>>>>> isn't real >>>>>>>>>> time), but even there, you end up with service >>>> providers like The >>>>>>>>>> Pirate Bay >>>>>>>>>> (R.I.P) to provide introduction services. I don't >> think we're >>>>>>>>>> going to see >>>>>>>>>> changes that eliminate service providers, and in this >>>> case, they >>>>>>>>>> provide >>>>>>>>>> value to the emergency calling systems. All of the emergency >>>>>>>>>> professionals >>>>>>>>>> I know have issues with service providers, but they >> would react >>>>>>>>>> with horror >>>>>>>>>> if you suggested cutting them out. Ask them, please. >>>>>>>>>> >>>>>>>>>> So, I claim you have a solution in search of a >>>> problem. We have >>>>>>>>>> solved the >>>>>>>>>> "calling network isn't the access network" problem >>>> already. Service >>>>>>>>>> providers ARE in the path now, in nearly every case >> (in fact a >>>>>>>>>> counter >>>>>>>>>> example escapes me, although there probably are some). >>>> There is >>>>>>>>>> no movement >>>>>>>>>> I can detect which would change that any time soon; quite the >>>>>>>>>> opposite. We >>>>>>>>>> have a known killer problem without some kind of >>>> subscription to a >>>>>>>>>> service >>>>>>>>>> that provides a good identity, for which you provide >>>> no answers. >>>>>>>>>> We have >>>>>>>>>> experience with the killer problem: sim-less calling >>>> was supposed >>>>>>>>>> to provide >>>>>>>>>> a way to make an emergency call in exactly the kinds of >>>>>>>>>> circumstances you >>>>>>>>>> are describing. Our real world experience is that >> you create a >>>>>>>>>> huge problem >>>>>>>>>> that diverts resources from helping people to chasing >>>> scammers and >>>>>>>>>> flea-market sellers. >>>>>>>>>> >>>>>>>>>> Nothing is perfect: you can get a AIM screen name >>>> without a very >>>>>>>>>> good >>>>>>>>>> identity for example. However, the notion that >> we're going to >>>>>>>>>> provide >>>>>>>>>> direct access without a service provider deliberately, >>>> especially >>>>>>>>>> without >>>>>>>>>> really good identity from the access network is, in my >>>> opinion not >>>>>>>>>> only a >>>>>>>>>> no, it's a heck no. I'll line up as many emergency service >>>>>>>>>> professionals as >>>>>>>>>> you would like to tell you this is a harmful idea. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 10/26/09 7:56 PM, "Dawson, Martin" >>>> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> I am glad this has come up. It's a debate that has to >>>> happen if >>>>>>>>>>> we are to >>>>>>>>>>> move >>>>>>>>>>> beyond a long standing legacy misconception. >>>>>>>>>>> >>>>>>>>>>> In the circuit service world - whether it was POTS or >>>> mobile, the >>>>>>>>>>> access >>>>>>>>>>> network had full responsibility for delivering the emergency >>>>>>>>>>> call. In that >>>>>>>>>>> world, routing an emergency call meant getting a circuit >>>>>>>>>>> established to the >>>>>>>>>>> correct call center. In most parts of the world, >> this was done >>>>>>>>>>> using the >>>>>>>>>>> regional part of the PSTN to switch the circuit to a >>>> call center >>>>>>>>>>> on the >>>>>>>>>>> PSTN. >>>>>>>>>>> In some jurisdictions, such as the US, it was done >>>> directly from >>>>>>>>>>> the local >>>>>>>>>>> exchange carrier to the call center. Either way, >> there was no >>>>>>>>>>> third party >>>>>>>>>>> involved. >>>>>>>>>>> >>>>>>>>>>> Now we have the Internet. We still have public >> access network >>>>>>>>>>> providers. >>>>>>>>>>> They >>>>>>>>>>> switch packets onto the Internet for their >>>> subscribers. They can >>>>>>>>>>> similarly >>>>>>>>>>> ensure that packets reach the local emergency call centers. >>>>>>>>>>> >>>>>>>>>>> The fact is that there was no equivalent of a VSP in the >>>>>>>>>>> traditional >>>>>>>>>>> environment. VoIP is a presence service, and it had >> no common >>>>>>>>>>> equivalent in >>>>>>>>>>> the PSTN world. It could have, but the narrowband state of >>>>>>>>>>> technology and >>>>>>>>>>> the >>>>>>>>>>> common market use cases didn't support its >> development. By the >>>>>>>>>>> time ISDN >>>>>>>>>>> arrived, the PSTN had already slipped into its >>>> palliative stage >>>>>>>>>>> without >>>>>>>>>>> realizing it. >>>>>>>>>>> >>>>>>>>>>> It's an entrenched misconception that because the >>>> circuit service >>>>>>>>>>> provided >>>>>>>>>>> by >>>>>>>>>>> exchange carriers was most commonly used for >> "voice" (but, it >>>>>>>>>>> should be >>>>>>>>>>> noted, >>>>>>>>>>> also for fax, telex, tty, security system monitoring >>>> and, even, >>>>>>>>>>> IP data) >>>>>>>>>>> that >>>>>>>>>>> VSPs are somehow equivalent to exchange carriers. >>>> They are not. >>>>>>>>>>> >>>>>>>>>>> Indeed, involving VSPs in emergency calls is the Internet >>>>>>>>>>> equivalent of >>>>>>>>>>> involving long distance providers in POTS emergency >>>> calls. They >>>>>>>>>>> are neither >>>>>>>>>>> necessary nor particularly helpful; they can't be >>>> guaranteed to >>>>>>>>>>> be within >>>>>>>>>>> the >>>>>>>>>>> emergency jurisdiction; depending on them actually >>>> diminishes the >>>>>>>>>>> efficacy >>>>>>>>>>> of >>>>>>>>>>> emergency service access. It does not help the caller, the >>>>>>>>>>> emergency >>>>>>>>>>> service, >>>>>>>>>>> nor the third party to insist on the third party's >>>> involvement. >>>>>>>>>>> >>>>>>>>>>> It can't be helped if you have over sold the benefits of VSP >>>>>>>>>>> involvement to >>>>>>>>>>> yourself and others Brian. It is time to have a >>>> reasoned debate. >>>>>>>>>>> From my >>>>>>>>>>> perspective, the argument that there is no "subscription" >>>>>>>>>>> involved is >>>>>>>>>>> patently >>>>>>>>>>> false. There has to be a subscription of some description in >>>>>>>>>>> order to get to >>>>>>>>>>> the Internet. Yes, there is free public Internet >>>> access (just as >>>>>>>>>>> there are >>>>>>>>>>> free courtesy phones on the PSTN and free access to >> emergency >>>>>>>>>>> services from >>>>>>>>>>> pay phones. All these services are still connected to >>>> the public >>>>>>>>>>> Internet >>>>>>>>>>> infrastructure and they all represent an "operator" >> with some >>>>>>>>>>> level of >>>>>>>>>>> information about the caller. >>>>>>>>>>> >>>>>>>>>>> With the over-emphasis on VSPs, what is missing >> from the ECRIT >>>>>>>>>>> and i3 models >>>>>>>>>>> is the direct interface for querying the access network for >>>>>>>>>>> subscriber data >>>>>>>>>>> (should it prove necessary). These models need to >>>> take the long >>>>>>>>>>> view of how >>>>>>>>>>> emergency calling is done in the Internet age; they >>>> should not be >>>>>>>>>>> protracting >>>>>>>>>>> an unnecessary reliance on VSPs. >>>>>>>>>>> >>>>>>>>>>> I have deleted the premature and prejudicial text from the >>>>>>>>>>> subject heading. >>>>>>>>>>> And I'll leave this on ECRIT as the most appropriate WG. >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Martin >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: ecrit-bounces@ietf.org >>>> [mailto:ecrit-bounces@ietf.org] On >>>>>>>>>>> Behalf Of >>>>>>>>>>> Hannes Tschofenig >>>>>>>>>>> Sent: Tuesday, 27 October 2009 8:23 AM >>>>>>>>>>> To: ecrit@ietf.org >>>>>>>>>>> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>>>>>>>>> considered harmful, >>>>>>>>>>> at least given our current experiences >>>>>>>>>>> >>>>>>>>>>> FYI: feedback from Brian regarding a recent ECRIT >>>> contribution. >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: geopriv-bounces@ietf.org >>>>>>>>>>>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian >>>>>>>>>>>> Sent: 26 October, 2009 23:10 >>>>>>>>>>>> To: geopriv@ietf.org >>>>>>>>>>>> Subject: [Geopriv] Winterbottom-ecrit-direct considered >>>>>>>>>>>> harmful, at least given our current experiences >>>>>>>>>>>> >>>>>>>>>>>> The notion behind -direct is to not use a service >> provider to >>>>>>>>>>>> place an emergency call. Instead, the device >> registers with >>>>>>>>>>>> an Emergency Services Routing Proxy immediately before the >>>>>>>>>>>> call and the call is routed directly from the device >>>> to the ESRP. >>>>>>>>>>>> >>>>>>>>>>>> At least at the moment, this is an exceedingly bad idea. >>>>>>>>>>>> >>>>>>>>>>>> Emergency calling authorities like service >> providers, a lot. >>>>>>>>>>>> They like them because they can hold them >>>> accountable, and the >>>>>>>>>>>> service providers don't like theft of service, which is >>>>>>>>>>>> something the emergency call guys have an analog to. >>>>>>>>>>>> >>>>>>>>>>>> The facts are that where unaccountable access to emergency >>>>>>>>>>>> calling is allowed, huge numbers of false calls >>>> occur, with no >>>>>>>>>>>> way to stop them, and no way to tell the good ones from the >>>>>>>>>>>> bad ones. This has been seen multiple times where >> so called >>>>>>>>>>>> "simless" or "unauthenticated" calls are allowed. >>>>>>>>>>>> >>>>>>>>>>>> -direct precisely duplicates simless calling. The only >>>>>>>>>>>> "registration" is an emergency registration, only emergency >>>>>>>>>>>> calls are allowed, any device can make an emergency call if >>>>>>>>>>>> all it has is a (radio) connection to any network. >>>>>>>>>>>> We can predict, with a very high degree of >>>> certainty, that the >>>>>>>>>>>> feature will be horribly abused: for example to test that a >>>>>>>>>>>> phone without a service plan works. >>>>>>>>>>>> >>>>>>>>>>>> There have been studies which show tens of thousands of bad >>>>>>>>>>>> calls with zero good ones. Nearly every authority I know >>>>>>>>>>>> where the regulator has insisted on simless >> calling wants it >>>>>>>>>>>> repealed. There is one counter example I know >> where the fact >>>>>>>>>>>> that they got a couple, literally, of good calls among the >>>>>>>>>>>> tens of thousands of bad calls was considered enough >>>> reason to >>>>>>>>>>>> put up with the problem. >>>>>>>>>>>> >>>>>>>>>>>> Service providers give us information that may be useful: a >>>>>>>>>>>> subscriber name and address for example, which is not >>>>>>>>>>>> spoofable by the caller. They have ways to trace callers, >>>>>>>>>>>> especially bad callers. They don't want their >> systems abused >>>>>>>>>>>> any more than the emergency calling authorities do. >>>>>>>>>>>> >>>>>>>>>>>> This is a bad idea. A very bad idea. Please stop it. >>>>>>>>>>>> >>>>>>>>>>>> Someday, we may have better ways to prevent abuse. Until we >>>>>>>>>>>> do, service providers are a good thing on an >> emergency call. >>>>>>>>>>>> We don't want them cut out. >>>>>>>>>>>> >>>>>>>>>>>> Brian >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Geopriv mailing list >>>>>>>>>>>> Geopriv@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 mlinsner@cisco.com Fri Oct 30 10:46:09 2009 Return-Path: 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 87E333A694F for ; Fri, 30 Oct 2009 10:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.28 X-Spam-Level: X-Spam-Status: No, score=-6.28 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] 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 4wllNyYIOKE5 for ; Fri, 30 Oct 2009 10:46:06 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 226433A691F for ; Fri, 30 Oct 2009 10:46:06 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAK/D6kpAZnwM/2dsb2JhbADJIJgxgjkGgX4EgmuJFQ X-IronPort-AV: E=Sophos;i="4.44,655,1249257600"; d="scan'208";a="65747598" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 30 Oct 2009 17:46:21 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9UHkLhc000677; Fri, 30 Oct 2009 17:46:21 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 13:46:21 -0400 Received: from [10.116.195.121] ([10.116.195.121]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 13:46:19 -0400 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Fri, 30 Oct 2009 13:46:16 -0400 From: Marc Linsner To: Brian Rosen Message-ID: Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4AE1y5CAAGs5+wAAX4z4UAAdMnZQACY9dzAAJ55ZEAIY7SzwAIVkuo In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 30 Oct 2009 17:46:19.0530 (UTC) FILETIME=[E32D46A0:01CA5988] Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Fri, 30 Oct 2009 17:46:09 -0000 Brian, "Normal Call Path" was NOT added to phonebcp for the purpose of the perceived security you describe. The advantage (and the reason it's in phonebcp) to using the normal call path is due to it being the most likely mechanism to work. Unused/untested mechanisms are more likely to fail when tried for the first time verses mechanisms that are used/tested daily. Emergency time is not the time to test a new mechanism, hence use the normal call path, the same one you just used to call grandma, to summons emergency assistance. (This is a negative against this proposed mechanism.) If you are evangelizing within the PS community that 'sip:johnny@att.com' is less of a threat than 'sip:johnny@vanitydomain.com', I suggest that is the wrong message to be spreading. Please stop now. This will only lead to the thousands of personal injury lawyers making big $$ at the expense of the PS community. As you are intimately aware, there are millions of 'vanity' domains in use and it's growing. Its growing not just in the individual market, but in the small/medium business market. You also know there are thousands of hosting companies providing services to the owners of vanity domains (email, web, ftp, etc.). I expect in the near future that hosting providers will add sip proxy services to their list of wares. My guess would be that PS officials would like to treat their customer known as -'sip:johnny@vanitydomain.com' the same as their customer known as -'sip:johnny@att.com'. The domain name does not dictate the level of urgency in the request for emergency assistance, nor the veracity of the caller. When an overload of the ESInet exists, I would suggest to look for other parameters to use in decision process of how to populate the various queues. - Are the calls from all the same location? - Is it reasonable that the IP address/network can be at the reported location? - How many calls have we received over a period of time from this AOR? IP address/network? Location? Simply using the domain/AOR as the black and white rule, as you suggest, will lead to big problems. Just my opinion, -Marc- On 10/30/09 9:47 AM, "Brian Rosen" wrote: > I want it to say MUST NOT use that mechanism :) > > I don't want alternative ways to make emergency calls. I want what phonebcp > already says: send the call on the normal path and a normal identity and > callback (which implies using a normal registration). > > I understand that the local authority can disable the ESRP registration > mechanism. If this draft goes forward against my advice, then I will ask > that there be text that says if the registration cannot be completed, the > device MUST NOT send emergency calls direct to that ESRP, and must use its > normal call path for emergency calls. > > We can't stop calls from entering the emergency services IP network without > passing through a service provider. I have no wish to add any mechanism > which would attempt to do so. If it would help, I would be happy to beef > up language in framework that discusses this problem and what "normal call > path" means. I would even be very happy to add a item to phonebcp that says > "if you can't make normal calls, you can't make emergency calls", although > we might get hung up on defining "normal", because if at some time when you > need help the only number that could actually answer your call, sent down > the same call path as you would normally send any call, is the emergency > service, then we want that call. > > We frequently use you as an example. If you have a SIP Registrar and proxy > server in your home (or boat) and you have a phone that registers with it, > and you normally make calls to your family and friends with that setup, then > I suspect that there is some service provider helping your proxy server > connect to your family and friends. We would prefer your emergency calls go > through that service provider. However, if for some reason, your proxy > server forwarded an emergency call direct to the ESInet, it will normally go > through. > > Unfortunately for you, if someone decides to attack the emergency call > system, and it gets overloaded for some period of time until we can mitigate > the attack, we may have to make choices on which calls we answer and which > ones we don't. Your call sent through your proxy server to the ESInet > direct may get lower priority than the same call sent through the service > provider, if we notice that most of the attack calls are coming direct from > the Internet, rather than going through a service provider we know about. > We're building in explicit attack mitigation strategies like that. It's not > unreasonable: if you have 5 sources entering your network, and one of them > is the place where all (or most) of the attack is coming from, you shut off > that source until you have a better filter. > > If a whole lot of devices assume the direct path is the preferred path, that > would be bad for them. > > Furthermore, there is additional data sent to the emergency system (in the > U.S.) with the call from the service provider. That information may be > useful in helping you. The device can actually send the information, but > while while we are pretty sure we can get most service providers to give it > to us, we are pessimistic most devices will. Devices that have sensors, > where the sensor data is useful for emergency calls may very well do it. > Medical monitoring devices for example. NENA will be asking the IETF to > standardize this soon, so that all service providers anywhere could provide > it to all emergency services. It has things like subscriber (as opposed to > caller) contact data, class of service information, SP contact data, etc. > When things go wrong, the PSAP will often contact the SP and get help. The > SP often has tools and mechanisms that CAN help. > > Brian > > > On 10/29/09 5:46 PM, "Marc Linsner" wrote: > >> Brian, >> >> I didn't read anything in the draft that stated devices 'should' use this >> mechanism (if it's there, it needs removed). I read it more as a device >> 'could' use this mechanism (as in an alternative to other mechanisms). >> >> Further, since the ESRP is controlled by the PSAP, it certainly would be a >> PSAP policy decision whether to support this mechanism. As without the ESRP >> support of unknown UA registrations, the mechanism doesn't work. >> >> BTW, the term 'unregistered' is not in phonebcp. I think your are >> stretching the 'normal call path' to include registration with something(?). >> I find nothing in phonebcp that disallows 'direct' calls to an ESRP. If I >> contact an ESRP from my UA 'directly', as long as the PSAP can call-back >> using the Contact header I sent in the invite and my AOR leads back to my >> UA, I've satisfied phonebcp. >> >> What am I missing? >> >> -Marc- >> >> >> On 10/29/09 4:35 PM, "Brian Rosen" wrote: >> >>> The IETF writing standards that describe how devices should bypass their >>> service provider and place emergency calls direct is not a PSAP policy >>> issue. >>> >>> I'm satisfied with the current -phonebcp dictum to send calls on the normal >>> call path. For an "unregistered" device, that will not allow any "calls" >>> including emergency calls. >>> >>> I discussed this draft on the NENA LTD meeting this morning. That may >>> generate some list discussion from some PSAP people who are subscribed. I >>> would also like to hear from more PSAP folks on this subject. >>> >>> Brian >>> >>> >>> On 10/29/09 3:27 PM, "Marc Linsner" wrote: >>> >>>> These are all PSAP policy decisions. Just as it's a PSAP policy decision >>>> to >>>> support the suggested mechanism in the draft. Existence of the document >>>> describing the mechanism doesn't force PSAP policy. >>>> >>>> I personally would like to see some PSAPs and/or PS jurisdictions line up >>>> behind the draft before it proceeds, but I don't see any harm in it going >>>> forward. >>>> >>>> Of course, I'm dreaming about this special place where a PSAP actually >>>> wants >>>> to enable communication with all their customers and not force them to be a >>>> member of a special club. >>>> >>>> [non-chair hat on] >>>> >>>> -Marc- >>>> >>>> >>>> On 10/29/09 2:35 PM, "Brian Rosen" wrote: >>>> >>>>> Thank you. That is what I meant, and you said it better than I was going >>>>> to. >>>>> >>>>> We may also have some transitive relationships: that is, if there is a >>>>> "local" PSAP that trusts that they have done so, other PSAPs may trust >>>>> that >>>>> they have done so. >>>>> >>>>> Brian >>>>> >>>>> On 10/29/09 11:48 AM, "DRAGE, Keith (Keith)" >>>>> wrote: >>>>> >>>>>> I suspect that what Brian is saying is that anyone can be a service >>>>>> provider >>>>>> (or whatever else you want to call it) in this case provided that: >>>>>> >>>>>> 1) they make that agreement with the PSAP providers they route calls >>>>>> to; >>>>>> >>>>>> 2) they authenticate the calls requests to a level of security that >>>>>> meets >>>>>> the PSAPs (and any legal) requirements; >>>>>> >>>>>> 3) the PSAP trusts that they have done so. >>>>>> >>>>>> While this would normally be what we would understand as public >>>>>> telecommuncation operators, it doesn't mean they have to be. >>>>>> >>>>>> regards >>>>>> >>>>>> Keith >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>>>>>> On Behalf Of Marc Linsner >>>>>>> Sent: Thursday, October 29, 2009 12:32 PM >>>>>>> To: Brian Rosen >>>>>>> Cc: ecrit@ietf.org >>>>>>> Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>>>>> considered >>>>>>> >>>>>>> Brian, >>>>>>> >>>>>>> Please define what you consider to be a service provider. >>>>>>> >>>>>>> Is Skype a service? >>>>>>> Is Jabber a service? >>>>>>> Is Google Voice a service? >>>>>>> Is mydomain.com hosted on a commercial site a service? >>>>>>> Is mydomain.com hosted on a home server a service? >>>>>>> Is myEnterpriseVoIP.com a service? >>>>>>> >>>>>>> So, what you are saying that if I can make calls via all of >>>>>>> the above, it's OK for all of the above to contact an ESRP? >>>>>>> >>>>>>> Are you requiring that I have a full-time proxy on-line for >>>>>>> mydomain.com or can I simply run a transient UA and dynamic DNS? >>>>>>> >>>>>>> -Marc- >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 10/28/09 11:17 PM, "Brian Rosen" wrote: >>>>>>> >>>>>>>> I'm not worried about security by obscurity. I don't want >>>>>>> phones (or >>>>>>>> other >>>>>>>> devices) built to call directly. >>>>>>>> >>>>>>>> -phonebcp says "send the call on your normal outbound call path". >>>>>>>> That's what I want it to say, and I don't want it to say "send it >>>>>>>> direct, bypass your service provider. >>>>>>>> >>>>>>>> I'm not stopping attack, I am stopping abuse. >>>>>>>> >>>>>>>> I don't want devices that are not subscribed to services to >>>>>>> be able to >>>>>>>> make emergency calls (that is, if they can't make "normal" >>>>>>> calls, they >>>>>>>> should not be able to make emergency calls). >>>>>>>> >>>>>>>> Brian >>>>>>>> >>>>>>>> >>>>>>>> On 10/28/09 6:51 PM, "Marc Linsner" wrote: >>>>>>>> >>>>>>>>> Brian, >>>>>>>>> >>>>>>>>> What I hear you saying: 'if we don't document how to spoof a PSAP, >>>>>>>>> then nobody will figure it out.' Isn't that a little >>>>>>> short sighted? >>>>>>>>> >>>>>>>>> Joey@miscreant.org will figure out how to establish a SIP session >>>>>>>>> with any PSAP in the world within 10 minutes of that PSAP being >>>>>>>>> accessible via the Internet, regardless of documentation. >>>>>>>>> >>>>>>>>> I believe there's more harm created in not documenting this for >>>>>>>>> John.Q.Public@ordinary_citizen.com. >>>>>>>>> >>>>>>>>> Granted, nobody here is looking to cause harm to a PSAP. But >>>>>>>>> Joey@miscreant.org can certainly expend public safety resources by >>>>>>>>> reporting a bomb threat to a local school. Should we require that >>>>>>>>> all SIP calls to the local school come from a trusted SP? >>>>>>> Where does it end? >>>>>>>>> >>>>>>>>> This isn't the way to deal with spam. >>>>>>>>> >>>>>>>>> -Marc- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/27/09 11:00 AM, "Brian Rosen" wrote: >>>>>>>>> >>>>>>>>>> The first goal is to prevent bad calls. >>>>>>>>>> >>>>>>>>>> The second goal is to indentify the source of the bad calls. >>>>>>>>>> >>>>>>>>>> I'm starting with the first goal. I don't want you to be able to >>>>>>>>>> take a device out of a box, plug it into a network, and have the >>>>>>>>>> only call you can make be an emergency call. I want the >>>>>>> device to >>>>>>>>>> actually "work" (as in be able to place calls to all the entities >>>>>>>>>> that it was intended to) first, and then be able to place >>>>>>> emergency calls. >>>>>>>>>> >>>>>>>>>> Please spend some time in a PSAP while a kid with a >>>>>>> simless phone has "fun" >>>>>>>>>> with it. Imagine how much fun the test mechanism is as >>>>>>> opposed to >>>>>>>>>> placing real calls. >>>>>>>>>> >>>>>>>>>> If we somehow get a bad call, we need to send the cops. >>>>>>> That means >>>>>>>>>> we need an identity (and a location). >>>>>>>>>> >>>>>>>>>> I think a good cert could be the basis of a good identity, if we >>>>>>>>>> could get one. I don't see how we do that. >>>>>>>>>> >>>>>>>>>> Brian >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 10/27/09 10:39 AM, "Richard Barnes" wrote: >>>>>>>>>> >>>>>>>>>>> Brian, >>>>>>>>>>> >>>>>>>>>>> Is the security goal here more access control (i.e., controlling >>>>>>>>>>> who can send calls to a PSAP) or attribution/identification for >>>>>>>>>>> post-hoc action. >>>>>>>>>>> >>>>>>>>>>> If it's the latter, then ISTM that the problem can largely be >>>>>>>>>>> reduced to having a certificate infrastructure that binds >>>>>>>>>>> authenticated identities to real-world entities. The >>>>>>> "extended validation" >>>>>>>>>>> certificates that current commercial CAs issue seem to largely >>>>>>>>>>> satisfy this requirement. >>>>>>>>>>> >>>>>>>>>>> --Richard >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Oct 27, 2009, at 4:31 PM, Brian Rosen wrote: >>>>>>>>>>> >>>>>>>>>>>> Of course not all VSPs will have trust relationships with all >>>>>>>>>>>> PSAPs. One can hope that long term, we can evolve to >>>>>>> transitive >>>>>>>>>>>> trust relationships that work pretty well cross border. >>>>>>>>>>>> >>>>>>>>>>>> The emergency guys are actually terrified of private/individual >>>>>>>>>>>> domains sending them calls, and we're telling them we >>>>>>> expect that >>>>>>>>>>>> to be possible, but rare, and we're giving them mechanisms that >>>>>>>>>>>> will effectively allow them to turn off calls >>>>>>> selectively, based >>>>>>>>>>>> on factors including what domain the call comes from. >>>>>>> They expect >>>>>>>>>>>> that such calls will be one of the loopholes where they get >>>>>>>>>>>> equivalents to sim-less calls, which drive them nuts. >>>>>>> They don't >>>>>>>>>>>> want ANY calls that don't come from service providers, although >>>>>>>>>>>> they seem to be okay with the notion that the SP may not have >>>>>>>>>>>> great identity (AOL being a poster child). So, while >>>>>>> indeed they >>>>>>>>>>>> understand, and have concerns about having to take calls from >>>>>>>>>>>> Sierra Leone VoIP services Pty, they would much rather >>>>>>> have a call >>>>>>>>>>>> that went through them then a call that went through no service >>>>>>>>>>>> provider at all. >>>>>>>>>>>> >>>>>>>>>>>> I'm not trying to make calls direct from devices or private >>>>>>>>>>>> domains impossible, but I think the notion that we're promoting >>>>>>>>>>>> them is a very bad idea until we have effective mechanisms to >>>>>>>>>>>> prevent abuse. >>>>>>>>>>>> >>>>>>>>>>>> Brian >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/27/09 9:02 AM, "Marc Linsner" wrote: >>>>>>>>>>>> >>>>>>>>>>>> Brian, >>>>>>>>>>>> >>>>>>>>>>>> I'm a little confused. I don't remember you objecting to >>>>>>>>>>>> requirement RE1 from RFC5012 and I remember your use >>>>>>> case about a >>>>>>>>>>>> Sierra Leone VSP. >>>>>>>>>>>> >>>>>>>>>>>> Are you implying that *all* VSPs will have a trust >>>>>>> relationships >>>>>>>>>>>> with *all* PSAPs? >>>>>>>>>>>> >>>>>>>>>>>> What is the difference between a call coming from a private/ >>>>>>>>>>>> individual domain (as in not a commercial VSP) and a >>>>>>> VSP on the >>>>>>>>>>>> other side of the world (outside the jurisdiction)? >>>>>>>>>>>> >>>>>>>>>>>> I'm trying to figure out whether you're objecting to anonymous >>>>>>>>>>>> calls to the PSAP or the mechanisms proposed in this draft? >>>>>>>>>>>> >>>>>>>>>>>> [Don't take this as my endorsement of the draft, as >>>>>>> I'm not sure >>>>>>>>>>>> I agree with UAs registering with the ESRP.] >>>>>>>>>>>> >>>>>>>>>>>> -Marc- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/26/09 8:59 PM, "Brian Rosen" wrote: >>>>>>>>>>>> >>>>>>>>>>>> First of all, I put it on the wrong email list, sorry >>>>>>> about that. >>>>>>>>>>>> >>>>>>>>>>>> Then, we have carefully arranged it so that there is >>>>>>> no identity >>>>>>>>>>>> coming from the access network provider, and because the >>>>>>>>>>>> location is coming from that provider, we really >>>>>>> don't want to. >>>>>>>>>>>> But even if we did, we would need a really good >>>>>>> identifier, and >>>>>>>>>>>> there isn't one. >>>>>>>>>>>> >>>>>>>>>>>> The problem we have with -direct is anonymous callers, and if >>>>>>>>>>>> they have any option, they would also be >>>>>>> location-less. Until >>>>>>>>>>>> and unless we get rid of anonymity, we can't >>>>>>> encourage service >>>>>>>>>>>> provider-less calls. The draft does not make any >>>>>>> provision to >>>>>>>>>>>> provide any kind of identity. Many networks (think free wifi >>>>>>>>>>>> for example) would make providing good identity difficult. >>>>>>>>>>>> >>>>>>>>>>>> The fact is that there is a SERVICE provider in >>>>>>> nearly all of the >>>>>>>>>>>> communications systems. The SERVICE provider is in >>>>>>> a position to >>>>>>>>>>>> assist >>>>>>>>>>>> the emergency calling system when it needs more information. >>>>>>>>>>>> That's what a >>>>>>>>>>>> good SERVICE provider does. Cutting them out is not a great >>>>>>>>>>>> idea. Most of the attempts to provide real time >>>>>>> communications >>>>>>>>>>>> between people have evolved to using service providers, even >>>>>>>>>>>> when there were alternatives. File transfer via >>>>>>> something like >>>>>>>>>>>> Torrent is a counterexample (which isn't real time), but even >>>>>>>>>>>> there, you end up with service providers like The Pirate Bay >>>>>>>>>>>> (R.I.P) to provide introduction services. I don't >>>>>>> think we're >>>>>>>>>>>> going to see changes that eliminate service providers, and in >>>>>>>>>>>> this case, they provide value to the emergency >>>>>>> calling systems. >>>>>>>>>>>> All of the emergency professionals I know have issues with >>>>>>>>>>>> service providers, but they would react with horror if you >>>>>>>>>>>> suggested cutting them out. Ask them, please. >>>>>>>>>>>> >>>>>>>>>>>> So, I claim you have a solution in search of a >>>>>>> problem. We have >>>>>>>>>>>> solved the "calling network isn't the access network" problem >>>>>>>>>>>> already. Service providers ARE in the path now, in >>>>>>> nearly every >>>>>>>>>>>> case (in fact a counter example escapes me, although there >>>>>>>>>>>> probably are some). There is no movement I can detect which >>>>>>>>>>>> would change that any time soon; quite the opposite. >>>>>>> We have a >>>>>>>>>>>> known killer problem without some kind of subscription to a >>>>>>>>>>>> service that provides a good identity, for which you >>>>>>> provide no >>>>>>>>>>>> answers. >>>>>>>>>>>> We have >>>>>>>>>>>> experience with the killer problem: sim-less calling was >>>>>>>>>>>> supposed to provide a way to make an emergency call >>>>>>> in exactly >>>>>>>>>>>> the kinds of circumstances you are describing. Our >>>>>>> real world >>>>>>>>>>>> experience is that you create a huge problem that diverts >>>>>>>>>>>> resources from helping people to chasing scammers and >>>>>>>>>>>> flea-market sellers. >>>>>>>>>>>> >>>>>>>>>>>> Nothing is perfect: you can get a AIM screen name >>>>>>> without a very >>>>>>>>>>>> good identity for example. However, the notion that >>>>>>> we're going >>>>>>>>>>>> to provide direct access without a service provider >>>>>>>>>>>> deliberately, especially without really good identity >>>>>>> from the >>>>>>>>>>>> access network is, in my opinion not only a no, it's >>>>>>> a heck no. >>>>>>>>>>>> I'll line up as many emergency service professionals as you >>>>>>>>>>>> would like to tell you this is a harmful idea. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/26/09 7:56 PM, "Dawson, Martin" >>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> I am glad this has come up. It's a debate that has >>>>>>> to happen if >>>>>>>>>>>> we are to move beyond a long standing legacy misconception. >>>>>>>>>>>> >>>>>>>>>>>> In the circuit service world - whether it was POTS >>>>>>> or mobile, >>>>>>>>>>>> the access network had full responsibility for >>>>>>> delivering the >>>>>>>>>>>> emergency call. In that world, routing an emergency >>>>>>> call meant >>>>>>>>>>>> getting a circuit established to the correct call center. In >>>>>>>>>>>> most parts of the world, this was done using the >>>>>>> regional part >>>>>>>>>>>> of the PSTN to switch the circuit to a call center >>>>>>> on the PSTN. >>>>>>>>>>>> In some jurisdictions, such as the US, it was done directly >>>>>>>>>>>> from the local exchange carrier to the call center. >>>>>>> Either way, >>>>>>>>>>>> there was no third party involved. >>>>>>>>>>>> >>>>>>>>>>>> Now we have the Internet. We still have public >>>>>>> access network >>>>>>>>>>>> providers. >>>>>>>>>>>> They >>>>>>>>>>>> switch packets onto the Internet for their subscribers. They >>>>>>>>>>>> can similarly ensure that packets reach the local emergency >>>>>>>>>>>> call centers. >>>>>>>>>>>> >>>>>>>>>>>> The fact is that there was no equivalent of a VSP in the >>>>>>>>>>>> traditional environment. VoIP is a presence service, >>>>>>> and it had >>>>>>>>>>>> no common equivalent in the PSTN world. It could >>>>>>> have, but the >>>>>>>>>>>> narrowband state of technology and the common market >>>>>>> use cases >>>>>>>>>>>> didn't support its development. By the time ISDN >>>>>>> arrived, the >>>>>>>>>>>> PSTN had already slipped into its palliative stage without >>>>>>>>>>>> realizing it. >>>>>>>>>>>> >>>>>>>>>>>> It's an entrenched misconception that because the circuit >>>>>>>>>>>> service provided by exchange carriers was most commonly used >>>>>>>>>>>> for "voice" (but, it should be noted, also for fax, >>>>>>> telex, tty, >>>>>>>>>>>> security system monitoring and, even, IP data) that VSPs are >>>>>>>>>>>> somehow equivalent to exchange carriers. They are not. >>>>>>>>>>>> >>>>>>>>>>>> Indeed, involving VSPs in emergency calls is the Internet >>>>>>>>>>>> equivalent of involving long distance providers in POTS >>>>>>>>>>>> emergency calls. They are neither necessary nor particularly >>>>>>>>>>>> helpful; they can't be guaranteed to be within the emergency >>>>>>>>>>>> jurisdiction; depending on them actually diminishes the >>>>>>>>>>>> efficacy of emergency service access. It does not help the >>>>>>>>>>>> caller, the emergency service, nor the third party >>>>>>> to insist on >>>>>>>>>>>> the third party's involvement. >>>>>>>>>>>> >>>>>>>>>>>> It can't be helped if you have over sold the benefits of VSP >>>>>>>>>>>> involvement to yourself and others Brian. It is time >>>>>>> to have a >>>>>>>>>>>> reasoned debate. >>>>>>>>>>>> From my >>>>>>>>>>>> perspective, the argument that there is no "subscription" >>>>>>>>>>>> involved is >>>>>>>>>>>> patently >>>>>>>>>>>> false. There has to be a subscription of some description in >>>>>>>>>>>> order to get to the Internet. Yes, there is free public >>>>>>>>>>>> Internet access (just as there are free courtesy >>>>>>> phones on the >>>>>>>>>>>> PSTN and free access to emergency services from pay >>>>>>> phones. All >>>>>>>>>>>> these services are still connected to the public Internet >>>>>>>>>>>> infrastructure and they all represent an "operator" >>>>>>> with some >>>>>>>>>>>> level of information about the caller. >>>>>>>>>>>> >>>>>>>>>>>> With the over-emphasis on VSPs, what is missing from >>>>>>> the ECRIT >>>>>>>>>>>> and i3 models is the direct interface for querying >>>>>>> the access >>>>>>>>>>>> network for subscriber data (should it prove >>>>>>> necessary). These >>>>>>>>>>>> models need to take the long view of how emergency >>>>>>> calling is >>>>>>>>>>>> done in the Internet age; they should not be protracting an >>>>>>>>>>>> unnecessary reliance on VSPs. >>>>>>>>>>>> >>>>>>>>>>>> I have deleted the premature and prejudicial text from the >>>>>>>>>>>> subject heading. >>>>>>>>>>>> And I'll leave this on ECRIT as the most appropriate WG. >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> Martin >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: ecrit-bounces@ietf.org >>>>>>> [mailto:ecrit-bounces@ietf.org] On >>>>>>>>>>>> Behalf Of Hannes Tschofenig >>>>>>>>>>>> Sent: Tuesday, 27 October 2009 8:23 AM >>>>>>>>>>>> To: ecrit@ietf.org >>>>>>>>>>>> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>>>>>>>>>> considered harmful, at least given our current experiences >>>>>>>>>>>> >>>>>>>>>>>> FYI: feedback from Brian regarding a recent ECRIT >>>>>>> contribution. >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: geopriv-bounces@ietf.org >>>>>>>>>>>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian >>>>>>>>>>>> Sent: 26 October, 2009 23:10 >>>>>>>>>>>> To: geopriv@ietf.org >>>>>>>>>>>> Subject: [Geopriv] Winterbottom-ecrit-direct considered >>>>>>>>>>>> harmful, at least given our current experiences >>>>>>>>>>>> >>>>>>>>>>>> The notion behind -direct is to not use a service >>>>>>> provider to >>>>>>>>>>>> place an emergency call. Instead, the device >>>>>>> registers with >>>>>>>>>>>> an Emergency Services Routing Proxy immediately before the >>>>>>>>>>>> call and the call is routed directly from the >>>>>>> device to the ESRP. >>>>>>>>>>>> >>>>>>>>>>>> At least at the moment, this is an exceedingly bad idea. >>>>>>>>>>>> >>>>>>>>>>>> Emergency calling authorities like service providers, a lot. >>>>>>>>>>>> They like them because they can hold them >>>>>>> accountable, and the >>>>>>>>>>>> service providers don't like theft of service, which is >>>>>>>>>>>> something the emergency call guys have an analog to. >>>>>>>>>>>> >>>>>>>>>>>> The facts are that where unaccountable access to emergency >>>>>>>>>>>> calling is allowed, huge numbers of false calls >>>>>>> occur, with no >>>>>>>>>>>> way to stop them, and no way to tell the good ones from the >>>>>>>>>>>> bad ones. This has been seen multiple times where >>>>>>> so called >>>>>>>>>>>> "simless" or "unauthenticated" calls are allowed. >>>>>>>>>>>> >>>>>>>>>>>> -direct precisely duplicates simless calling. The only >>>>>>>>>>>> "registration" is an emergency registration, only emergency >>>>>>>>>>>> calls are allowed, any device can make an emergency call if >>>>>>>>>>>> all it has is a (radio) connection to any network. >>>>>>>>>>>> We can predict, with a very high degree of >>>>>>> certainty, that the >>>>>>>>>>>> feature will be horribly abused: for example to test that a >>>>>>>>>>>> phone without a service plan works. >>>>>>>>>>>> >>>>>>>>>>>> There have been studies which show tens of thousands of bad >>>>>>>>>>>> calls with zero good ones. Nearly every authority I know >>>>>>>>>>>> where the regulator has insisted on simless calling >>>>>>> wants it >>>>>>>>>>>> repealed. There is one counter example I know >>>>>>> where the fact >>>>>>>>>>>> that they got a couple, literally, of good calls among the >>>>>>>>>>>> tens of thousands of bad calls was considered >>>>>>> enough reason to >>>>>>>>>>>> put up with the problem. >>>>>>>>>>>> >>>>>>>>>>>> Service providers give us information that may be useful: a >>>>>>>>>>>> subscriber name and address for example, which is not >>>>>>>>>>>> spoofable by the caller. They have ways to trace callers, >>>>>>>>>>>> especially bad callers. They don't want their >>>>>>> systems abused >>>>>>>>>>>> any more than the emergency calling authorities do. >>>>>>>>>>>> >>>>>>>>>>>> This is a bad idea. A very bad idea. Please stop it. >>>>>>>>>>>> >>>>>>>>>>>> Someday, we may have better ways to prevent abuse. Until we >>>>>>>>>>>> do, service providers are a good thing on an emergency call. >>>>>>>>>>>> We don't want them cut out. >>>>>>>>>>>> >>>>>>>>>>>> Brian >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Geopriv mailing list >>>>>>>>>>>> Geopriv@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 br@brianrosen.net Fri Oct 30 11:29:28 2009 Return-Path: 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 996C83A68DD for ; Fri, 30 Oct 2009 11:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] 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 EZGTxnpxTnej for ; Fri, 30 Oct 2009 11:29:26 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id A6CDC3A68D1 for ; Fri, 30 Oct 2009 11:29:25 -0700 (PDT) Received: from [209.173.57.233] (helo=[192.168.130.13]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1N3wE2-0006vU-CE; Fri, 30 Oct 2009 13:29:33 -0500 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Fri, 30 Oct 2009 14:29:29 -0400 From: Brian Rosen To: Marc Linsner Message-ID: Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4AE1y5CAAGs5+wAAX4z4UAAdMnZQACY9dzAAJ55ZEAIY7SzwAIVkuoAAGCY3E= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Fri, 30 Oct 2009 18:29:28 -0000 I'm the messenger here. PSAPs prefer service providers to be on the path of a call, and they have bad experiences when they aren't. Given their experiences, I can't fault them. The reason the text is in phonebcp is as you said it is: because "normal" is likely to work. The fact that "normal" means SP path in 99.999% of cases gets the PSAPs what they want. They don't care about why we did it, they care they get the right result. I don't believe we are going to see vanity domains used on calls, and even if they were in "From", they won't be the domain in P-Asserted-Identity, or the SubjectAltName of the Identity signature. If some service that used email addresses as identities sent us calls, the email address (with its domain) is the "userpart" of the identity, not the whole thing. There are some interesting problems when you have URI to something like the MS IM systems. The first "@' (br@brianrosen.net@msn.com) gets escaped. We've built systems that handle that. The Firewall/Session Border controls will have several criteria when PSAPs are overloaded, but AFAIK, no existing firewalls or SBCs do what you suggest other than the repeat offender rule, which is the first line of defense. They do filter based on criteria that equate to IP Address or Domain of the SP, which we can deal with. We'll use what works for the other users of these systems, we're unlikely to be able to have emergency services special firewalls or SBCs. In most cases we're going to have hard connections, or more likely VPNs from service providers to the ESInet routers. That will probably handle 90+ percent of calls, but we'll still have substantial numbers coming from the big I Internet. We do want to know where they are coming from, and we will have SOME form of identity that we trust to separate those we know about from those we don't. This is a percentages game. Most of the time, calls will be accepted no matter how they get to the ESInet. If you want your calls to get through when things are bad, send them the way you send all your other calls; that will work okay. If you break that (by encouraging people to send them direct), then we'll have more problems. I'm back to the basic tenet: if you can use the service to create media sessions to others, you can use it to send emergency calls, and we want the calls sent the same path (because it will work). If you can't use the service (like, you can't register for one reason or another), we don't want you to be able to make emergency calls. To be fair, there is at least one country I know of that doesn't agree. They have documented a small number of good calls in with the tens of thousands of bad ones, and think its worth it to handle the bad ones in order to get to the good ones. Most PSAPs I know of don't. And furthermore, there are some regulations around this that are nation specific, and I think we don't need the IETF to wade into trying to figure out how to meet those regulations. In most cases, we don't really know how the regulator intends the regulations to cover devices on the Internet. Brian On 10/30/09 1:46 PM, "Marc Linsner" wrote: > Brian, > > "Normal Call Path" was NOT added to phonebcp for the purpose of the > perceived security you describe. The advantage (and the reason it's in > phonebcp) to using the normal call path is due to it being the most likely > mechanism to work. Unused/untested mechanisms are more likely to fail when > tried for the first time verses mechanisms that are used/tested daily. > Emergency time is not the time to test a new mechanism, hence use the normal > call path, the same one you just used to call grandma, to summons emergency > assistance. (This is a negative against this proposed mechanism.) > > If you are evangelizing within the PS community that 'sip:johnny@att.com' is > less of a threat than 'sip:johnny@vanitydomain.com', I suggest that is the > wrong message to be spreading. Please stop now. This will only lead to the > thousands of personal injury lawyers making big $$ at the expense of the PS > community. > > As you are intimately aware, there are millions of 'vanity' domains in use > and it's growing. Its growing not just in the individual market, but in the > small/medium business market. You also know there are thousands of hosting > companies providing services to the owners of vanity domains (email, web, > ftp, etc.). I expect in the near future that hosting providers will add sip > proxy services to their list of wares. > > My guess would be that PS officials would like to treat their customer known > as -'sip:johnny@vanitydomain.com' the same as their customer known as > -'sip:johnny@att.com'. The domain name does not dictate the level of > urgency in the request for emergency assistance, nor the veracity of the > caller. > > When an overload of the ESInet exists, I would suggest to look for other > parameters to use in decision process of how to populate the various queues. > > - Are the calls from all the same location? > - Is it reasonable that the IP address/network can be at the reported > location? > - How many calls have we received over a period of time from this AOR? IP > address/network? Location? > > Simply using the domain/AOR as the black and white rule, as you suggest, > will lead to big problems. > > Just my opinion, > > -Marc- > > On 10/30/09 9:47 AM, "Brian Rosen" wrote: > >> I want it to say MUST NOT use that mechanism :) >> >> I don't want alternative ways to make emergency calls. I want what phonebcp >> already says: send the call on the normal path and a normal identity and >> callback (which implies using a normal registration). >> >> I understand that the local authority can disable the ESRP registration >> mechanism. If this draft goes forward against my advice, then I will ask >> that there be text that says if the registration cannot be completed, the >> device MUST NOT send emergency calls direct to that ESRP, and must use its >> normal call path for emergency calls. >> >> We can't stop calls from entering the emergency services IP network without >> passing through a service provider. I have no wish to add any mechanism >> which would attempt to do so. If it would help, I would be happy to beef >> up language in framework that discusses this problem and what "normal call >> path" means. I would even be very happy to add a item to phonebcp that says >> "if you can't make normal calls, you can't make emergency calls", although >> we might get hung up on defining "normal", because if at some time when you >> need help the only number that could actually answer your call, sent down >> the same call path as you would normally send any call, is the emergency >> service, then we want that call. >> >> We frequently use you as an example. If you have a SIP Registrar and proxy >> server in your home (or boat) and you have a phone that registers with it, >> and you normally make calls to your family and friends with that setup, then >> I suspect that there is some service provider helping your proxy server >> connect to your family and friends. We would prefer your emergency calls go >> through that service provider. However, if for some reason, your proxy >> server forwarded an emergency call direct to the ESInet, it will normally go >> through. >> >> Unfortunately for you, if someone decides to attack the emergency call >> system, and it gets overloaded for some period of time until we can mitigate >> the attack, we may have to make choices on which calls we answer and which >> ones we don't. Your call sent through your proxy server to the ESInet >> direct may get lower priority than the same call sent through the service >> provider, if we notice that most of the attack calls are coming direct from >> the Internet, rather than going through a service provider we know about. >> We're building in explicit attack mitigation strategies like that. It's not >> unreasonable: if you have 5 sources entering your network, and one of them >> is the place where all (or most) of the attack is coming from, you shut off >> that source until you have a better filter. >> >> If a whole lot of devices assume the direct path is the preferred path, that >> would be bad for them. >> >> Furthermore, there is additional data sent to the emergency system (in the >> U.S.) with the call from the service provider. That information may be >> useful in helping you. The device can actually send the information, but >> while while we are pretty sure we can get most service providers to give it >> to us, we are pessimistic most devices will. Devices that have sensors, >> where the sensor data is useful for emergency calls may very well do it. >> Medical monitoring devices for example. NENA will be asking the IETF to >> standardize this soon, so that all service providers anywhere could provide >> it to all emergency services. It has things like subscriber (as opposed to >> caller) contact data, class of service information, SP contact data, etc. >> When things go wrong, the PSAP will often contact the SP and get help. The >> SP often has tools and mechanisms that CAN help. >> >> Brian >> >> >> On 10/29/09 5:46 PM, "Marc Linsner" wrote: >> >>> Brian, >>> >>> I didn't read anything in the draft that stated devices 'should' use this >>> mechanism (if it's there, it needs removed). I read it more as a device >>> 'could' use this mechanism (as in an alternative to other mechanisms). >>> >>> Further, since the ESRP is controlled by the PSAP, it certainly would be a >>> PSAP policy decision whether to support this mechanism. As without the ESRP >>> support of unknown UA registrations, the mechanism doesn't work. >>> >>> BTW, the term 'unregistered' is not in phonebcp. I think your are >>> stretching the 'normal call path' to include registration with something(?). >>> I find nothing in phonebcp that disallows 'direct' calls to an ESRP. If I >>> contact an ESRP from my UA 'directly', as long as the PSAP can call-back >>> using the Contact header I sent in the invite and my AOR leads back to my >>> UA, I've satisfied phonebcp. >>> >>> What am I missing? >>> >>> -Marc- >>> >>> >>> On 10/29/09 4:35 PM, "Brian Rosen" wrote: >>> >>>> The IETF writing standards that describe how devices should bypass their >>>> service provider and place emergency calls direct is not a PSAP policy >>>> issue. >>>> >>>> I'm satisfied with the current -phonebcp dictum to send calls on the normal >>>> call path. For an "unregistered" device, that will not allow any "calls" >>>> including emergency calls. >>>> >>>> I discussed this draft on the NENA LTD meeting this morning. That may >>>> generate some list discussion from some PSAP people who are subscribed. I >>>> would also like to hear from more PSAP folks on this subject. >>>> >>>> Brian >>>> >>>> >>>> On 10/29/09 3:27 PM, "Marc Linsner" wrote: >>>> >>>>> These are all PSAP policy decisions. Just as it's a PSAP policy decision >>>>> to >>>>> support the suggested mechanism in the draft. Existence of the document >>>>> describing the mechanism doesn't force PSAP policy. >>>>> >>>>> I personally would like to see some PSAPs and/or PS jurisdictions line up >>>>> behind the draft before it proceeds, but I don't see any harm in it going >>>>> forward. >>>>> >>>>> Of course, I'm dreaming about this special place where a PSAP actually >>>>> wants >>>>> to enable communication with all their customers and not force them to be >>>>> a >>>>> member of a special club. >>>>> >>>>> [non-chair hat on] >>>>> >>>>> -Marc- >>>>> >>>>> >>>>> On 10/29/09 2:35 PM, "Brian Rosen" wrote: >>>>> >>>>>> Thank you. That is what I meant, and you said it better than I was going >>>>>> to. >>>>>> >>>>>> We may also have some transitive relationships: that is, if there is a >>>>>> "local" PSAP that trusts that they have done so, other PSAPs may trust >>>>>> that >>>>>> they have done so. >>>>>> >>>>>> Brian >>>>>> >>>>>> On 10/29/09 11:48 AM, "DRAGE, Keith (Keith)" >>>>>> wrote: >>>>>> >>>>>>> I suspect that what Brian is saying is that anyone can be a service >>>>>>> provider >>>>>>> (or whatever else you want to call it) in this case provided that: >>>>>>> >>>>>>> 1) they make that agreement with the PSAP providers they route >>>>>>> calls >>>>>>> to; >>>>>>> >>>>>>> 2) they authenticate the calls requests to a level of security that >>>>>>> meets >>>>>>> the PSAPs (and any legal) requirements; >>>>>>> >>>>>>> 3) the PSAP trusts that they have done so. >>>>>>> >>>>>>> While this would normally be what we would understand as public >>>>>>> telecommuncation operators, it doesn't mean they have to be. >>>>>>> >>>>>>> regards >>>>>>> >>>>>>> Keith >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>>>>>>> On Behalf Of Marc Linsner >>>>>>>> Sent: Thursday, October 29, 2009 12:32 PM >>>>>>>> To: Brian Rosen >>>>>>>> Cc: ecrit@ietf.org >>>>>>>> Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>>>>>> considered >>>>>>>> >>>>>>>> Brian, >>>>>>>> >>>>>>>> Please define what you consider to be a service provider. >>>>>>>> >>>>>>>> Is Skype a service? >>>>>>>> Is Jabber a service? >>>>>>>> Is Google Voice a service? >>>>>>>> Is mydomain.com hosted on a commercial site a service? >>>>>>>> Is mydomain.com hosted on a home server a service? >>>>>>>> Is myEnterpriseVoIP.com a service? >>>>>>>> >>>>>>>> So, what you are saying that if I can make calls via all of >>>>>>>> the above, it's OK for all of the above to contact an ESRP? >>>>>>>> >>>>>>>> Are you requiring that I have a full-time proxy on-line for >>>>>>>> mydomain.com or can I simply run a transient UA and dynamic DNS? >>>>>>>> >>>>>>>> -Marc- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 10/28/09 11:17 PM, "Brian Rosen" wrote: >>>>>>>> >>>>>>>>> I'm not worried about security by obscurity. I don't want >>>>>>>> phones (or >>>>>>>>> other >>>>>>>>> devices) built to call directly. >>>>>>>>> >>>>>>>>> -phonebcp says "send the call on your normal outbound call path". >>>>>>>>> That's what I want it to say, and I don't want it to say "send it >>>>>>>>> direct, bypass your service provider. >>>>>>>>> >>>>>>>>> I'm not stopping attack, I am stopping abuse. >>>>>>>>> >>>>>>>>> I don't want devices that are not subscribed to services to >>>>>>>> be able to >>>>>>>>> make emergency calls (that is, if they can't make "normal" >>>>>>>> calls, they >>>>>>>>> should not be able to make emergency calls). >>>>>>>>> >>>>>>>>> Brian >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/28/09 6:51 PM, "Marc Linsner" wrote: >>>>>>>>> >>>>>>>>>> Brian, >>>>>>>>>> >>>>>>>>>> What I hear you saying: 'if we don't document how to spoof a PSAP, >>>>>>>>>> then nobody will figure it out.' Isn't that a little >>>>>>>> short sighted? >>>>>>>>>> >>>>>>>>>> Joey@miscreant.org will figure out how to establish a SIP session >>>>>>>>>> with any PSAP in the world within 10 minutes of that PSAP being >>>>>>>>>> accessible via the Internet, regardless of documentation. >>>>>>>>>> >>>>>>>>>> I believe there's more harm created in not documenting this for >>>>>>>>>> John.Q.Public@ordinary_citizen.com. >>>>>>>>>> >>>>>>>>>> Granted, nobody here is looking to cause harm to a PSAP. But >>>>>>>>>> Joey@miscreant.org can certainly expend public safety resources by >>>>>>>>>> reporting a bomb threat to a local school. Should we require that >>>>>>>>>> all SIP calls to the local school come from a trusted SP? >>>>>>>> Where does it end? >>>>>>>>>> >>>>>>>>>> This isn't the way to deal with spam. >>>>>>>>>> >>>>>>>>>> -Marc- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 10/27/09 11:00 AM, "Brian Rosen" wrote: >>>>>>>>>> >>>>>>>>>>> The first goal is to prevent bad calls. >>>>>>>>>>> >>>>>>>>>>> The second goal is to indentify the source of the bad calls. >>>>>>>>>>> >>>>>>>>>>> I'm starting with the first goal. I don't want you to be able to >>>>>>>>>>> take a device out of a box, plug it into a network, and have the >>>>>>>>>>> only call you can make be an emergency call. I want the >>>>>>>> device to >>>>>>>>>>> actually "work" (as in be able to place calls to all the entities >>>>>>>>>>> that it was intended to) first, and then be able to place >>>>>>>> emergency calls. >>>>>>>>>>> >>>>>>>>>>> Please spend some time in a PSAP while a kid with a >>>>>>>> simless phone has "fun" >>>>>>>>>>> with it. Imagine how much fun the test mechanism is as >>>>>>>> opposed to >>>>>>>>>>> placing real calls. >>>>>>>>>>> >>>>>>>>>>> If we somehow get a bad call, we need to send the cops. >>>>>>>> That means >>>>>>>>>>> we need an identity (and a location). >>>>>>>>>>> >>>>>>>>>>> I think a good cert could be the basis of a good identity, if we >>>>>>>>>>> could get one. I don't see how we do that. >>>>>>>>>>> >>>>>>>>>>> Brian >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 10/27/09 10:39 AM, "Richard Barnes" wrote: >>>>>>>>>>> >>>>>>>>>>>> Brian, >>>>>>>>>>>> >>>>>>>>>>>> Is the security goal here more access control (i.e., controlling >>>>>>>>>>>> who can send calls to a PSAP) or attribution/identification for >>>>>>>>>>>> post-hoc action. >>>>>>>>>>>> >>>>>>>>>>>> If it's the latter, then ISTM that the problem can largely be >>>>>>>>>>>> reduced to having a certificate infrastructure that binds >>>>>>>>>>>> authenticated identities to real-world entities. The >>>>>>>> "extended validation" >>>>>>>>>>>> certificates that current commercial CAs issue seem to largely >>>>>>>>>>>> satisfy this requirement. >>>>>>>>>>>> >>>>>>>>>>>> --Richard >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Oct 27, 2009, at 4:31 PM, Brian Rosen wrote: >>>>>>>>>>>> >>>>>>>>>>>> Of course not all VSPs will have trust relationships with all >>>>>>>>>>>> PSAPs. One can hope that long term, we can evolve to >>>>>>>> transitive >>>>>>>>>>>> trust relationships that work pretty well cross border. >>>>>>>>>>>> >>>>>>>>>>>> The emergency guys are actually terrified of private/individual >>>>>>>>>>>> domains sending them calls, and we're telling them we >>>>>>>> expect that >>>>>>>>>>>> to be possible, but rare, and we're giving them mechanisms that >>>>>>>>>>>> will effectively allow them to turn off calls >>>>>>>> selectively, based >>>>>>>>>>>> on factors including what domain the call comes from. >>>>>>>> They expect >>>>>>>>>>>> that such calls will be one of the loopholes where they get >>>>>>>>>>>> equivalents to sim-less calls, which drive them nuts. >>>>>>>> They don't >>>>>>>>>>>> want ANY calls that don't come from service providers, although >>>>>>>>>>>> they seem to be okay with the notion that the SP may not have >>>>>>>>>>>> great identity (AOL being a poster child). So, while >>>>>>>> indeed they >>>>>>>>>>>> understand, and have concerns about having to take calls from >>>>>>>>>>>> Sierra Leone VoIP services Pty, they would much rather >>>>>>>> have a call >>>>>>>>>>>> that went through them then a call that went through no service >>>>>>>>>>>> provider at all. >>>>>>>>>>>> >>>>>>>>>>>> I'm not trying to make calls direct from devices or private >>>>>>>>>>>> domains impossible, but I think the notion that we're promoting >>>>>>>>>>>> them is a very bad idea until we have effective mechanisms to >>>>>>>>>>>> prevent abuse. >>>>>>>>>>>> >>>>>>>>>>>> Brian >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/27/09 9:02 AM, "Marc Linsner" wrote: >>>>>>>>>>>> >>>>>>>>>>>> Brian, >>>>>>>>>>>> >>>>>>>>>>>> I'm a little confused. I don't remember you objecting to >>>>>>>>>>>> requirement RE1 from RFC5012 and I remember your use >>>>>>>> case about a >>>>>>>>>>>> Sierra Leone VSP. >>>>>>>>>>>> >>>>>>>>>>>> Are you implying that *all* VSPs will have a trust >>>>>>>> relationships >>>>>>>>>>>> with *all* PSAPs? >>>>>>>>>>>> >>>>>>>>>>>> What is the difference between a call coming from a private/ >>>>>>>>>>>> individual domain (as in not a commercial VSP) and a >>>>>>>> VSP on the >>>>>>>>>>>> other side of the world (outside the jurisdiction)? >>>>>>>>>>>> >>>>>>>>>>>> I'm trying to figure out whether you're objecting to anonymous >>>>>>>>>>>> calls to the PSAP or the mechanisms proposed in this draft? >>>>>>>>>>>> >>>>>>>>>>>> [Don't take this as my endorsement of the draft, as >>>>>>>> I'm not sure >>>>>>>>>>>> I agree with UAs registering with the ESRP.] >>>>>>>>>>>> >>>>>>>>>>>> -Marc- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/26/09 8:59 PM, "Brian Rosen" wrote: >>>>>>>>>>>> >>>>>>>>>>>> First of all, I put it on the wrong email list, sorry >>>>>>>> about that. >>>>>>>>>>>> >>>>>>>>>>>> Then, we have carefully arranged it so that there is >>>>>>>> no identity >>>>>>>>>>>> coming from the access network provider, and because the >>>>>>>>>>>> location is coming from that provider, we really >>>>>>>> don't want to. >>>>>>>>>>>> But even if we did, we would need a really good >>>>>>>> identifier, and >>>>>>>>>>>> there isn't one. >>>>>>>>>>>> >>>>>>>>>>>> The problem we have with -direct is anonymous callers, and if >>>>>>>>>>>> they have any option, they would also be >>>>>>>> location-less. Until >>>>>>>>>>>> and unless we get rid of anonymity, we can't >>>>>>>> encourage service >>>>>>>>>>>> provider-less calls. The draft does not make any >>>>>>>> provision to >>>>>>>>>>>> provide any kind of identity. Many networks (think free wifi >>>>>>>>>>>> for example) would make providing good identity difficult. >>>>>>>>>>>> >>>>>>>>>>>> The fact is that there is a SERVICE provider in >>>>>>>> nearly all of the >>>>>>>>>>>> communications systems. The SERVICE provider is in >>>>>>>> a position to >>>>>>>>>>>> assist >>>>>>>>>>>> the emergency calling system when it needs more information. >>>>>>>>>>>> That's what a >>>>>>>>>>>> good SERVICE provider does. Cutting them out is not a great >>>>>>>>>>>> idea. Most of the attempts to provide real time >>>>>>>> communications >>>>>>>>>>>> between people have evolved to using service providers, even >>>>>>>>>>>> when there were alternatives. File transfer via >>>>>>>> something like >>>>>>>>>>>> Torrent is a counterexample (which isn't real time), but even >>>>>>>>>>>> there, you end up with service providers like The Pirate Bay >>>>>>>>>>>> (R.I.P) to provide introduction services. I don't >>>>>>>> think we're >>>>>>>>>>>> going to see changes that eliminate service providers, and in >>>>>>>>>>>> this case, they provide value to the emergency >>>>>>>> calling systems. >>>>>>>>>>>> All of the emergency professionals I know have issues with >>>>>>>>>>>> service providers, but they would react with horror if you >>>>>>>>>>>> suggested cutting them out. Ask them, please. >>>>>>>>>>>> >>>>>>>>>>>> So, I claim you have a solution in search of a >>>>>>>> problem. We have >>>>>>>>>>>> solved the "calling network isn't the access network" problem >>>>>>>>>>>> already. Service providers ARE in the path now, in >>>>>>>> nearly every >>>>>>>>>>>> case (in fact a counter example escapes me, although there >>>>>>>>>>>> probably are some). There is no movement I can detect which >>>>>>>>>>>> would change that any time soon; quite the opposite. >>>>>>>> We have a >>>>>>>>>>>> known killer problem without some kind of subscription to a >>>>>>>>>>>> service that provides a good identity, for which you >>>>>>>> provide no >>>>>>>>>>>> answers. >>>>>>>>>>>> We have >>>>>>>>>>>> experience with the killer problem: sim-less calling was >>>>>>>>>>>> supposed to provide a way to make an emergency call >>>>>>>> in exactly >>>>>>>>>>>> the kinds of circumstances you are describing. Our >>>>>>>> real world >>>>>>>>>>>> experience is that you create a huge problem that diverts >>>>>>>>>>>> resources from helping people to chasing scammers and >>>>>>>>>>>> flea-market sellers. >>>>>>>>>>>> >>>>>>>>>>>> Nothing is perfect: you can get a AIM screen name >>>>>>>> without a very >>>>>>>>>>>> good identity for example. However, the notion that >>>>>>>> we're going >>>>>>>>>>>> to provide direct access without a service provider >>>>>>>>>>>> deliberately, especially without really good identity >>>>>>>> from the >>>>>>>>>>>> access network is, in my opinion not only a no, it's >>>>>>>> a heck no. >>>>>>>>>>>> I'll line up as many emergency service professionals as you >>>>>>>>>>>> would like to tell you this is a harmful idea. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/26/09 7:56 PM, "Dawson, Martin" >>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> I am glad this has come up. It's a debate that has >>>>>>>> to happen if >>>>>>>>>>>> we are to move beyond a long standing legacy misconception. >>>>>>>>>>>> >>>>>>>>>>>> In the circuit service world - whether it was POTS >>>>>>>> or mobile, >>>>>>>>>>>> the access network had full responsibility for >>>>>>>> delivering the >>>>>>>>>>>> emergency call. In that world, routing an emergency >>>>>>>> call meant >>>>>>>>>>>> getting a circuit established to the correct call center. In >>>>>>>>>>>> most parts of the world, this was done using the >>>>>>>> regional part >>>>>>>>>>>> of the PSTN to switch the circuit to a call center >>>>>>>> on the PSTN. >>>>>>>>>>>> In some jurisdictions, such as the US, it was done directly >>>>>>>>>>>> from the local exchange carrier to the call center. >>>>>>>> Either way, >>>>>>>>>>>> there was no third party involved. >>>>>>>>>>>> >>>>>>>>>>>> Now we have the Internet. We still have public >>>>>>>> access network >>>>>>>>>>>> providers. >>>>>>>>>>>> They >>>>>>>>>>>> switch packets onto the Internet for their subscribers. They >>>>>>>>>>>> can similarly ensure that packets reach the local emergency >>>>>>>>>>>> call centers. >>>>>>>>>>>> >>>>>>>>>>>> The fact is that there was no equivalent of a VSP in the >>>>>>>>>>>> traditional environment. VoIP is a presence service, >>>>>>>> and it had >>>>>>>>>>>> no common equivalent in the PSTN world. It could >>>>>>>> have, but the >>>>>>>>>>>> narrowband state of technology and the common market >>>>>>>> use cases >>>>>>>>>>>> didn't support its development. By the time ISDN >>>>>>>> arrived, the >>>>>>>>>>>> PSTN had already slipped into its palliative stage without >>>>>>>>>>>> realizing it. >>>>>>>>>>>> >>>>>>>>>>>> It's an entrenched misconception that because the circuit >>>>>>>>>>>> service provided by exchange carriers was most commonly used >>>>>>>>>>>> for "voice" (but, it should be noted, also for fax, >>>>>>>> telex, tty, >>>>>>>>>>>> security system monitoring and, even, IP data) that VSPs are >>>>>>>>>>>> somehow equivalent to exchange carriers. They are not. >>>>>>>>>>>> >>>>>>>>>>>> Indeed, involving VSPs in emergency calls is the Internet >>>>>>>>>>>> equivalent of involving long distance providers in POTS >>>>>>>>>>>> emergency calls. They are neither necessary nor particularly >>>>>>>>>>>> helpful; they can't be guaranteed to be within the emergency >>>>>>>>>>>> jurisdiction; depending on them actually diminishes the >>>>>>>>>>>> efficacy of emergency service access. It does not help the >>>>>>>>>>>> caller, the emergency service, nor the third party >>>>>>>> to insist on >>>>>>>>>>>> the third party's involvement. >>>>>>>>>>>> >>>>>>>>>>>> It can't be helped if you have over sold the benefits of VSP >>>>>>>>>>>> involvement to yourself and others Brian. It is time >>>>>>>> to have a >>>>>>>>>>>> reasoned debate. >>>>>>>>>>>> From my >>>>>>>>>>>> perspective, the argument that there is no "subscription" >>>>>>>>>>>> involved is >>>>>>>>>>>> patently >>>>>>>>>>>> false. There has to be a subscription of some description in >>>>>>>>>>>> order to get to the Internet. Yes, there is free public >>>>>>>>>>>> Internet access (just as there are free courtesy >>>>>>>> phones on the >>>>>>>>>>>> PSTN and free access to emergency services from pay >>>>>>>> phones. All >>>>>>>>>>>> these services are still connected to the public Internet >>>>>>>>>>>> infrastructure and they all represent an "operator" >>>>>>>> with some >>>>>>>>>>>> level of information about the caller. >>>>>>>>>>>> >>>>>>>>>>>> With the over-emphasis on VSPs, what is missing from >>>>>>>> the ECRIT >>>>>>>>>>>> and i3 models is the direct interface for querying >>>>>>>> the access >>>>>>>>>>>> network for subscriber data (should it prove >>>>>>>> necessary). These >>>>>>>>>>>> models need to take the long view of how emergency >>>>>>>> calling is >>>>>>>>>>>> done in the Internet age; they should not be protracting an >>>>>>>>>>>> unnecessary reliance on VSPs. >>>>>>>>>>>> >>>>>>>>>>>> I have deleted the premature and prejudicial text from the >>>>>>>>>>>> subject heading. >>>>>>>>>>>> And I'll leave this on ECRIT as the most appropriate WG. >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> Martin >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: ecrit-bounces@ietf.org >>>>>>>> [mailto:ecrit-bounces@ietf.org] On >>>>>>>>>>>> Behalf Of Hannes Tschofenig >>>>>>>>>>>> Sent: Tuesday, 27 October 2009 8:23 AM >>>>>>>>>>>> To: ecrit@ietf.org >>>>>>>>>>>> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>>>>>>>>>> considered harmful, at least given our current experiences >>>>>>>>>>>> >>>>>>>>>>>> FYI: feedback from Brian regarding a recent ECRIT >>>>>>>> contribution. >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: geopriv-bounces@ietf.org >>>>>>>>>>>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian >>>>>>>>>>>> Sent: 26 October, 2009 23:10 >>>>>>>>>>>> To: geopriv@ietf.org >>>>>>>>>>>> Subject: [Geopriv] Winterbottom-ecrit-direct considered >>>>>>>>>>>> harmful, at least given our current experiences >>>>>>>>>>>> >>>>>>>>>>>> The notion behind -direct is to not use a service >>>>>>>> provider to >>>>>>>>>>>> place an emergency call. Instead, the device >>>>>>>> registers with >>>>>>>>>>>> an Emergency Services Routing Proxy immediately before the >>>>>>>>>>>> call and the call is routed directly from the >>>>>>>> device to the ESRP. >>>>>>>>>>>> >>>>>>>>>>>> At least at the moment, this is an exceedingly bad idea. >>>>>>>>>>>> >>>>>>>>>>>> Emergency calling authorities like service providers, a lot. >>>>>>>>>>>> They like them because they can hold them >>>>>>>> accountable, and the >>>>>>>>>>>> service providers don't like theft of service, which is >>>>>>>>>>>> something the emergency call guys have an analog to. >>>>>>>>>>>> >>>>>>>>>>>> The facts are that where unaccountable access to emergency >>>>>>>>>>>> calling is allowed, huge numbers of false calls >>>>>>>> occur, with no >>>>>>>>>>>> way to stop them, and no way to tell the good ones from the >>>>>>>>>>>> bad ones. This has been seen multiple times where >>>>>>>> so called >>>>>>>>>>>> "simless" or "unauthenticated" calls are allowed. >>>>>>>>>>>> >>>>>>>>>>>> -direct precisely duplicates simless calling. The only >>>>>>>>>>>> "registration" is an emergency registration, only emergency >>>>>>>>>>>> calls are allowed, any device can make an emergency call if >>>>>>>>>>>> all it has is a (radio) connection to any network. >>>>>>>>>>>> We can predict, with a very high degree of >>>>>>>> certainty, that the >>>>>>>>>>>> feature will be horribly abused: for example to test that a >>>>>>>>>>>> phone without a service plan works. >>>>>>>>>>>> >>>>>>>>>>>> There have been studies which show tens of thousands of bad >>>>>>>>>>>> calls with zero good ones. Nearly every authority I know >>>>>>>>>>>> where the regulator has insisted on simless calling >>>>>>>> wants it >>>>>>>>>>>> repealed. There is one counter example I know >>>>>>>> where the fact >>>>>>>>>>>> that they got a couple, literally, of good calls among the >>>>>>>>>>>> tens of thousands of bad calls was considered >>>>>>>> enough reason to >>>>>>>>>>>> put up with the problem. >>>>>>>>>>>> >>>>>>>>>>>> Service providers give us information that may be useful: a >>>>>>>>>>>> subscriber name and address for example, which is not >>>>>>>>>>>> spoofable by the caller. They have ways to trace callers, >>>>>>>>>>>> especially bad callers. They don't want their >>>>>>>> systems abused >>>>>>>>>>>> any more than the emergency calling authorities do. >>>>>>>>>>>> >>>>>>>>>>>> This is a bad idea. A very bad idea. Please stop it. >>>>>>>>>>>> >>>>>>>>>>>> Someday, we may have better ways to prevent abuse. Until we >>>>>>>>>>>> do, service providers are a good thing on an emergency call. >>>>>>>>>>>> We don't want them cut out. >>>>>>>>>>>> >>>>>>>>>>>> Brian >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Geopriv mailing list >>>>>>>>>>>> Geopriv@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 mlinsner@cisco.com Fri Oct 30 13:14:35 2009 Return-Path: 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 AC3C83A68AC for ; Fri, 30 Oct 2009 13:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.438 X-Spam-Level: X-Spam-Status: No, score=-6.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 iF4hQS+sQn1k for ; Fri, 30 Oct 2009 13:14:34 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 857873A6867 for ; Fri, 30 Oct 2009 13:14:34 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKvl6kqtJV2Z/2dsb2JhbADIRZg/gjkGgX4EjAA X-IronPort-AV: E=Sophos;i="4.44,655,1249257600"; d="scan'208";a="65770678" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-2.cisco.com with ESMTP; 30 Oct 2009 20:14:51 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id n9UKEpbt018932; Fri, 30 Oct 2009 20:14:51 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.3959); Fri, 30 Oct 2009 16:14:50 -0400 Received: from [10.116.195.121] ([10.116.195.121]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 16:14:50 -0400 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Fri, 30 Oct 2009 16:14:47 -0400 From: Marc Linsner To: Brian Rosen Message-ID: Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4AE1y5CAAGs5+wAAX4z4UAAdMnZQACY9dzAAJ55ZEAIY7SzwAIVkuoAAGCY3EAA610Lg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 30 Oct 2009 20:14:50.0332 (UTC) FILETIME=[A26DC1C0:01CA599D] Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Fri, 30 Oct 2009 20:14:35 -0000 On 10/30/09 2:29 PM, "Brian Rosen" wrote: > I'm the messenger here. PSAPs prefer service providers to be on the path of > a call, and they have bad experiences when they aren't. > > Given their experiences, I can't fault them. > > The reason the text is in phonebcp is as you said it is: because "normal" is > likely to work. The fact that "normal" means SP path in 99.999% of cases > gets the PSAPs what they want. They don't care about why we did it, they > care they get the right result. I, like others, believe the role/definition of the 'SP', as currently defined by the PSAPs, will change significantly going forward. > > I don't believe we are going to see vanity domains used on calls, and even > if they were in "From", they won't be the domain in P-Asserted-Identity, or > the SubjectAltName of the Identity signature. If some service that used > email addresses as identities sent us calls, the email address (with its > domain) is the "userpart" of the identity, not the whole thing. There are > some interesting problems when you have URI to something like the MS IM > systems. The first "@' (br@brianrosen.net@msn.com) gets escaped. We've > built systems that handle that. I think this is a little short-sighted. Certificates for vanity domains are certainly doable. Besides P-Asserted-Identity is not a MUST in phonebcp. :^) > > The Firewall/Session Border controls will have several criteria when PSAPs > are overloaded, but AFAIK, no existing firewalls or SBCs do what you suggest > other than the repeat offender rule, which is the first line of defense. > They do filter based on criteria that equate to IP Address or Domain of the > SP, which we can deal with. We'll use what works for the other users of > these systems, we're unlikely to be able to have emergency services special > firewalls or SBCs. We're not talking about existing firewalls and SBCs. We're talking about ESInet Border Control Function. If you don't define what you want there, you'll live with what you get. My suggestions are not beyond what's possible, it's all software. -Marc- From br@brianrosen.net Fri Oct 30 13:55:19 2009 Return-Path: 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 DDC9A3A67DD for ; Fri, 30 Oct 2009 13:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=0.345, 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 JzEE6vlMjEbG for ; Fri, 30 Oct 2009 13:55:19 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id E2C423A63EC for ; Fri, 30 Oct 2009 13:55:18 -0700 (PDT) Received: from [209.173.57.233] (helo=[192.168.130.13]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1N3yVI-0006AO-Uj; Fri, 30 Oct 2009 15:55:25 -0500 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Fri, 30 Oct 2009 16:55:30 -0400 From: Brian Rosen To: Marc Linsner Message-ID: Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4AE1y5CAAGs5+wAAX4z4UAAdMnZQACY9dzAAJ55ZEAIY7SzwAIVkuoAAGCY3EAA610LgABbAmu In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Fri, 30 Oct 2009 20:55:20 -0000 There is way too much speculation here. You are speculating that there will be interesting services without service providers that have two way interactive media, where the identity of the callers is a simple domain name, emergency calls from those devices is interesting, they can't provide a suitable callback without a registration from the ESRP, and such calls wont be the preferred abuse call source. When we have that problem, if we ever have that problem, we'll solve it. Right now, the simpler case of a direct call from an unknown source because you have a proxy server in your boat will get through just fine nearly all the time. When it doesn't, it will be because that path is being used by someone attacking, and the lack of a service provider will probably be to the disadvantage of the direct caller. I'm not going to lose sleep over that problem. I'd rather beef up the system so we don't have to drop calls when we're attacked. OTOH, I don't want to promote the proxy server in the boat idea. If it happens occasionally, we'll cope. Brian On 10/30/09 4:14 PM, "Marc Linsner" wrote: > > > On 10/30/09 2:29 PM, "Brian Rosen" wrote: > >> I'm the messenger here. PSAPs prefer service providers to be on the path of >> a call, and they have bad experiences when they aren't. >> >> Given their experiences, I can't fault them. >> >> The reason the text is in phonebcp is as you said it is: because "normal" is >> likely to work. The fact that "normal" means SP path in 99.999% of cases >> gets the PSAPs what they want. They don't care about why we did it, they >> care they get the right result. > > I, like others, believe the role/definition of the 'SP', as currently > defined by the PSAPs, will change significantly going forward. > >> >> I don't believe we are going to see vanity domains used on calls, and even >> if they were in "From", they won't be the domain in P-Asserted-Identity, or >> the SubjectAltName of the Identity signature. If some service that used >> email addresses as identities sent us calls, the email address (with its >> domain) is the "userpart" of the identity, not the whole thing. There are >> some interesting problems when you have URI to something like the MS IM >> systems. The first "@' (br@brianrosen.net@msn.com) gets escaped. We've >> built systems that handle that. > > I think this is a little short-sighted. Certificates for vanity domains are > certainly doable. Besides P-Asserted-Identity is not a MUST in phonebcp. > :^) > >> >> The Firewall/Session Border controls will have several criteria when PSAPs >> are overloaded, but AFAIK, no existing firewalls or SBCs do what you suggest >> other than the repeat offender rule, which is the first line of defense. >> They do filter based on criteria that equate to IP Address or Domain of the >> SP, which we can deal with. We'll use what works for the other users of >> these systems, we're unlikely to be able to have emergency services special >> firewalls or SBCs. > > We're not talking about existing firewalls and SBCs. We're talking about > ESInet Border Control Function. If you don't define what you want there, > you'll live with what you get. My suggestions are not beyond what's > possible, it's all software. > > -Marc- > > > > From mlinsner@cisco.com Fri Oct 30 15:12:07 2009 Return-Path: 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 2473D3A6A33 for ; Fri, 30 Oct 2009 15:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 LDeFTmRhs+6W for ; Fri, 30 Oct 2009 15:12:06 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 265273A681F for ; Fri, 30 Oct 2009 15:12:06 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMsB60pAZnwN/2dsb2JhbADIN5g4gjkGgX4EjAA X-IronPort-AV: E=Sophos;i="4.44,656,1249257600"; d="scan'208";a="219975283" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by sj-iport-2.cisco.com with ESMTP; 30 Oct 2009 22:12:23 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9UMBP1p029072; Fri, 30 Oct 2009 22:12:23 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 18:12:17 -0400 Received: from [10.116.195.121] ([10.116.195.121]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 18:12:16 -0400 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Fri, 30 Oct 2009 18:12:13 -0400 From: Marc Linsner To: Brian Rosen Message-ID: Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4AE1y5CAAGs5+wAAX4z4UAAdMnZQACY9dzAAJ55ZEAIY7SzwAIVkuoAAGCY3EAA610LgABbAmuAAKt540= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 30 Oct 2009 22:12:16.0388 (UTC) FILETIME=[0A349440:01CA59AE] Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Fri, 30 Oct 2009 22:12:07 -0000 It's not that I necessarily believe there will be a lack of SPs. I believe the mix of SPs and the products they offer will change dramatically at a pace that PSAPs won't be able to keep up. This week Google, next week Noggle, the next week Boogle, etc. If in fact the PSAP requires relationships with every SP that may send an emergency call their way, it will only stifle innovation. -Marc- On 10/30/09 4:55 PM, "Brian Rosen" wrote: > There is way too much speculation here. > > You are speculating that there will be interesting services without service > providers that have two way interactive media, where the identity of the > callers is a simple domain name, emergency calls from those devices is > interesting, they can't provide a suitable callback without a registration > from the ESRP, and such calls wont be the preferred abuse call source. > > When we have that problem, if we ever have that problem, we'll solve it. > > Right now, the simpler case of a direct call from an unknown source because > you have a proxy server in your boat will get through just fine nearly all > the time. When it doesn't, it will be because that path is being used by > someone attacking, and the lack of a service provider will probably be to > the disadvantage of the direct caller. I'm not going to lose sleep over > that problem. I'd rather beef up the system so we don't have to drop calls > when we're attacked. OTOH, I don't want to promote the proxy server in the > boat idea. If it happens occasionally, we'll cope. > > Brian > > > On 10/30/09 4:14 PM, "Marc Linsner" wrote: > >> >> >> On 10/30/09 2:29 PM, "Brian Rosen" wrote: >> >>> I'm the messenger here. PSAPs prefer service providers to be on the path of >>> a call, and they have bad experiences when they aren't. >>> >>> Given their experiences, I can't fault them. >>> >>> The reason the text is in phonebcp is as you said it is: because "normal" is >>> likely to work. The fact that "normal" means SP path in 99.999% of cases >>> gets the PSAPs what they want. They don't care about why we did it, they >>> care they get the right result. >> >> I, like others, believe the role/definition of the 'SP', as currently >> defined by the PSAPs, will change significantly going forward. >> >>> >>> I don't believe we are going to see vanity domains used on calls, and even >>> if they were in "From", they won't be the domain in P-Asserted-Identity, or >>> the SubjectAltName of the Identity signature. If some service that used >>> email addresses as identities sent us calls, the email address (with its >>> domain) is the "userpart" of the identity, not the whole thing. There are >>> some interesting problems when you have URI to something like the MS IM >>> systems. The first "@' (br@brianrosen.net@msn.com) gets escaped. We've >>> built systems that handle that. >> >> I think this is a little short-sighted. Certificates for vanity domains are >> certainly doable. Besides P-Asserted-Identity is not a MUST in phonebcp. >> :^) >> >>> >>> The Firewall/Session Border controls will have several criteria when PSAPs >>> are overloaded, but AFAIK, no existing firewalls or SBCs do what you suggest >>> other than the repeat offender rule, which is the first line of defense. >>> They do filter based on criteria that equate to IP Address or Domain of the >>> SP, which we can deal with. We'll use what works for the other users of >>> these systems, we're unlikely to be able to have emergency services special >>> firewalls or SBCs. >> >> We're not talking about existing firewalls and SBCs. We're talking about >> ESInet Border Control Function. If you don't define what you want there, >> you'll live with what you get. My suggestions are not beyond what's >> possible, it's all software. >> >> -Marc- >> >> >> >> > > From Martin.Dawson@andrew.com Fri Oct 30 18:18:31 2009 Return-Path: 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 261023A69B6 for ; Fri, 30 Oct 2009 18:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] 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 iQeUXIi1t6dL for ; Fri, 30 Oct 2009 18:18:28 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id DB2B23A6781 for ; Fri, 30 Oct 2009 18:18:27 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:48597 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S67870AbZJaBSm convert rfc822-to-8bit (ORCPT ); Fri, 30 Oct 2009 20:18:42 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Fri, 30 Oct 2009 20:18:41 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Sat, 31 Oct 2009 09:18:37 +0800 From: "Dawson, Martin" To: Brian Rosen , Marc Linsner Date: Sat, 31 Oct 2009 09:18:11 +0800 Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4AE1y5CAAGs5+wAAX4z4UAAdMnZQACY9dzAAJ55ZEAIY7SzwAIVkuoAAGCY3EADhIEsA== Message-ID: <8B0A9FCBB9832F43971E38010638454F0F251C34@SISPE7MB1.commscope.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Dawson@andrew.com Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Sat, 31 Oct 2009 01:18:31 -0000 Hey Brian, Maybe if you keep saying "service provider" we'll all start believing it means "VSP" and it really does have some quintessential significance to emergency calling... However, to quote Watto (Phantom Menace): "What? You think you're some kind of Jedi, waving your hand around like that?" :) Sure PSAP providers like to have a "service provider" they can point their finger at. They like someone who might be a source of forensic information related to the source of nuisance calls. In particular, it's really useful if that provider is in the same jurisdiction that they are. That would be the 'I' SP rather than the 'V' SP that you keep trying to steer the focus back to. Cheers, Martin -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Saturday, 31 October 2009 5:29 AM To: Marc Linsner Cc: ecrit@ietf.org Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered I'm the messenger here. PSAPs prefer service providers to be on the path of a call, and they have bad experiences when they aren't. Given their experiences, I can't fault them. The reason the text is in phonebcp is as you said it is: because "normal" is likely to work. The fact that "normal" means SP path in 99.999% of cases gets the PSAPs what they want. They don't care about why we did it, they care they get the right result. I don't believe we are going to see vanity domains used on calls, and even if they were in "From", they won't be the domain in P-Asserted-Identity, or the SubjectAltName of the Identity signature. If some service that used email addresses as identities sent us calls, the email address (with its domain) is the "userpart" of the identity, not the whole thing. There are some interesting problems when you have URI to something like the MS IM systems. The first "@' (br@brianrosen.net@msn.com) gets escaped. We've built systems that handle that. The Firewall/Session Border controls will have several criteria when PSAPs are overloaded, but AFAIK, no existing firewalls or SBCs do what you suggest other than the repeat offender rule, which is the first line of defense. They do filter based on criteria that equate to IP Address or Domain of the SP, which we can deal with. We'll use what works for the other users of these systems, we're unlikely to be able to have emergency services special firewalls or SBCs. In most cases we're going to have hard connections, or more likely VPNs from service providers to the ESInet routers. That will probably handle 90+ percent of calls, but we'll still have substantial numbers coming from the big I Internet. We do want to know where they are coming from, and we will have SOME form of identity that we trust to separate those we know about from those we don't. This is a percentages game. Most of the time, calls will be accepted no matter how they get to the ESInet. If you want your calls to get through when things are bad, send them the way you send all your other calls; that will work okay. If you break that (by encouraging people to send them direct), then we'll have more problems. I'm back to the basic tenet: if you can use the service to create media sessions to others, you can use it to send emergency calls, and we want the calls sent the same path (because it will work). If you can't use the service (like, you can't register for one reason or another), we don't want you to be able to make emergency calls. To be fair, there is at least one country I know of that doesn't agree. They have documented a small number of good calls in with the tens of thousands of bad ones, and think its worth it to handle the bad ones in order to get to the good ones. Most PSAPs I know of don't. And furthermore, there are some regulations around this that are nation specific, and I think we don't need the IETF to wade into trying to figure out how to meet those regulations. In most cases, we don't really know how the regulator intends the regulations to cover devices on the Internet. Brian On 10/30/09 1:46 PM, "Marc Linsner" wrote: > Brian, > > "Normal Call Path" was NOT added to phonebcp for the purpose of the > perceived security you describe. The advantage (and the reason it's in > phonebcp) to using the normal call path is due to it being the most likely > mechanism to work. Unused/untested mechanisms are more likely to fail when > tried for the first time verses mechanisms that are used/tested daily. > Emergency time is not the time to test a new mechanism, hence use the normal > call path, the same one you just used to call grandma, to summons emergency > assistance. (This is a negative against this proposed mechanism.) > > If you are evangelizing within the PS community that 'sip:johnny@att.com' is > less of a threat than 'sip:johnny@vanitydomain.com', I suggest that is the > wrong message to be spreading. Please stop now. This will only lead to the > thousands of personal injury lawyers making big $$ at the expense of the PS > community. > > As you are intimately aware, there are millions of 'vanity' domains in use > and it's growing. Its growing not just in the individual market, but in the > small/medium business market. You also know there are thousands of hosting > companies providing services to the owners of vanity domains (email, web, > ftp, etc.). I expect in the near future that hosting providers will add sip > proxy services to their list of wares. > > My guess would be that PS officials would like to treat their customer known > as -'sip:johnny@vanitydomain.com' the same as their customer known as > -'sip:johnny@att.com'. The domain name does not dictate the level of > urgency in the request for emergency assistance, nor the veracity of the > caller. > > When an overload of the ESInet exists, I would suggest to look for other > parameters to use in decision process of how to populate the various queues. > > - Are the calls from all the same location? > - Is it reasonable that the IP address/network can be at the reported > location? > - How many calls have we received over a period of time from this AOR? IP > address/network? Location? > > Simply using the domain/AOR as the black and white rule, as you suggest, > will lead to big problems. > > Just my opinion, > > -Marc- > > On 10/30/09 9:47 AM, "Brian Rosen" wrote: > >> I want it to say MUST NOT use that mechanism :) >> >> I don't want alternative ways to make emergency calls. I want what phonebcp >> already says: send the call on the normal path and a normal identity and >> callback (which implies using a normal registration). >> >> I understand that the local authority can disable the ESRP registration >> mechanism. If this draft goes forward against my advice, then I will ask >> that there be text that says if the registration cannot be completed, the >> device MUST NOT send emergency calls direct to that ESRP, and must use its >> normal call path for emergency calls. >> >> We can't stop calls from entering the emergency services IP network without >> passing through a service provider. I have no wish to add any mechanism >> which would attempt to do so. If it would help, I would be happy to beef >> up language in framework that discusses this problem and what "normal call >> path" means. I would even be very happy to add a item to phonebcp that says >> "if you can't make normal calls, you can't make emergency calls", although >> we might get hung up on defining "normal", because if at some time when you >> need help the only number that could actually answer your call, sent down >> the same call path as you would normally send any call, is the emergency >> service, then we want that call. >> >> We frequently use you as an example. If you have a SIP Registrar and proxy >> server in your home (or boat) and you have a phone that registers with it, >> and you normally make calls to your family and friends with that setup, then >> I suspect that there is some service provider helping your proxy server >> connect to your family and friends. We would prefer your emergency calls go >> through that service provider. However, if for some reason, your proxy >> server forwarded an emergency call direct to the ESInet, it will normally go >> through. >> >> Unfortunately for you, if someone decides to attack the emergency call >> system, and it gets overloaded for some period of time until we can mitigate >> the attack, we may have to make choices on which calls we answer and which >> ones we don't. Your call sent through your proxy server to the ESInet >> direct may get lower priority than the same call sent through the service >> provider, if we notice that most of the attack calls are coming direct from >> the Internet, rather than going through a service provider we know about. >> We're building in explicit attack mitigation strategies like that. It's not >> unreasonable: if you have 5 sources entering your network, and one of them >> is the place where all (or most) of the attack is coming from, you shut off >> that source until you have a better filter. >> >> If a whole lot of devices assume the direct path is the preferred path, that >> would be bad for them. >> >> Furthermore, there is additional data sent to the emergency system (in the >> U.S.) with the call from the service provider. That information may be >> useful in helping you. The device can actually send the information, but >> while while we are pretty sure we can get most service providers to give it >> to us, we are pessimistic most devices will. Devices that have sensors, >> where the sensor data is useful for emergency calls may very well do it. >> Medical monitoring devices for example. NENA will be asking the IETF to >> standardize this soon, so that all service providers anywhere could provide >> it to all emergency services. It has things like subscriber (as opposed to >> caller) contact data, class of service information, SP contact data, etc. >> When things go wrong, the PSAP will often contact the SP and get help. The >> SP often has tools and mechanisms that CAN help. >> >> Brian >> >> >> On 10/29/09 5:46 PM, "Marc Linsner" wrote: >> >>> Brian, >>> >>> I didn't read anything in the draft that stated devices 'should' use this >>> mechanism (if it's there, it needs removed). I read it more as a device >>> 'could' use this mechanism (as in an alternative to other mechanisms). >>> >>> Further, since the ESRP is controlled by the PSAP, it certainly would be a >>> PSAP policy decision whether to support this mechanism. As without the ESRP >>> support of unknown UA registrations, the mechanism doesn't work. >>> >>> BTW, the term 'unregistered' is not in phonebcp. I think your are >>> stretching the 'normal call path' to include registration with something(?). >>> I find nothing in phonebcp that disallows 'direct' calls to an ESRP. If I >>> contact an ESRP from my UA 'directly', as long as the PSAP can call-back >>> using the Contact header I sent in the invite and my AOR leads back to my >>> UA, I've satisfied phonebcp. >>> >>> What am I missing? >>> >>> -Marc- >>> >>> >>> On 10/29/09 4:35 PM, "Brian Rosen" wrote: >>> >>>> The IETF writing standards that describe how devices should bypass their >>>> service provider and place emergency calls direct is not a PSAP policy >>>> issue. >>>> >>>> I'm satisfied with the current -phonebcp dictum to send calls on the normal >>>> call path. For an "unregistered" device, that will not allow any "calls" >>>> including emergency calls. >>>> >>>> I discussed this draft on the NENA LTD meeting this morning. That may >>>> generate some list discussion from some PSAP people who are subscribed. I >>>> would also like to hear from more PSAP folks on this subject. >>>> >>>> Brian >>>> >>>> >>>> On 10/29/09 3:27 PM, "Marc Linsner" wrote: >>>> >>>>> These are all PSAP policy decisions. Just as it's a PSAP policy decision >>>>> to >>>>> support the suggested mechanism in the draft. Existence of the document >>>>> describing the mechanism doesn't force PSAP policy. >>>>> >>>>> I personally would like to see some PSAPs and/or PS jurisdictions line up >>>>> behind the draft before it proceeds, but I don't see any harm in it going >>>>> forward. >>>>> >>>>> Of course, I'm dreaming about this special place where a PSAP actually >>>>> wants >>>>> to enable communication with all their customers and not force them to be >>>>> a >>>>> member of a special club. >>>>> >>>>> [non-chair hat on] >>>>> >>>>> -Marc- >>>>> >>>>> >>>>> On 10/29/09 2:35 PM, "Brian Rosen" wrote: >>>>> >>>>>> Thank you. That is what I meant, and you said it better than I was going >>>>>> to. >>>>>> >>>>>> We may also have some transitive relationships: that is, if there is a >>>>>> "local" PSAP that trusts that they have done so, other PSAPs may trust >>>>>> that >>>>>> they have done so. >>>>>> >>>>>> Brian >>>>>> >>>>>> On 10/29/09 11:48 AM, "DRAGE, Keith (Keith)" >>>>>> wrote: >>>>>> >>>>>>> I suspect that what Brian is saying is that anyone can be a service >>>>>>> provider >>>>>>> (or whatever else you want to call it) in this case provided that: >>>>>>> >>>>>>> 1) they make that agreement with the PSAP providers they route >>>>>>> calls >>>>>>> to; >>>>>>> >>>>>>> 2) they authenticate the calls requests to a level of security that >>>>>>> meets >>>>>>> the PSAPs (and any legal) requirements; >>>>>>> >>>>>>> 3) the PSAP trusts that they have done so. >>>>>>> >>>>>>> While this would normally be what we would understand as public >>>>>>> telecommuncation operators, it doesn't mean they have to be. >>>>>>> >>>>>>> regards >>>>>>> >>>>>>> Keith >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>>>>>>> On Behalf Of Marc Linsner >>>>>>>> Sent: Thursday, October 29, 2009 12:32 PM >>>>>>>> To: Brian Rosen >>>>>>>> Cc: ecrit@ietf.org >>>>>>>> Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>>>>>> considered >>>>>>>> >>>>>>>> Brian, >>>>>>>> >>>>>>>> Please define what you consider to be a service provider. >>>>>>>> >>>>>>>> Is Skype a service? >>>>>>>> Is Jabber a service? >>>>>>>> Is Google Voice a service? >>>>>>>> Is mydomain.com hosted on a commercial site a service? >>>>>>>> Is mydomain.com hosted on a home server a service? >>>>>>>> Is myEnterpriseVoIP.com a service? >>>>>>>> >>>>>>>> So, what you are saying that if I can make calls via all of >>>>>>>> the above, it's OK for all of the above to contact an ESRP? >>>>>>>> >>>>>>>> Are you requiring that I have a full-time proxy on-line for >>>>>>>> mydomain.com or can I simply run a transient UA and dynamic DNS? >>>>>>>> >>>>>>>> -Marc- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 10/28/09 11:17 PM, "Brian Rosen" wrote: >>>>>>>> >>>>>>>>> I'm not worried about security by obscurity. I don't want >>>>>>>> phones (or >>>>>>>>> other >>>>>>>>> devices) built to call directly. >>>>>>>>> >>>>>>>>> -phonebcp says "send the call on your normal outbound call path". >>>>>>>>> That's what I want it to say, and I don't want it to say "send it >>>>>>>>> direct, bypass your service provider. >>>>>>>>> >>>>>>>>> I'm not stopping attack, I am stopping abuse. >>>>>>>>> >>>>>>>>> I don't want devices that are not subscribed to services to >>>>>>>> be able to >>>>>>>>> make emergency calls (that is, if they can't make "normal" >>>>>>>> calls, they >>>>>>>>> should not be able to make emergency calls). >>>>>>>>> >>>>>>>>> Brian >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/28/09 6:51 PM, "Marc Linsner" wrote: >>>>>>>>> >>>>>>>>>> Brian, >>>>>>>>>> >>>>>>>>>> What I hear you saying: 'if we don't document how to spoof a PSAP, >>>>>>>>>> then nobody will figure it out.' Isn't that a little >>>>>>>> short sighted? >>>>>>>>>> >>>>>>>>>> Joey@miscreant.org will figure out how to establish a SIP session >>>>>>>>>> with any PSAP in the world within 10 minutes of that PSAP being >>>>>>>>>> accessible via the Internet, regardless of documentation. >>>>>>>>>> >>>>>>>>>> I believe there's more harm created in not documenting this for >>>>>>>>>> John.Q.Public@ordinary_citizen.com. >>>>>>>>>> >>>>>>>>>> Granted, nobody here is looking to cause harm to a PSAP. But >>>>>>>>>> Joey@miscreant.org can certainly expend public safety resources by >>>>>>>>>> reporting a bomb threat to a local school. Should we require that >>>>>>>>>> all SIP calls to the local school come from a trusted SP? >>>>>>>> Where does it end? >>>>>>>>>> >>>>>>>>>> This isn't the way to deal with spam. >>>>>>>>>> >>>>>>>>>> -Marc- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 10/27/09 11:00 AM, "Brian Rosen" wrote: >>>>>>>>>> >>>>>>>>>>> The first goal is to prevent bad calls. >>>>>>>>>>> >>>>>>>>>>> The second goal is to indentify the source of the bad calls. >>>>>>>>>>> >>>>>>>>>>> I'm starting with the first goal. I don't want you to be able to >>>>>>>>>>> take a device out of a box, plug it into a network, and have the >>>>>>>>>>> only call you can make be an emergency call. I want the >>>>>>>> device to >>>>>>>>>>> actually "work" (as in be able to place calls to all the entities >>>>>>>>>>> that it was intended to) first, and then be able to place >>>>>>>> emergency calls. >>>>>>>>>>> >>>>>>>>>>> Please spend some time in a PSAP while a kid with a >>>>>>>> simless phone has "fun" >>>>>>>>>>> with it. Imagine how much fun the test mechanism is as >>>>>>>> opposed to >>>>>>>>>>> placing real calls. >>>>>>>>>>> >>>>>>>>>>> If we somehow get a bad call, we need to send the cops. >>>>>>>> That means >>>>>>>>>>> we need an identity (and a location). >>>>>>>>>>> >>>>>>>>>>> I think a good cert could be the basis of a good identity, if we >>>>>>>>>>> could get one. I don't see how we do that. >>>>>>>>>>> >>>>>>>>>>> Brian >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 10/27/09 10:39 AM, "Richard Barnes" wrote: >>>>>>>>>>> >>>>>>>>>>>> Brian, >>>>>>>>>>>> >>>>>>>>>>>> Is the security goal here more access control (i.e., controlling >>>>>>>>>>>> who can send calls to a PSAP) or attribution/identification for >>>>>>>>>>>> post-hoc action. >>>>>>>>>>>> >>>>>>>>>>>> If it's the latter, then ISTM that the problem can largely be >>>>>>>>>>>> reduced to having a certificate infrastructure that binds >>>>>>>>>>>> authenticated identities to real-world entities. The >>>>>>>> "extended validation" >>>>>>>>>>>> certificates that current commercial CAs issue seem to largely >>>>>>>>>>>> satisfy this requirement. >>>>>>>>>>>> >>>>>>>>>>>> --Richard >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Oct 27, 2009, at 4:31 PM, Brian Rosen wrote: >>>>>>>>>>>> >>>>>>>>>>>> Of course not all VSPs will have trust relationships with all >>>>>>>>>>>> PSAPs. One can hope that long term, we can evolve to >>>>>>>> transitive >>>>>>>>>>>> trust relationships that work pretty well cross border. >>>>>>>>>>>> >>>>>>>>>>>> The emergency guys are actually terrified of private/individual >>>>>>>>>>>> domains sending them calls, and we're telling them we >>>>>>>> expect that >>>>>>>>>>>> to be possible, but rare, and we're giving them mechanisms that >>>>>>>>>>>> will effectively allow them to turn off calls >>>>>>>> selectively, based >>>>>>>>>>>> on factors including what domain the call comes from. >>>>>>>> They expect >>>>>>>>>>>> that such calls will be one of the loopholes where they get >>>>>>>>>>>> equivalents to sim-less calls, which drive them nuts. >>>>>>>> They don't >>>>>>>>>>>> want ANY calls that don't come from service providers, although >>>>>>>>>>>> they seem to be okay with the notion that the SP may not have >>>>>>>>>>>> great identity (AOL being a poster child). So, while >>>>>>>> indeed they >>>>>>>>>>>> understand, and have concerns about having to take calls from >>>>>>>>>>>> Sierra Leone VoIP services Pty, they would much rather >>>>>>>> have a call >>>>>>>>>>>> that went through them then a call that went through no service >>>>>>>>>>>> provider at all. >>>>>>>>>>>> >>>>>>>>>>>> I'm not trying to make calls direct from devices or private >>>>>>>>>>>> domains impossible, but I think the notion that we're promoting >>>>>>>>>>>> them is a very bad idea until we have effective mechanisms to >>>>>>>>>>>> prevent abuse. >>>>>>>>>>>> >>>>>>>>>>>> Brian >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/27/09 9:02 AM, "Marc Linsner" wrote: >>>>>>>>>>>> >>>>>>>>>>>> Brian, >>>>>>>>>>>> >>>>>>>>>>>> I'm a little confused. I don't remember you objecting to >>>>>>>>>>>> requirement RE1 from RFC5012 and I remember your use >>>>>>>> case about a >>>>>>>>>>>> Sierra Leone VSP. >>>>>>>>>>>> >>>>>>>>>>>> Are you implying that *all* VSPs will have a trust >>>>>>>> relationships >>>>>>>>>>>> with *all* PSAPs? >>>>>>>>>>>> >>>>>>>>>>>> What is the difference between a call coming from a private/ >>>>>>>>>>>> individual domain (as in not a commercial VSP) and a >>>>>>>> VSP on the >>>>>>>>>>>> other side of the world (outside the jurisdiction)? >>>>>>>>>>>> >>>>>>>>>>>> I'm trying to figure out whether you're objecting to anonymous >>>>>>>>>>>> calls to the PSAP or the mechanisms proposed in this draft? >>>>>>>>>>>> >>>>>>>>>>>> [Don't take this as my endorsement of the draft, as >>>>>>>> I'm not sure >>>>>>>>>>>> I agree with UAs registering with the ESRP.] >>>>>>>>>>>> >>>>>>>>>>>> -Marc- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/26/09 8:59 PM, "Brian Rosen" wrote: >>>>>>>>>>>> >>>>>>>>>>>> First of all, I put it on the wrong email list, sorry >>>>>>>> about that. >>>>>>>>>>>> >>>>>>>>>>>> Then, we have carefully arranged it so that there is >>>>>>>> no identity >>>>>>>>>>>> coming from the access network provider, and because the >>>>>>>>>>>> location is coming from that provider, we really >>>>>>>> don't want to. >>>>>>>>>>>> But even if we did, we would need a really good >>>>>>>> identifier, and >>>>>>>>>>>> there isn't one. >>>>>>>>>>>> >>>>>>>>>>>> The problem we have with -direct is anonymous callers, and if >>>>>>>>>>>> they have any option, they would also be >>>>>>>> location-less. Until >>>>>>>>>>>> and unless we get rid of anonymity, we can't >>>>>>>> encourage service >>>>>>>>>>>> provider-less calls. The draft does not make any >>>>>>>> provision to >>>>>>>>>>>> provide any kind of identity. Many networks (think free wifi >>>>>>>>>>>> for example) would make providing good identity difficult. >>>>>>>>>>>> >>>>>>>>>>>> The fact is that there is a SERVICE provider in >>>>>>>> nearly all of the >>>>>>>>>>>> communications systems. The SERVICE provider is in >>>>>>>> a position to >>>>>>>>>>>> assist >>>>>>>>>>>> the emergency calling system when it needs more information. >>>>>>>>>>>> That's what a >>>>>>>>>>>> good SERVICE provider does. Cutting them out is not a great >>>>>>>>>>>> idea. Most of the attempts to provide real time >>>>>>>> communications >>>>>>>>>>>> between people have evolved to using service providers, even >>>>>>>>>>>> when there were alternatives. File transfer via >>>>>>>> something like >>>>>>>>>>>> Torrent is a counterexample (which isn't real time), but even >>>>>>>>>>>> there, you end up with service providers like The Pirate Bay >>>>>>>>>>>> (R.I.P) to provide introduction services. I don't >>>>>>>> think we're >>>>>>>>>>>> going to see changes that eliminate service providers, and in >>>>>>>>>>>> this case, they provide value to the emergency >>>>>>>> calling systems. >>>>>>>>>>>> All of the emergency professionals I know have issues with >>>>>>>>>>>> service providers, but they would react with horror if you >>>>>>>>>>>> suggested cutting them out. Ask them, please. >>>>>>>>>>>> >>>>>>>>>>>> So, I claim you have a solution in search of a >>>>>>>> problem. We have >>>>>>>>>>>> solved the "calling network isn't the access network" problem >>>>>>>>>>>> already. Service providers ARE in the path now, in >>>>>>>> nearly every >>>>>>>>>>>> case (in fact a counter example escapes me, although there >>>>>>>>>>>> probably are some). There is no movement I can detect which >>>>>>>>>>>> would change that any time soon; quite the opposite. >>>>>>>> We have a >>>>>>>>>>>> known killer problem without some kind of subscription to a >>>>>>>>>>>> service that provides a good identity, for which you >>>>>>>> provide no >>>>>>>>>>>> answers. >>>>>>>>>>>> We have >>>>>>>>>>>> experience with the killer problem: sim-less calling was >>>>>>>>>>>> supposed to provide a way to make an emergency call >>>>>>>> in exactly >>>>>>>>>>>> the kinds of circumstances you are describing. Our >>>>>>>> real world >>>>>>>>>>>> experience is that you create a huge problem that diverts >>>>>>>>>>>> resources from helping people to chasing scammers and >>>>>>>>>>>> flea-market sellers. >>>>>>>>>>>> >>>>>>>>>>>> Nothing is perfect: you can get a AIM screen name >>>>>>>> without a very >>>>>>>>>>>> good identity for example. However, the notion that >>>>>>>> we're going >>>>>>>>>>>> to provide direct access without a service provider >>>>>>>>>>>> deliberately, especially without really good identity >>>>>>>> from the >>>>>>>>>>>> access network is, in my opinion not only a no, it's >>>>>>>> a heck no. >>>>>>>>>>>> I'll line up as many emergency service professionals as you >>>>>>>>>>>> would like to tell you this is a harmful idea. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/26/09 7:56 PM, "Dawson, Martin" >>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> I am glad this has come up. It's a debate that has >>>>>>>> to happen if >>>>>>>>>>>> we are to move beyond a long standing legacy misconception. >>>>>>>>>>>> >>>>>>>>>>>> In the circuit service world - whether it was POTS >>>>>>>> or mobile, >>>>>>>>>>>> the access network had full responsibility for >>>>>>>> delivering the >>>>>>>>>>>> emergency call. In that world, routing an emergency >>>>>>>> call meant >>>>>>>>>>>> getting a circuit established to the correct call center. In >>>>>>>>>>>> most parts of the world, this was done using the >>>>>>>> regional part >>>>>>>>>>>> of the PSTN to switch the circuit to a call center >>>>>>>> on the PSTN. >>>>>>>>>>>> In some jurisdictions, such as the US, it was done directly >>>>>>>>>>>> from the local exchange carrier to the call center. >>>>>>>> Either way, >>>>>>>>>>>> there was no third party involved. >>>>>>>>>>>> >>>>>>>>>>>> Now we have the Internet. We still have public >>>>>>>> access network >>>>>>>>>>>> providers. >>>>>>>>>>>> They >>>>>>>>>>>> switch packets onto the Internet for their subscribers. They >>>>>>>>>>>> can similarly ensure that packets reach the local emergency >>>>>>>>>>>> call centers. >>>>>>>>>>>> >>>>>>>>>>>> The fact is that there was no equivalent of a VSP in the >>>>>>>>>>>> traditional environment. VoIP is a presence service, >>>>>>>> and it had >>>>>>>>>>>> no common equivalent in the PSTN world. It could >>>>>>>> have, but the >>>>>>>>>>>> narrowband state of technology and the common market >>>>>>>> use cases >>>>>>>>>>>> didn't support its development. By the time ISDN >>>>>>>> arrived, the >>>>>>>>>>>> PSTN had already slipped into its palliative stage without >>>>>>>>>>>> realizing it. >>>>>>>>>>>> >>>>>>>>>>>> It's an entrenched misconception that because the circuit >>>>>>>>>>>> service provided by exchange carriers was most commonly used >>>>>>>>>>>> for "voice" (but, it should be noted, also for fax, >>>>>>>> telex, tty, >>>>>>>>>>>> security system monitoring and, even, IP data) that VSPs are >>>>>>>>>>>> somehow equivalent to exchange carriers. They are not. >>>>>>>>>>>> >>>>>>>>>>>> Indeed, involving VSPs in emergency calls is the Internet >>>>>>>>>>>> equivalent of involving long distance providers in POTS >>>>>>>>>>>> emergency calls. They are neither necessary nor particularly >>>>>>>>>>>> helpful; they can't be guaranteed to be within the emergency >>>>>>>>>>>> jurisdiction; depending on them actually diminishes the >>>>>>>>>>>> efficacy of emergency service access. It does not help the >>>>>>>>>>>> caller, the emergency service, nor the third party >>>>>>>> to insist on >>>>>>>>>>>> the third party's involvement. >>>>>>>>>>>> >>>>>>>>>>>> It can't be helped if you have over sold the benefits of VSP >>>>>>>>>>>> involvement to yourself and others Brian. It is time >>>>>>>> to have a >>>>>>>>>>>> reasoned debate. >>>>>>>>>>>> From my >>>>>>>>>>>> perspective, the argument that there is no "subscription" >>>>>>>>>>>> involved is >>>>>>>>>>>> patently >>>>>>>>>>>> false. There has to be a subscription of some description in >>>>>>>>>>>> order to get to the Internet. Yes, there is free public >>>>>>>>>>>> Internet access (just as there are free courtesy >>>>>>>> phones on the >>>>>>>>>>>> PSTN and free access to emergency services from pay >>>>>>>> phones. All >>>>>>>>>>>> these services are still connected to the public Internet >>>>>>>>>>>> infrastructure and they all represent an "operator" >>>>>>>> with some >>>>>>>>>>>> level of information about the caller. >>>>>>>>>>>> >>>>>>>>>>>> With the over-emphasis on VSPs, what is missing from >>>>>>>> the ECRIT >>>>>>>>>>>> and i3 models is the direct interface for querying >>>>>>>> the access >>>>>>>>>>>> network for subscriber data (should it prove >>>>>>>> necessary). These >>>>>>>>>>>> models need to take the long view of how emergency >>>>>>>> calling is >>>>>>>>>>>> done in the Internet age; they should not be protracting an >>>>>>>>>>>> unnecessary reliance on VSPs. >>>>>>>>>>>> >>>>>>>>>>>> I have deleted the premature and prejudicial text from the >>>>>>>>>>>> subject heading. >>>>>>>>>>>> And I'll leave this on ECRIT as the most appropriate WG. >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> Martin >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: ecrit-bounces@ietf.org >>>>>>>> [mailto:ecrit-bounces@ietf.org] On >>>>>>>>>>>> Behalf Of Hannes Tschofenig >>>>>>>>>>>> Sent: Tuesday, 27 October 2009 8:23 AM >>>>>>>>>>>> To: ecrit@ietf.org >>>>>>>>>>>> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>>>>>>>>>> considered harmful, at least given our current experiences >>>>>>>>>>>> >>>>>>>>>>>> FYI: feedback from Brian regarding a recent ECRIT >>>>>>>> contribution. >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: geopriv-bounces@ietf.org >>>>>>>>>>>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian >>>>>>>>>>>> Sent: 26 October, 2009 23:10 >>>>>>>>>>>> To: geopriv@ietf.org >>>>>>>>>>>> Subject: [Geopriv] Winterbottom-ecrit-direct considered >>>>>>>>>>>> harmful, at least given our current experiences >>>>>>>>>>>> >>>>>>>>>>>> The notion behind -direct is to not use a service >>>>>>>> provider to >>>>>>>>>>>> place an emergency call. Instead, the device >>>>>>>> registers with >>>>>>>>>>>> an Emergency Services Routing Proxy immediately before the >>>>>>>>>>>> call and the call is routed directly from the >>>>>>>> device to the ESRP. >>>>>>>>>>>> >>>>>>>>>>>> At least at the moment, this is an exceedingly bad idea. >>>>>>>>>>>> >>>>>>>>>>>> Emergency calling authorities like service providers, a lot. >>>>>>>>>>>> They like them because they can hold them >>>>>>>> accountable, and the >>>>>>>>>>>> service providers don't like theft of service, which is >>>>>>>>>>>> something the emergency call guys have an analog to. >>>>>>>>>>>> >>>>>>>>>>>> The facts are that where unaccountable access to emergency >>>>>>>>>>>> calling is allowed, huge numbers of false calls >>>>>>>> occur, with no >>>>>>>>>>>> way to stop them, and no way to tell the good ones from the >>>>>>>>>>>> bad ones. This has been seen multiple times where >>>>>>>> so called >>>>>>>>>>>> "simless" or "unauthenticated" calls are allowed. >>>>>>>>>>>> >>>>>>>>>>>> -direct precisely duplicates simless calling. The only >>>>>>>>>>>> "registration" is an emergency registration, only emergency >>>>>>>>>>>> calls are allowed, any device can make an emergency call if >>>>>>>>>>>> all it has is a (radio) connection to any network. >>>>>>>>>>>> We can predict, with a very high degree of >>>>>>>> certainty, that the >>>>>>>>>>>> feature will be horribly abused: for example to test that a >>>>>>>>>>>> phone without a service plan works. >>>>>>>>>>>> >>>>>>>>>>>> There have been studies which show tens of thousands of bad >>>>>>>>>>>> calls with zero good ones. Nearly every authority I know >>>>>>>>>>>> where the regulator has insisted on simless calling >>>>>>>> wants it >>>>>>>>>>>> repealed. There is one counter example I know >>>>>>>> where the fact >>>>>>>>>>>> that they got a couple, literally, of good calls among the >>>>>>>>>>>> tens of thousands of bad calls was considered >>>>>>>> enough reason to >>>>>>>>>>>> put up with the problem. >>>>>>>>>>>> >>>>>>>>>>>> Service providers give us information that may be useful: a >>>>>>>>>>>> subscriber name and address for example, which is not >>>>>>>>>>>> spoofable by the caller. They have ways to trace callers, >>>>>>>>>>>> especially bad callers. They don't want their >>>>>>>> systems abused >>>>>>>>>>>> any more than the emergency calling authorities do. >>>>>>>>>>>> >>>>>>>>>>>> This is a bad idea. A very bad idea. Please stop it. >>>>>>>>>>>> >>>>>>>>>>>> Someday, we may have better ways to prevent abuse. Until we >>>>>>>>>>>> do, service providers are a good thing on an emergency call. >>>>>>>>>>>> We don't want them cut out. >>>>>>>>>>>> >>>>>>>>>>>> Brian >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Geopriv mailing list >>>>>>>>>>>> Geopriv@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 Martin.Dawson@andrew.com Fri Oct 30 18:27:23 2009 Return-Path: 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 43B253A6946 for ; Fri, 30 Oct 2009 18:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 aggj6xTLeayN for ; Fri, 30 Oct 2009 18:27:22 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.243]) by core3.amsl.com (Postfix) with ESMTP id 25FF73A6781 for ; Fri, 30 Oct 2009 18:27:22 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:58070 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S4892981AbZJaB1j convert rfc822-to-8bit (ORCPT ); Fri, 30 Oct 2009 20:27:39 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Fri, 30 Oct 2009 20:27:39 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Sat, 31 Oct 2009 09:27:34 +0800 From: "Dawson, Martin" To: Marc Linsner , Brian Rosen Date: Sat, 31 Oct 2009 09:27:29 +0800 Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4AE1y5CAAGs5+wAAX4z4UAAdMnZQACY9dzAAJ55ZEAIY7SzwAIVkuoAAGCY3EAA610LgABbAmuAAKt540ABoUEYA== Message-ID: <8B0A9FCBB9832F43971E38010638454F0F251C35@SISPE7MB1.commscope.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Dawson@andrew.com Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Sat, 31 Oct 2009 01:27:23 -0000 Indeed - and I think this actually militates against the only other argument for using the "normal" call path as described in phone BCP. "Normal" is effectively meaningless. Further, the proposition that this results in a more robust implementation is highly questionable. On the one hand, there are multiple manifestations of VSPs using proprietary client protocols, semi-proprietary protocols, and some standards compliant protocols, and you have them operating out of globally diverse jurisdictions. What's important is what happens when the call gets routed to the ESRP. This isn't a "normal" use case in the context of those services - so where's the guarantee that they will work with arbitrary ESRP implementations when that moment comes? On the other hand, there's the possibility of an ECRIT-specific client implementation that can be embedded at the OS level. This can be implemented to a reference design made to work with the reference ESRP design. It can be solved once at the device OS level and not have a dependency on arbitrary "VSP" approaches into the future. I argue that this is a more robust approach to the reliability of emergency call client and server behaviour. Cheers, Martin -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner Sent: Saturday, 31 October 2009 9:12 AM To: Brian Rosen Cc: ecrit@ietf.org Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered It's not that I necessarily believe there will be a lack of SPs. I believe the mix of SPs and the products they offer will change dramatically at a pace that PSAPs won't be able to keep up. This week Google, next week Noggle, the next week Boogle, etc. If in fact the PSAP requires relationships with every SP that may send an emergency call their way, it will only stifle innovation. -Marc- On 10/30/09 4:55 PM, "Brian Rosen" wrote: > There is way too much speculation here. > > You are speculating that there will be interesting services without service > providers that have two way interactive media, where the identity of the > callers is a simple domain name, emergency calls from those devices is > interesting, they can't provide a suitable callback without a registration > from the ESRP, and such calls wont be the preferred abuse call source. > > When we have that problem, if we ever have that problem, we'll solve it. > > Right now, the simpler case of a direct call from an unknown source because > you have a proxy server in your boat will get through just fine nearly all > the time. When it doesn't, it will be because that path is being used by > someone attacking, and the lack of a service provider will probably be to > the disadvantage of the direct caller. I'm not going to lose sleep over > that problem. I'd rather beef up the system so we don't have to drop calls > when we're attacked. OTOH, I don't want to promote the proxy server in the > boat idea. If it happens occasionally, we'll cope. > > Brian > > > On 10/30/09 4:14 PM, "Marc Linsner" wrote: > >> >> >> On 10/30/09 2:29 PM, "Brian Rosen" wrote: >> >>> I'm the messenger here. PSAPs prefer service providers to be on the path of >>> a call, and they have bad experiences when they aren't. >>> >>> Given their experiences, I can't fault them. >>> >>> The reason the text is in phonebcp is as you said it is: because "normal" is >>> likely to work. The fact that "normal" means SP path in 99.999% of cases >>> gets the PSAPs what they want. They don't care about why we did it, they >>> care they get the right result. >> >> I, like others, believe the role/definition of the 'SP', as currently >> defined by the PSAPs, will change significantly going forward. >> >>> >>> I don't believe we are going to see vanity domains used on calls, and even >>> if they were in "From", they won't be the domain in P-Asserted-Identity, or >>> the SubjectAltName of the Identity signature. If some service that used >>> email addresses as identities sent us calls, the email address (with its >>> domain) is the "userpart" of the identity, not the whole thing. There are >>> some interesting problems when you have URI to something like the MS IM >>> systems. The first "@' (br@brianrosen.net@msn.com) gets escaped. We've >>> built systems that handle that. >> >> I think this is a little short-sighted. Certificates for vanity domains are >> certainly doable. Besides P-Asserted-Identity is not a MUST in phonebcp. >> :^) >> >>> >>> The Firewall/Session Border controls will have several criteria when PSAPs >>> are overloaded, but AFAIK, no existing firewalls or SBCs do what you suggest >>> other than the repeat offender rule, which is the first line of defense. >>> They do filter based on criteria that equate to IP Address or Domain of the >>> SP, which we can deal with. We'll use what works for the other users of >>> these systems, we're unlikely to be able to have emergency services special >>> firewalls or SBCs. >> >> We're not talking about existing firewalls and SBCs. We're talking about >> ESInet Border Control Function. If you don't define what you want there, >> you'll live with what you get. My suggestions are not beyond what's >> possible, it's all software. >> >> -Marc- >> >> >> >> > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From mlinsner@cisco.com Sat Oct 31 05:54:37 2009 Return-Path: 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 3B08E3A68A0 for ; Sat, 31 Oct 2009 05:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.458 X-Spam-Level: X-Spam-Status: No, score=-6.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 yvLBPTWnC+x9 for ; Sat, 31 Oct 2009 05:54:36 -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 2FBFC3A659B for ; Sat, 31 Oct 2009 05:54:36 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABbQ60qrR7Ht/2dsb2JhbADEXpgRgjYGgX4EjAM X-IronPort-AV: E=Sophos;i="4.44,658,1249257600"; d="scan'208";a="264269923" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 31 Oct 2009 12:54:54 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9VCsrYB007348; Sat, 31 Oct 2009 12:54:54 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.3959); Sat, 31 Oct 2009 08:54:53 -0400 Received: from [10.116.195.121] ([10.116.195.121]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 31 Oct 2009 08:54:52 -0400 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Sat, 31 Oct 2009 08:54:51 -0400 From: Marc Linsner To: Brian Rosen , "ecrit@ietf.org" Message-ID: Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4AE1y5CAAGs5+wAAX4z4UAAdMnZQACY9dzAAJ55ZEAIY7SzwAIVkuoAAGCY3EAA610LgABbAmuAAKt540AAQTFywAdzpZY In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 31 Oct 2009 12:54:52.0992 (UTC) FILETIME=[56CD1400:01CA5A29] Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Sat, 31 Oct 2009 12:54:37 -0000 On 10/30/09 6:41 PM, "Brian Rosen" wrote: > I don't see that as a big problem. There aren't going to be thousands of > such successful service providers. It usually quickly settles Darwinian > style to one or two. When the PSAPs see a bunch of calls from some new > source, they will call them up, and get them on the "we know you" list. No > big deal. > > You are still speculating about something that hasn't happened, and you > can't find a good predecessor. The latest "thing" is the social newtworks, > there were maybe 50 of them, and now there are maybe 5 or 6 that matter. Exactly my point. In the scenario you've painted, the PSAP is going to evaluate the validity/urgency of the request for emergency assistance differently for their customers (as in the PSAP's customer) that chose to use social network 7-50 verses 1-6. Please explain how my emergency is lesser of a priority because I buy services from social network provider #29. This is not the right tool for the PSAP to use for this purpose. Simply stating these are the only tools available is not good enough. -Marc- > > Brian > > > On 10/30/09 6:12 PM, "Marc Linsner" wrote: > >> It's not that I necessarily believe there will be a lack of SPs. I believe >> the mix of SPs and the products they offer will change dramatically at a >> pace that PSAPs won't be able to keep up. This week Google, next week >> Noggle, the next week Boogle, etc. If in fact the PSAP requires >> relationships with every SP that may send an emergency call their way, it >> will only stifle innovation. >> >> -Marc- >> >> >> On 10/30/09 4:55 PM, "Brian Rosen" wrote: >> >>> There is way too much speculation here. >>> >>> You are speculating that there will be interesting services without service >>> providers that have two way interactive media, where the identity of the >>> callers is a simple domain name, emergency calls from those devices is >>> interesting, they can't provide a suitable callback without a registration >>> from the ESRP, and such calls wont be the preferred abuse call source. >>> >>> When we have that problem, if we ever have that problem, we'll solve it. >>> >>> Right now, the simpler case of a direct call from an unknown source because >>> you have a proxy server in your boat will get through just fine nearly all >>> the time. When it doesn't, it will be because that path is being used by >>> someone attacking, and the lack of a service provider will probably be to >>> the disadvantage of the direct caller. I'm not going to lose sleep over >>> that problem. I'd rather beef up the system so we don't have to drop calls >>> when we're attacked. OTOH, I don't want to promote the proxy server in the >>> boat idea. If it happens occasionally, we'll cope. >>> >>> Brian >>> >>> >>> On 10/30/09 4:14 PM, "Marc Linsner" wrote: >>> >>>> >>>> >>>> On 10/30/09 2:29 PM, "Brian Rosen" wrote: >>>> >>>>> I'm the messenger here. PSAPs prefer service providers to be on the path >>>>> of >>>>> a call, and they have bad experiences when they aren't. >>>>> >>>>> Given their experiences, I can't fault them. >>>>> >>>>> The reason the text is in phonebcp is as you said it is: because "normal" >>>>> is >>>>> likely to work. The fact that "normal" means SP path in 99.999% of cases >>>>> gets the PSAPs what they want. They don't care about why we did it, they >>>>> care they get the right result. >>>> >>>> I, like others, believe the role/definition of the 'SP', as currently >>>> defined by the PSAPs, will change significantly going forward. >>>> >>>>> >>>>> I don't believe we are going to see vanity domains used on calls, and even >>>>> if they were in "From", they won't be the domain in P-Asserted-Identity, >>>>> or >>>>> the SubjectAltName of the Identity signature. If some service that used >>>>> email addresses as identities sent us calls, the email address (with its >>>>> domain) is the "userpart" of the identity, not the whole thing. There are >>>>> some interesting problems when you have URI to something like the MS IM >>>>> systems. The first "@' (br@brianrosen.net@msn.com) gets escaped. We've >>>>> built systems that handle that. >>>> >>>> I think this is a little short-sighted. Certificates for vanity domains >>>> are >>>> certainly doable. Besides P-Asserted-Identity is not a MUST in phonebcp. >>>> :^) >>>> >>>>> >>>>> The Firewall/Session Border controls will have several criteria when PSAPs >>>>> are overloaded, but AFAIK, no existing firewalls or SBCs do what you >>>>> suggest >>>>> other than the repeat offender rule, which is the first line of defense. >>>>> They do filter based on criteria that equate to IP Address or Domain of >>>>> the >>>>> SP, which we can deal with. We'll use what works for the other users of >>>>> these systems, we're unlikely to be able to have emergency services >>>>> special >>>>> firewalls or SBCs. >>>> >>>> We're not talking about existing firewalls and SBCs. We're talking about >>>> ESInet Border Control Function. If you don't define what you want there, >>>> you'll live with what you get. My suggestions are not beyond what's >>>> possible, it's all software. >>>> >>>> -Marc- >>>> >>>> >>>> >>>> >>> >>> >> >> > > From br@brianrosen.net Sat Oct 31 06:42:51 2009 Return-Path: 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 64D5D3A680C for ; Sat, 31 Oct 2009 06:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.269 X-Spam-Level: X-Spam-Status: No, score=-2.269 tagged_above=-999 required=5 tests=[AWL=0.330, 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 SrcgaC4dNXbZ for ; Sat, 31 Oct 2009 06:42:50 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 084893A65A6 for ; Sat, 31 Oct 2009 06:42:49 -0700 (PDT) Received: from [209.173.57.233] (helo=[192.168.130.13]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1N4EEN-0001wW-PU; Sat, 31 Oct 2009 08:43:00 -0500 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Sat, 31 Oct 2009 09:43:01 -0400 From: Brian Rosen To: Marc Linsner , "ecrit@ietf.org" Message-ID: Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4AE1y5CAAGs5+wAAX4z4UAAdMnZQACY9dzAAJ55ZEAIY7SzwAIVkuoAAGCY3EAA610LgABbAmuAAKt540AAQTFywAdzpZYAAGupcY= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Sat, 31 Oct 2009 13:42:51 -0000 You are looking for trouble when there isn't any. First of all, the latest example is that of a service provider, and not entirely p2p. That's what we expect, and we don't expect the scenario you are trying to paint. Then, ANY provider, regardless of size, should arrange to get whatever credential we end up deploying. That means: A) The devices on their network and/or their own network elements yield phonebcp compliant emergency calls B) They correctly forward such calls to the ESInet C) They include the additional information we ask for, which includes appropriate contact info It doesn't mean much more than that. It does give us some basis for making choices, when we have to make choices, about calls. And please remember, we're nearly always taking calls wherever they come from: the scenario we are spilling all these bits in the last several messages is something we hope roughly never happens, but we plan for it anyway. I think PSAPs and their contractors will be trying to be proactive about looking for calls from unknown providers, but as always, the ones with the most calls are going to get more attention than the ones who have fewer calls. That's all I meant. Actually, it occurs to me that they probably will go after providers who send calls that don't follow the rules before they go after well behaving, but unknown providers. Brian On 10/31/09 8:54 AM, "Marc Linsner" wrote: > > > > On 10/30/09 6:41 PM, "Brian Rosen" wrote: > >> I don't see that as a big problem. There aren't going to be thousands of >> such successful service providers. It usually quickly settles Darwinian >> style to one or two. When the PSAPs see a bunch of calls from some new >> source, they will call them up, and get them on the "we know you" list. No >> big deal. >> >> You are still speculating about something that hasn't happened, and you >> can't find a good predecessor. The latest "thing" is the social newtworks, >> there were maybe 50 of them, and now there are maybe 5 or 6 that matter. > > Exactly my point. In the scenario you've painted, the PSAP is going to > evaluate the validity/urgency of the request for emergency assistance > differently for their customers (as in the PSAP's customer) that chose to > use social network 7-50 verses 1-6. Please explain how my emergency is > lesser of a priority because I buy services from social network provider > #29. This is not the right tool for the PSAP to use for this purpose. > Simply stating these are the only tools available is not good enough. > > -Marc- > >> >> Brian >> >> >> On 10/30/09 6:12 PM, "Marc Linsner" wrote: >> >>> It's not that I necessarily believe there will be a lack of SPs. I believe >>> the mix of SPs and the products they offer will change dramatically at a >>> pace that PSAPs won't be able to keep up. This week Google, next week >>> Noggle, the next week Boogle, etc. If in fact the PSAP requires >>> relationships with every SP that may send an emergency call their way, it >>> will only stifle innovation. >>> >>> -Marc- >>> >>> >>> On 10/30/09 4:55 PM, "Brian Rosen" wrote: >>> >>>> There is way too much speculation here. >>>> >>>> You are speculating that there will be interesting services without service >>>> providers that have two way interactive media, where the identity of the >>>> callers is a simple domain name, emergency calls from those devices is >>>> interesting, they can't provide a suitable callback without a registration >>>> from the ESRP, and such calls wont be the preferred abuse call source. >>>> >>>> When we have that problem, if we ever have that problem, we'll solve it. >>>> >>>> Right now, the simpler case of a direct call from an unknown source because >>>> you have a proxy server in your boat will get through just fine nearly all >>>> the time. When it doesn't, it will be because that path is being used by >>>> someone attacking, and the lack of a service provider will probably be to >>>> the disadvantage of the direct caller. I'm not going to lose sleep over >>>> that problem. I'd rather beef up the system so we don't have to drop calls >>>> when we're attacked. OTOH, I don't want to promote the proxy server in the >>>> boat idea. If it happens occasionally, we'll cope. >>>> >>>> Brian >>>> >>>> >>>> On 10/30/09 4:14 PM, "Marc Linsner" wrote: >>>> >>>>> >>>>> >>>>> On 10/30/09 2:29 PM, "Brian Rosen" wrote: >>>>> >>>>>> I'm the messenger here. PSAPs prefer service providers to be on the path >>>>>> of >>>>>> a call, and they have bad experiences when they aren't. >>>>>> >>>>>> Given their experiences, I can't fault them. >>>>>> >>>>>> The reason the text is in phonebcp is as you said it is: because "normal" >>>>>> is >>>>>> likely to work. The fact that "normal" means SP path in 99.999% of cases >>>>>> gets the PSAPs what they want. They don't care about why we did it, they >>>>>> care they get the right result. >>>>> >>>>> I, like others, believe the role/definition of the 'SP', as currently >>>>> defined by the PSAPs, will change significantly going forward. >>>>> >>>>>> >>>>>> I don't believe we are going to see vanity domains used on calls, and >>>>>> even >>>>>> if they were in "From", they won't be the domain in P-Asserted-Identity, >>>>>> or >>>>>> the SubjectAltName of the Identity signature. If some service that used >>>>>> email addresses as identities sent us calls, the email address (with its >>>>>> domain) is the "userpart" of the identity, not the whole thing. There >>>>>> are >>>>>> some interesting problems when you have URI to something like the MS IM >>>>>> systems. The first "@' (br@brianrosen.net@msn.com) gets escaped. We've >>>>>> built systems that handle that. >>>>> >>>>> I think this is a little short-sighted. Certificates for vanity domains >>>>> are >>>>> certainly doable. Besides P-Asserted-Identity is not a MUST in phonebcp. >>>>> :^) >>>>> >>>>>> >>>>>> The Firewall/Session Border controls will have several criteria when >>>>>> PSAPs >>>>>> are overloaded, but AFAIK, no existing firewalls or SBCs do what you >>>>>> suggest >>>>>> other than the repeat offender rule, which is the first line of defense. >>>>>> They do filter based on criteria that equate to IP Address or Domain of >>>>>> the >>>>>> SP, which we can deal with. We'll use what works for the other users of >>>>>> these systems, we're unlikely to be able to have emergency services >>>>>> special >>>>>> firewalls or SBCs. >>>>> >>>>> We're not talking about existing firewalls and SBCs. We're talking about >>>>> ESInet Border Control Function. If you don't define what you want there, >>>>> you'll live with what you get. My suggestions are not beyond what's >>>>> possible, it's all software. >>>>> >>>>> -Marc- >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > From br@brianrosen.net Sat Oct 31 07:01:43 2009 Return-Path: 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 78CED3A681A for ; Sat, 31 Oct 2009 07:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.126 X-Spam-Level: X-Spam-Status: No, score=-2.126 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] 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 JrUEiOtq8ZLo for ; Sat, 31 Oct 2009 07:01:40 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 5B9823A68A0 for ; Sat, 31 Oct 2009 07:01:40 -0700 (PDT) Received: from [209.173.57.233] (helo=[192.168.130.13]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1N4EWZ-00032L-87; Sat, 31 Oct 2009 09:01:48 -0500 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Sat, 31 Oct 2009 10:01:47 -0400 From: Brian Rosen To: "Dawson, Martin" , Marc Linsner Message-ID: Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4AE1y5CAAGs5+wAAX4z4UAAdMnZQACY9dzAAJ55ZEAIY7SzwAIVkuoAAGCY3EADhIEsAAa3yqp In-Reply-To: <8B0A9FCBB9832F43971E38010638454F0F251C34@SISPE7MB1.commscope.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Sat, 31 Oct 2009 14:01:43 -0000 There is no doubt that the PSAPs care about the access provider, because the access provider is responsible for location. They want a good identity from that location provider, and they want the data that it provides to have some kind of integrity protection. It is an advantage that the access provider is local. However, calls don't come from access providers, they come from service providers who provide some sort of real time two way media session service (recognizing that often the access network and the SP that provides the calling service are the same entity). That's the SP we're talking about. Unlike the calling network, where there is at least a rudimentary authentication system in place always, there are many access networks that have no authentication at all, which gives rise to the abuse problem that makes this idea not tenable. There is no reason to believe that is going to change. I also point out, once again, that using the access network as the source of authentication means that we are using an IP address as an identifier. IP addresses make lousy identifiers. They are addresses, not identifiers. Oh, one more thing about this idea: It means that devices have to have a SIP stack, regardless of what they actually use to place calls. That's okay for some devices, but of course there are many, many more devices and services that don't use SIP from the device to the service provider. It's one thing to say that the SP has to gateway to SIP if its devices don't already speak SIP. It's quite another to say that every device has to be able to speak SIP for emergency calls regardless of what it uses for everything else. There would be similar daunting problems for codecs. On 10/30/09 9:18 PM, "Dawson, Martin" wrote: > Hey Brian, > > Maybe if you keep saying "service provider" we'll all start believing it means > "VSP" and it really does have some quintessential significance to emergency > calling... > > However, to quote Watto (Phantom Menace): > > "What? You think you're some kind of Jedi, waving your > hand around like that?" > > :) > > Sure PSAP providers like to have a "service provider" they can point their > finger at. They like someone who might be a source of forensic information > related to the source of nuisance calls. In particular, it's really useful if > that provider is in the same jurisdiction that they are. That would be the 'I' > SP rather than the 'V' SP that you keep trying to steer the focus back to. > > Cheers, > Martin > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Brian Rosen > Sent: Saturday, 31 October 2009 5:29 AM > To: Marc Linsner > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered > > I'm the messenger here. PSAPs prefer service providers to be on the path of > a call, and they have bad experiences when they aren't. > > Given their experiences, I can't fault them. > > The reason the text is in phonebcp is as you said it is: because "normal" is > likely to work. The fact that "normal" means SP path in 99.999% of cases > gets the PSAPs what they want. They don't care about why we did it, they > care they get the right result. > > I don't believe we are going to see vanity domains used on calls, and even > if they were in "From", they won't be the domain in P-Asserted-Identity, or > the SubjectAltName of the Identity signature. If some service that used > email addresses as identities sent us calls, the email address (with its > domain) is the "userpart" of the identity, not the whole thing. There are > some interesting problems when you have URI to something like the MS IM > systems. The first "@' (br@brianrosen.net@msn.com) gets escaped. We've > built systems that handle that. > > The Firewall/Session Border controls will have several criteria when PSAPs > are overloaded, but AFAIK, no existing firewalls or SBCs do what you suggest > other than the repeat offender rule, which is the first line of defense. > They do filter based on criteria that equate to IP Address or Domain of the > SP, which we can deal with. We'll use what works for the other users of > these systems, we're unlikely to be able to have emergency services special > firewalls or SBCs. > > In most cases we're going to have hard connections, or more likely VPNs from > service providers to the ESInet routers. That will probably handle 90+ > percent of calls, but we'll still have substantial numbers coming from the > big I Internet. We do want to know where they are coming from, and we will > have SOME form of identity that we trust to separate those we know about > from those we don't. > > This is a percentages game. Most of the time, calls will be accepted no > matter how they get to the ESInet. If you want your calls to get through > when things are bad, send them the way you send all your other calls; that > will work okay. If you break that (by encouraging people to send them > direct), then we'll have more problems. > > I'm back to the basic tenet: if you can use the service to create media > sessions to others, you can use it to send emergency calls, and we want the > calls sent the same path (because it will work). If you can't use the > service (like, you can't register for one reason or another), we don't want > you to be able to make emergency calls. > > To be fair, there is at least one country I know of that doesn't agree. > They have documented a small number of good calls in with the tens of > thousands of bad ones, and think its worth it to handle the bad ones in > order to get to the good ones. Most PSAPs I know of don't. > > And furthermore, there are some regulations around this that are nation > specific, and I think we don't need the IETF to wade into trying to figure > out how to meet those regulations. In most cases, we don't really know how > the regulator intends the regulations to cover devices on the Internet. > > Brian > > On 10/30/09 1:46 PM, "Marc Linsner" wrote: > >> Brian, >> >> "Normal Call Path" was NOT added to phonebcp for the purpose of the >> perceived security you describe. The advantage (and the reason it's in >> phonebcp) to using the normal call path is due to it being the most likely >> mechanism to work. Unused/untested mechanisms are more likely to fail when >> tried for the first time verses mechanisms that are used/tested daily. >> Emergency time is not the time to test a new mechanism, hence use the normal >> call path, the same one you just used to call grandma, to summons emergency >> assistance. (This is a negative against this proposed mechanism.) >> >> If you are evangelizing within the PS community that 'sip:johnny@att.com' is >> less of a threat than 'sip:johnny@vanitydomain.com', I suggest that is the >> wrong message to be spreading. Please stop now. This will only lead to the >> thousands of personal injury lawyers making big $$ at the expense of the PS >> community. >> >> As you are intimately aware, there are millions of 'vanity' domains in use >> and it's growing. Its growing not just in the individual market, but in the >> small/medium business market. You also know there are thousands of hosting >> companies providing services to the owners of vanity domains (email, web, >> ftp, etc.). I expect in the near future that hosting providers will add sip >> proxy services to their list of wares. >> >> My guess would be that PS officials would like to treat their customer known >> as -'sip:johnny@vanitydomain.com' the same as their customer known as >> -'sip:johnny@att.com'. The domain name does not dictate the level of >> urgency in the request for emergency assistance, nor the veracity of the >> caller. >> >> When an overload of the ESInet exists, I would suggest to look for other >> parameters to use in decision process of how to populate the various queues. >> >> - Are the calls from all the same location? >> - Is it reasonable that the IP address/network can be at the reported >> location? >> - How many calls have we received over a period of time from this AOR? IP >> address/network? Location? >> >> Simply using the domain/AOR as the black and white rule, as you suggest, >> will lead to big problems. >> >> Just my opinion, >> >> -Marc- >> >> On 10/30/09 9:47 AM, "Brian Rosen" wrote: >> >>> I want it to say MUST NOT use that mechanism :) >>> >>> I don't want alternative ways to make emergency calls. I want what phonebcp >>> already says: send the call on the normal path and a normal identity and >>> callback (which implies using a normal registration). >>> >>> I understand that the local authority can disable the ESRP registration >>> mechanism. If this draft goes forward against my advice, then I will ask >>> that there be text that says if the registration cannot be completed, the >>> device MUST NOT send emergency calls direct to that ESRP, and must use its >>> normal call path for emergency calls. >>> >>> We can't stop calls from entering the emergency services IP network without >>> passing through a service provider. I have no wish to add any mechanism >>> which would attempt to do so. If it would help, I would be happy to beef >>> up language in framework that discusses this problem and what "normal call >>> path" means. I would even be very happy to add a item to phonebcp that says >>> "if you can't make normal calls, you can't make emergency calls", although >>> we might get hung up on defining "normal", because if at some time when you >>> need help the only number that could actually answer your call, sent down >>> the same call path as you would normally send any call, is the emergency >>> service, then we want that call. >>> >>> We frequently use you as an example. If you have a SIP Registrar and proxy >>> server in your home (or boat) and you have a phone that registers with it, >>> and you normally make calls to your family and friends with that setup, then >>> I suspect that there is some service provider helping your proxy server >>> connect to your family and friends. We would prefer your emergency calls go >>> through that service provider. However, if for some reason, your proxy >>> server forwarded an emergency call direct to the ESInet, it will normally go >>> through. >>> >>> Unfortunately for you, if someone decides to attack the emergency call >>> system, and it gets overloaded for some period of time until we can mitigate >>> the attack, we may have to make choices on which calls we answer and which >>> ones we don't. Your call sent through your proxy server to the ESInet >>> direct may get lower priority than the same call sent through the service >>> provider, if we notice that most of the attack calls are coming direct from >>> the Internet, rather than going through a service provider we know about. >>> We're building in explicit attack mitigation strategies like that. It's not >>> unreasonable: if you have 5 sources entering your network, and one of them >>> is the place where all (or most) of the attack is coming from, you shut off >>> that source until you have a better filter. >>> >>> If a whole lot of devices assume the direct path is the preferred path, that >>> would be bad for them. >>> >>> Furthermore, there is additional data sent to the emergency system (in the >>> U.S.) with the call from the service provider. That information may be >>> useful in helping you. The device can actually send the information, but >>> while while we are pretty sure we can get most service providers to give it >>> to us, we are pessimistic most devices will. Devices that have sensors, >>> where the sensor data is useful for emergency calls may very well do it. >>> Medical monitoring devices for example. NENA will be asking the IETF to >>> standardize this soon, so that all service providers anywhere could provide >>> it to all emergency services. It has things like subscriber (as opposed to >>> caller) contact data, class of service information, SP contact data, etc. >>> When things go wrong, the PSAP will often contact the SP and get help. The >>> SP often has tools and mechanisms that CAN help. >>> >>> Brian >>> >>> >>> On 10/29/09 5:46 PM, "Marc Linsner" wrote: >>> >>>> Brian, >>>> >>>> I didn't read anything in the draft that stated devices 'should' use this >>>> mechanism (if it's there, it needs removed). I read it more as a device >>>> 'could' use this mechanism (as in an alternative to other mechanisms). >>>> >>>> Further, since the ESRP is controlled by the PSAP, it certainly would be a >>>> PSAP policy decision whether to support this mechanism. As without the >>>> ESRP >>>> support of unknown UA registrations, the mechanism doesn't work. >>>> >>>> BTW, the term 'unregistered' is not in phonebcp. I think your are >>>> stretching the 'normal call path' to include registration with >>>> something(?). >>>> I find nothing in phonebcp that disallows 'direct' calls to an ESRP. If I >>>> contact an ESRP from my UA 'directly', as long as the PSAP can call-back >>>> using the Contact header I sent in the invite and my AOR leads back to my >>>> UA, I've satisfied phonebcp. >>>> >>>> What am I missing? >>>> >>>> -Marc- >>>> >>>> >>>> On 10/29/09 4:35 PM, "Brian Rosen" wrote: >>>> >>>>> The IETF writing standards that describe how devices should bypass their >>>>> service provider and place emergency calls direct is not a PSAP policy >>>>> issue. >>>>> >>>>> I'm satisfied with the current -phonebcp dictum to send calls on the >>>>> normal >>>>> call path. For an "unregistered" device, that will not allow any "calls" >>>>> including emergency calls. >>>>> >>>>> I discussed this draft on the NENA LTD meeting this morning. That may >>>>> generate some list discussion from some PSAP people who are subscribed. I >>>>> would also like to hear from more PSAP folks on this subject. >>>>> >>>>> Brian >>>>> >>>>> >>>>> On 10/29/09 3:27 PM, "Marc Linsner" wrote: >>>>> >>>>>> These are all PSAP policy decisions. Just as it's a PSAP policy decision >>>>>> to >>>>>> support the suggested mechanism in the draft. Existence of the document >>>>>> describing the mechanism doesn't force PSAP policy. >>>>>> >>>>>> I personally would like to see some PSAPs and/or PS jurisdictions line up >>>>>> behind the draft before it proceeds, but I don't see any harm in it going >>>>>> forward. >>>>>> >>>>>> Of course, I'm dreaming about this special place where a PSAP actually >>>>>> wants >>>>>> to enable communication with all their customers and not force them to be >>>>>> a >>>>>> member of a special club. >>>>>> >>>>>> [non-chair hat on] >>>>>> >>>>>> -Marc- >>>>>> >>>>>> >>>>>> On 10/29/09 2:35 PM, "Brian Rosen" wrote: >>>>>> >>>>>>> Thank you. That is what I meant, and you said it better than I was >>>>>>> going >>>>>>> to. >>>>>>> >>>>>>> We may also have some transitive relationships: that is, if there is a >>>>>>> "local" PSAP that trusts that they have done so, other PSAPs may trust >>>>>>> that >>>>>>> they have done so. >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>> On 10/29/09 11:48 AM, "DRAGE, Keith (Keith)" >>>>>>> wrote: >>>>>>> >>>>>>>> I suspect that what Brian is saying is that anyone can be a service >>>>>>>> provider >>>>>>>> (or whatever else you want to call it) in this case provided that: >>>>>>>> >>>>>>>> 1) they make that agreement with the PSAP providers they route >>>>>>>> calls >>>>>>>> to; >>>>>>>> >>>>>>>> 2) they authenticate the calls requests to a level of security >>>>>>>> that >>>>>>>> meets >>>>>>>> the PSAPs (and any legal) requirements; >>>>>>>> >>>>>>>> 3) the PSAP trusts that they have done so. >>>>>>>> >>>>>>>> While this would normally be what we would understand as public >>>>>>>> telecommuncation operators, it doesn't mean they have to be. >>>>>>>> >>>>>>>> regards >>>>>>>> >>>>>>>> Keith >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>>>>>>>> On Behalf Of Marc Linsner >>>>>>>>> Sent: Thursday, October 29, 2009 12:32 PM >>>>>>>>> To: Brian Rosen >>>>>>>>> Cc: ecrit@ietf.org >>>>>>>>> Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>>>>>>> considered >>>>>>>>> >>>>>>>>> Brian, >>>>>>>>> >>>>>>>>> Please define what you consider to be a service provider. >>>>>>>>> >>>>>>>>> Is Skype a service? >>>>>>>>> Is Jabber a service? >>>>>>>>> Is Google Voice a service? >>>>>>>>> Is mydomain.com hosted on a commercial site a service? >>>>>>>>> Is mydomain.com hosted on a home server a service? >>>>>>>>> Is myEnterpriseVoIP.com a service? >>>>>>>>> >>>>>>>>> So, what you are saying that if I can make calls via all of >>>>>>>>> the above, it's OK for all of the above to contact an ESRP? >>>>>>>>> >>>>>>>>> Are you requiring that I have a full-time proxy on-line for >>>>>>>>> mydomain.com or can I simply run a transient UA and dynamic DNS? >>>>>>>>> >>>>>>>>> -Marc- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/28/09 11:17 PM, "Brian Rosen" wrote: >>>>>>>>> >>>>>>>>>> I'm not worried about security by obscurity. I don't want >>>>>>>>> phones (or >>>>>>>>>> other >>>>>>>>>> devices) built to call directly. >>>>>>>>>> >>>>>>>>>> -phonebcp says "send the call on your normal outbound call path". >>>>>>>>>> That's what I want it to say, and I don't want it to say "send it >>>>>>>>>> direct, bypass your service provider. >>>>>>>>>> >>>>>>>>>> I'm not stopping attack, I am stopping abuse. >>>>>>>>>> >>>>>>>>>> I don't want devices that are not subscribed to services to >>>>>>>>> be able to >>>>>>>>>> make emergency calls (that is, if they can't make "normal" >>>>>>>>> calls, they >>>>>>>>>> should not be able to make emergency calls). >>>>>>>>>> >>>>>>>>>> Brian >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 10/28/09 6:51 PM, "Marc Linsner" wrote: >>>>>>>>>> >>>>>>>>>>> Brian, >>>>>>>>>>> >>>>>>>>>>> What I hear you saying: 'if we don't document how to spoof a PSAP, >>>>>>>>>>> then nobody will figure it out.' Isn't that a little >>>>>>>>> short sighted? >>>>>>>>>>> >>>>>>>>>>> Joey@miscreant.org will figure out how to establish a SIP session >>>>>>>>>>> with any PSAP in the world within 10 minutes of that PSAP being >>>>>>>>>>> accessible via the Internet, regardless of documentation. >>>>>>>>>>> >>>>>>>>>>> I believe there's more harm created in not documenting this for >>>>>>>>>>> John.Q.Public@ordinary_citizen.com. >>>>>>>>>>> >>>>>>>>>>> Granted, nobody here is looking to cause harm to a PSAP. But >>>>>>>>>>> Joey@miscreant.org can certainly expend public safety resources by >>>>>>>>>>> reporting a bomb threat to a local school. Should we require that >>>>>>>>>>> all SIP calls to the local school come from a trusted SP? >>>>>>>>> Where does it end? >>>>>>>>>>> >>>>>>>>>>> This isn't the way to deal with spam. >>>>>>>>>>> >>>>>>>>>>> -Marc- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 10/27/09 11:00 AM, "Brian Rosen" wrote: >>>>>>>>>>> >>>>>>>>>>>> The first goal is to prevent bad calls. >>>>>>>>>>>> >>>>>>>>>>>> The second goal is to indentify the source of the bad calls. >>>>>>>>>>>> >>>>>>>>>>>> I'm starting with the first goal. I don't want you to be able to >>>>>>>>>>>> take a device out of a box, plug it into a network, and have the >>>>>>>>>>>> only call you can make be an emergency call. I want the >>>>>>>>> device to >>>>>>>>>>>> actually "work" (as in be able to place calls to all the entities >>>>>>>>>>>> that it was intended to) first, and then be able to place >>>>>>>>> emergency calls. >>>>>>>>>>>> >>>>>>>>>>>> Please spend some time in a PSAP while a kid with a >>>>>>>>> simless phone has "fun" >>>>>>>>>>>> with it. Imagine how much fun the test mechanism is as >>>>>>>>> opposed to >>>>>>>>>>>> placing real calls. >>>>>>>>>>>> >>>>>>>>>>>> If we somehow get a bad call, we need to send the cops. >>>>>>>>> That means >>>>>>>>>>>> we need an identity (and a location). >>>>>>>>>>>> >>>>>>>>>>>> I think a good cert could be the basis of a good identity, if we >>>>>>>>>>>> could get one. I don't see how we do that. >>>>>>>>>>>> >>>>>>>>>>>> Brian >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/27/09 10:39 AM, "Richard Barnes" wrote: >>>>>>>>>>>> >>>>>>>>>>>> Brian, >>>>>>>>>>>> >>>>>>>>>>>> Is the security goal here more access control (i.e., controlling >>>>>>>>>>>> who can send calls to a PSAP) or attribution/identification for >>>>>>>>>>>> post-hoc action. >>>>>>>>>>>> >>>>>>>>>>>> If it's the latter, then ISTM that the problem can largely be >>>>>>>>>>>> reduced to having a certificate infrastructure that binds >>>>>>>>>>>> authenticated identities to real-world entities. The >>>>>>>>> "extended validation" >>>>>>>>>>>> certificates that current commercial CAs issue seem to largely >>>>>>>>>>>> satisfy this requirement. >>>>>>>>>>>> >>>>>>>>>>>> --Richard >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Oct 27, 2009, at 4:31 PM, Brian Rosen wrote: >>>>>>>>>>>> >>>>>>>>>>>> Of course not all VSPs will have trust relationships with all >>>>>>>>>>>> PSAPs. One can hope that long term, we can evolve to >>>>>>>>> transitive >>>>>>>>>>>> trust relationships that work pretty well cross border. >>>>>>>>>>>> >>>>>>>>>>>> The emergency guys are actually terrified of private/individual >>>>>>>>>>>> domains sending them calls, and we're telling them we >>>>>>>>> expect that >>>>>>>>>>>> to be possible, but rare, and we're giving them mechanisms that >>>>>>>>>>>> will effectively allow them to turn off calls >>>>>>>>> selectively, based >>>>>>>>>>>> on factors including what domain the call comes from. >>>>>>>>> They expect >>>>>>>>>>>> that such calls will be one of the loopholes where they get >>>>>>>>>>>> equivalents to sim-less calls, which drive them nuts. >>>>>>>>> They don't >>>>>>>>>>>> want ANY calls that don't come from service providers, although >>>>>>>>>>>> they seem to be okay with the notion that the SP may not have >>>>>>>>>>>> great identity (AOL being a poster child). So, while >>>>>>>>> indeed they >>>>>>>>>>>> understand, and have concerns about having to take calls from >>>>>>>>>>>> Sierra Leone VoIP services Pty, they would much rather >>>>>>>>> have a call >>>>>>>>>>>> that went through them then a call that went through no service >>>>>>>>>>>> provider at all. >>>>>>>>>>>> >>>>>>>>>>>> I'm not trying to make calls direct from devices or private >>>>>>>>>>>> domains impossible, but I think the notion that we're promoting >>>>>>>>>>>> them is a very bad idea until we have effective mechanisms to >>>>>>>>>>>> prevent abuse. >>>>>>>>>>>> >>>>>>>>>>>> Brian >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/27/09 9:02 AM, "Marc Linsner" wrote: >>>>>>>>>>>> >>>>>>>>>>>> Brian, >>>>>>>>>>>> >>>>>>>>>>>> I'm a little confused. I don't remember you objecting to >>>>>>>>>>>> requirement RE1 from RFC5012 and I remember your use >>>>>>>>> case about a >>>>>>>>>>>> Sierra Leone VSP. >>>>>>>>>>>> >>>>>>>>>>>> Are you implying that *all* VSPs will have a trust >>>>>>>>> relationships >>>>>>>>>>>> with *all* PSAPs? >>>>>>>>>>>> >>>>>>>>>>>> What is the difference between a call coming from a private/ >>>>>>>>>>>> individual domain (as in not a commercial VSP) and a >>>>>>>>> VSP on the >>>>>>>>>>>> other side of the world (outside the jurisdiction)? >>>>>>>>>>>> >>>>>>>>>>>> I'm trying to figure out whether you're objecting to anonymous >>>>>>>>>>>> calls to the PSAP or the mechanisms proposed in this draft? >>>>>>>>>>>> >>>>>>>>>>>> [Don't take this as my endorsement of the draft, as >>>>>>>>> I'm not sure >>>>>>>>>>>> I agree with UAs registering with the ESRP.] >>>>>>>>>>>> >>>>>>>>>>>> -Marc- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/26/09 8:59 PM, "Brian Rosen" wrote: >>>>>>>>>>>> >>>>>>>>>>>> First of all, I put it on the wrong email list, sorry >>>>>>>>> about that. >>>>>>>>>>>> >>>>>>>>>>>> Then, we have carefully arranged it so that there is >>>>>>>>> no identity >>>>>>>>>>>> coming from the access network provider, and because the >>>>>>>>>>>> location is coming from that provider, we really >>>>>>>>> don't want to. >>>>>>>>>>>> But even if we did, we would need a really good >>>>>>>>> identifier, and >>>>>>>>>>>> there isn't one. >>>>>>>>>>>> >>>>>>>>>>>> The problem we have with -direct is anonymous callers, and if >>>>>>>>>>>> they have any option, they would also be >>>>>>>>> location-less. Until >>>>>>>>>>>> and unless we get rid of anonymity, we can't >>>>>>>>> encourage service >>>>>>>>>>>> provider-less calls. The draft does not make any >>>>>>>>> provision to >>>>>>>>>>>> provide any kind of identity. Many networks (think free wifi >>>>>>>>>>>> for example) would make providing good identity difficult. >>>>>>>>>>>> >>>>>>>>>>>> The fact is that there is a SERVICE provider in >>>>>>>>> nearly all of the >>>>>>>>>>>> communications systems. The SERVICE provider is in >>>>>>>>> a position to >>>>>>>>>>>> assist >>>>>>>>>>>> the emergency calling system when it needs more information. >>>>>>>>>>>> That's what a >>>>>>>>>>>> good SERVICE provider does. Cutting them out is not a great >>>>>>>>>>>> idea. Most of the attempts to provide real time >>>>>>>>> communications >>>>>>>>>>>> between people have evolved to using service providers, even >>>>>>>>>>>> when there were alternatives. File transfer via >>>>>>>>> something like >>>>>>>>>>>> Torrent is a counterexample (which isn't real time), but even >>>>>>>>>>>> there, you end up with service providers like The Pirate Bay >>>>>>>>>>>> (R.I.P) to provide introduction services. I don't >>>>>>>>> think we're >>>>>>>>>>>> going to see changes that eliminate service providers, and in >>>>>>>>>>>> this case, they provide value to the emergency >>>>>>>>> calling systems. >>>>>>>>>>>> All of the emergency professionals I know have issues with >>>>>>>>>>>> service providers, but they would react with horror if you >>>>>>>>>>>> suggested cutting them out. Ask them, please. >>>>>>>>>>>> >>>>>>>>>>>> So, I claim you have a solution in search of a >>>>>>>>> problem. We have >>>>>>>>>>>> solved the "calling network isn't the access network" problem >>>>>>>>>>>> already. Service providers ARE in the path now, in >>>>>>>>> nearly every >>>>>>>>>>>> case (in fact a counter example escapes me, although there >>>>>>>>>>>> probably are some). There is no movement I can detect which >>>>>>>>>>>> would change that any time soon; quite the opposite. >>>>>>>>> We have a >>>>>>>>>>>> known killer problem without some kind of subscription to a >>>>>>>>>>>> service that provides a good identity, for which you >>>>>>>>> provide no >>>>>>>>>>>> answers. >>>>>>>>>>>> We have >>>>>>>>>>>> experience with the killer problem: sim-less calling was >>>>>>>>>>>> supposed to provide a way to make an emergency call >>>>>>>>> in exactly >>>>>>>>>>>> the kinds of circumstances you are describing. Our >>>>>>>>> real world >>>>>>>>>>>> experience is that you create a huge problem that diverts >>>>>>>>>>>> resources from helping people to chasing scammers and >>>>>>>>>>>> flea-market sellers. >>>>>>>>>>>> >>>>>>>>>>>> Nothing is perfect: you can get a AIM screen name >>>>>>>>> without a very >>>>>>>>>>>> good identity for example. However, the notion that >>>>>>>>> we're going >>>>>>>>>>>> to provide direct access without a service provider >>>>>>>>>>>> deliberately, especially without really good identity >>>>>>>>> from the >>>>>>>>>>>> access network is, in my opinion not only a no, it's >>>>>>>>> a heck no. >>>>>>>>>>>> I'll line up as many emergency service professionals as you >>>>>>>>>>>> would like to tell you this is a harmful idea. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/26/09 7:56 PM, "Dawson, Martin" >>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> I am glad this has come up. It's a debate that has >>>>>>>>> to happen if >>>>>>>>>>>> we are to move beyond a long standing legacy misconception. >>>>>>>>>>>> >>>>>>>>>>>> In the circuit service world - whether it was POTS >>>>>>>>> or mobile, >>>>>>>>>>>> the access network had full responsibility for >>>>>>>>> delivering the >>>>>>>>>>>> emergency call. In that world, routing an emergency >>>>>>>>> call meant >>>>>>>>>>>> getting a circuit established to the correct call center. In >>>>>>>>>>>> most parts of the world, this was done using the >>>>>>>>> regional part >>>>>>>>>>>> of the PSTN to switch the circuit to a call center >>>>>>>>> on the PSTN. >>>>>>>>>>>> In some jurisdictions, such as the US, it was done directly >>>>>>>>>>>> from the local exchange carrier to the call center. >>>>>>>>> Either way, >>>>>>>>>>>> there was no third party involved. >>>>>>>>>>>> >>>>>>>>>>>> Now we have the Internet. We still have public >>>>>>>>> access network >>>>>>>>>>>> providers. >>>>>>>>>>>> They >>>>>>>>>>>> switch packets onto the Internet for their subscribers. They >>>>>>>>>>>> can similarly ensure that packets reach the local emergency >>>>>>>>>>>> call centers. >>>>>>>>>>>> >>>>>>>>>>>> The fact is that there was no equivalent of a VSP in the >>>>>>>>>>>> traditional environment. VoIP is a presence service, >>>>>>>>> and it had >>>>>>>>>>>> no common equivalent in the PSTN world. It could >>>>>>>>> have, but the >>>>>>>>>>>> narrowband state of technology and the common market >>>>>>>>> use cases >>>>>>>>>>>> didn't support its development. By the time ISDN >>>>>>>>> arrived, the >>>>>>>>>>>> PSTN had already slipped into its palliative stage without >>>>>>>>>>>> realizing it. >>>>>>>>>>>> >>>>>>>>>>>> It's an entrenched misconception that because the circuit >>>>>>>>>>>> service provided by exchange carriers was most commonly used >>>>>>>>>>>> for "voice" (but, it should be noted, also for fax, >>>>>>>>> telex, tty, >>>>>>>>>>>> security system monitoring and, even, IP data) that VSPs are >>>>>>>>>>>> somehow equivalent to exchange carriers. They are not. >>>>>>>>>>>> >>>>>>>>>>>> Indeed, involving VSPs in emergency calls is the Internet >>>>>>>>>>>> equivalent of involving long distance providers in POTS >>>>>>>>>>>> emergency calls. They are neither necessary nor particularly >>>>>>>>>>>> helpful; they can't be guaranteed to be within the emergency >>>>>>>>>>>> jurisdiction; depending on them actually diminishes the >>>>>>>>>>>> efficacy of emergency service access. It does not help the >>>>>>>>>>>> caller, the emergency service, nor the third party >>>>>>>>> to insist on >>>>>>>>>>>> the third party's involvement. >>>>>>>>>>>> >>>>>>>>>>>> It can't be helped if you have over sold the benefits of VSP >>>>>>>>>>>> involvement to yourself and others Brian. It is time >>>>>>>>> to have a >>>>>>>>>>>> reasoned debate. >>>>>>>>>>>> From my >>>>>>>>>>>> perspective, the argument that there is no "subscription" >>>>>>>>>>>> involved is >>>>>>>>>>>> patently >>>>>>>>>>>> false. There has to be a subscription of some description in >>>>>>>>>>>> order to get to the Internet. Yes, there is free public >>>>>>>>>>>> Internet access (just as there are free courtesy >>>>>>>>> phones on the >>>>>>>>>>>> PSTN and free access to emergency services from pay >>>>>>>>> phones. All >>>>>>>>>>>> these services are still connected to the public Internet >>>>>>>>>>>> infrastructure and they all represent an "operator" >>>>>>>>> with some >>>>>>>>>>>> level of information about the caller. >>>>>>>>>>>> >>>>>>>>>>>> With the over-emphasis on VSPs, what is missing from >>>>>>>>> the ECRIT >>>>>>>>>>>> and i3 models is the direct interface for querying >>>>>>>>> the access >>>>>>>>>>>> network for subscriber data (should it prove >>>>>>>>> necessary). These >>>>>>>>>>>> models need to take the long view of how emergency >>>>>>>>> calling is >>>>>>>>>>>> done in the Internet age; they should not be protracting an >>>>>>>>>>>> unnecessary reliance on VSPs. >>>>>>>>>>>> >>>>>>>>>>>> I have deleted the premature and prejudicial text from the >>>>>>>>>>>> subject heading. >>>>>>>>>>>> And I'll leave this on ECRIT as the most appropriate WG. >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> Martin >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: ecrit-bounces@ietf.org >>>>>>>>> [mailto:ecrit-bounces@ietf.org] On >>>>>>>>>>>> Behalf Of Hannes Tschofenig >>>>>>>>>>>> Sent: Tuesday, 27 October 2009 8:23 AM >>>>>>>>>>>> To: ecrit@ietf.org >>>>>>>>>>>> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>>>>>>>>>> considered harmful, at least given our current experiences >>>>>>>>>>>> >>>>>>>>>>>> FYI: feedback from Brian regarding a recent ECRIT >>>>>>>>> contribution. >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: geopriv-bounces@ietf.org >>>>>>>>>>>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian >>>>>>>>>>>> Sent: 26 October, 2009 23:10 >>>>>>>>>>>> To: geopriv@ietf.org >>>>>>>>>>>> Subject: [Geopriv] Winterbottom-ecrit-direct considered >>>>>>>>>>>> harmful, at least given our current experiences >>>>>>>>>>>> >>>>>>>>>>>> The notion behind -direct is to not use a service >>>>>>>>> provider to >>>>>>>>>>>> place an emergency call. Instead, the device >>>>>>>>> registers with >>>>>>>>>>>> an Emergency Services Routing Proxy immediately before the >>>>>>>>>>>> call and the call is routed directly from the >>>>>>>>> device to the ESRP. >>>>>>>>>>>> >>>>>>>>>>>> At least at the moment, this is an exceedingly bad idea. >>>>>>>>>>>> >>>>>>>>>>>> Emergency calling authorities like service providers, a lot. >>>>>>>>>>>> They like them because they can hold them >>>>>>>>> accountable, and the >>>>>>>>>>>> service providers don't like theft of service, which is >>>>>>>>>>>> something the emergency call guys have an analog to. >>>>>>>>>>>> >>>>>>>>>>>> The facts are that where unaccountable access to emergency >>>>>>>>>>>> calling is allowed, huge numbers of false calls >>>>>>>>> occur, with no >>>>>>>>>>>> way to stop them, and no way to tell the good ones from the >>>>>>>>>>>> bad ones. This has been seen multiple times where >>>>>>>>> so called >>>>>>>>>>>> "simless" or "unauthenticated" calls are allowed. >>>>>>>>>>>> >>>>>>>>>>>> -direct precisely duplicates simless calling. The only >>>>>>>>>>>> "registration" is an emergency registration, only emergency >>>>>>>>>>>> calls are allowed, any device can make an emergency call if >>>>>>>>>>>> all it has is a (radio) connection to any network. >>>>>>>>>>>> We can predict, with a very high degree of >>>>>>>>> certainty, that the >>>>>>>>>>>> feature will be horribly abused: for example to test that a >>>>>>>>>>>> phone without a service plan works. >>>>>>>>>>>> >>>>>>>>>>>> There have been studies which show tens of thousands of bad >>>>>>>>>>>> calls with zero good ones. Nearly every authority I know >>>>>>>>>>>> where the regulator has insisted on simless calling >>>>>>>>> wants it >>>>>>>>>>>> repealed. There is one counter example I know >>>>>>>>> where the fact >>>>>>>>>>>> that they got a couple, literally, of good calls among the >>>>>>>>>>>> tens of thousands of bad calls was considered >>>>>>>>> enough reason to >>>>>>>>>>>> put up with the problem. >>>>>>>>>>>> >>>>>>>>>>>> Service providers give us information that may be useful: a >>>>>>>>>>>> subscriber name and address for example, which is not >>>>>>>>>>>> spoofable by the caller. They have ways to trace callers, >>>>>>>>>>>> especially bad callers. They don't want their >>>>>>>>> systems abused >>>>>>>>>>>> any more than the emergency calling authorities do. >>>>>>>>>>>> >>>>>>>>>>>> This is a bad idea. A very bad idea. Please stop it. >>>>>>>>>>>> >>>>>>>>>>>> Someday, we may have better ways to prevent abuse. Until we >>>>>>>>>>>> do, service providers are a good thing on an emergency call. >>>>>>>>>>>> We don't want them cut out. >>>>>>>>>>>> >>>>>>>>>>>> Brian >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Geopriv mailing list >>>>>>>>>>>> Geopriv@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 James.Winterbottom@andrew.com Sat Oct 31 14:44:33 2009 Return-Path: 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 43B743A6841 for ; Sat, 31 Oct 2009 14:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.017 X-Spam-Level: X-Spam-Status: No, score=-2.017 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] 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 TjWisMfwp71X for ; Sat, 31 Oct 2009 14:44:30 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id E53603A67A8 for ; Sat, 31 Oct 2009 14:44:29 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:56966 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S63489AbZJaVor convert rfc822-to-8bit (ORCPT ); Sat, 31 Oct 2009 16:44:47 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.393.1; Sat, 31 Oct 2009 16:44:47 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Sun, 1 Nov 2009 05:44:44 +0800 From: "Winterbottom, James" To: Brian Rosen , "Dawson, Martin" , Marc Linsner Date: Sun, 1 Nov 2009 05:44:43 +0800 Thread-Topic: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4AE1y5CAAGs5+wAAX4z4UAAdMnZQACY9dzAAJ55ZEAIY7SzwAIVkuoAAGCY3EADhIEsAAa3yqpAA9rF8Y= Message-ID: <5A55A45AE77F5941B18E5457ECAC8188011EB8E6DA71@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F0F251C34@SISPE7MB1.commscope.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Sat, 31 Oct 2009 21:44:33 -0000 I have puzzled over a number of the comments below and I think you just don't get what we mean by an access provider Brian. Specific comments inline. ________________________________________ From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of Brian Rosen [br@brianrosen.net] Sent: Saturday, October 31, 2009 9:01 AM To: Dawson, Martin; Marc Linsner Cc: ecrit@ietf.org Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered There is no doubt that the PSAPs care about the access provider, because the access provider is responsible for location. They want a good identity from that location provider, and they want the data that it provides to have some kind of integrity protection. [AJW] The access provider is actually THE BEST SOURCE of the identity information to the equivalent of what they get today for landline. The access provider knows in whose name the access service is provided. This is exactly the same as what happens with a landline today, or a mobile for that matter, or a public telephone. Making the assumption that the person that rents the line is the person that makes the call is a fundamentally flawed assumption, the best you can ever get is the identity of the person that rents the service. It is an advantage that the access provider is local. [AJW] The access provider is ALWAYS LOCAL. i don't understand you comments here at all. However, calls don't come from access providers, they come from service providers who provide some sort of real time two way media session service (recognizing that often the access network and the SP that provides the calling service are the same entity). That's the SP we're talking about. [AJW] Fundamentally wrong. ALL TRAFFIC comes via the access provider, that is why they are the access provider. Are you suggesting that calls somehow use a different path to enter the Internet than through the access provider's network, if so, isn't that second path also provided by an access provider? Unlike the calling network, where there is at least a rudimentary authentication system in place always, there are many access networks that have no authentication at all, which gives rise to the abuse problem that makes this idea not tenable. There is no reason to believe that is going to change. [AJW] Are you saying that the person that ultimately provides the access service doesn't have to do any kind of authentication, contractually or cryptographically, in order to get their fibre connected into the Internet? I simply don't believe you, and if that is the case I want to move where this is possible. Ultimatley, if you provide an open Internet connection, and the users you allow to connect to it start making nuisance calls then you as the access provider will be held responsible. This is reasonable. And yes they will know where you are, and yes you will get hit with a big stick. I also think that there are enough logs in the system that if it is the same user doing it all the time you could take pretty reasonable steps to stop them from connecting to the network at all. I also point out, once again, that using the access network as the source of authentication means that we are using an IP address as an identifier. IP addresses make lousy identifiers. They are addresses, not identifiers. [AJW] I have a few comments on this. An address identifies where to send traffic, so it is an identifier, it identifies a device at a point in time. For the purpose of this discussion I am trying to get help to the person on the end of the device. I have absolutely no way of ever knowing precisely who they are, so this whole "person identity" discussion is entirely moot, the best I can EVER know, as I stated before, is who is paying for the service, access or phone. On my access provider, I can assure you that modem does need to authenticate, so my access provider absolutely knows that the modem on the end of this service is paid for by me. My wife and children live in this house too, and anyone of them can also use a computer connected to the network in my house, sometimes I let visitors use it too. This is no different to a conventional phone service, and the PSAP operator cannot assume that it is me that is calling, the only thing that they can be sure of is that it is a p hone in my house. Using the access provider to authenticate and provide information in this manner is a very good idea, and guess what, this is EXACTLY what ECRIT Direct is saying. Keep everything local! Oh, one more thing about this idea: It means that devices have to have a SIP stack, regardless of what they actually use to place calls. That's okay for some devices, but of course there are many, many more devices and services that don't use SIP from the device to the service provider. It's one thing to say that the SP has to gateway to SIP if its devices don't already speak SIP. It's quite another to say that every device has to be able to speak SIP for emergency calls regardless of what it uses for everything else. There would be similar daunting problems for codecs. [AJW] This is ONLY true is the device wants to be compliant with this specification. This specification builds on phone BCP and provides an end-game solution, it does not mean that things in Phone BCP cannot be used. Cheers James On 10/30/09 9:18 PM, "Dawson, Martin" wrote: > Hey Brian, > > Maybe if you keep saying "service provider" we'll all start believing it means > "VSP" and it really does have some quintessential significance to emergency > calling... > > However, to quote Watto (Phantom Menace): > > "What? You think you're some kind of Jedi, waving your > hand around like that?" > > :) > > Sure PSAP providers like to have a "service provider" they can point their > finger at. They like someone who might be a source of forensic information > related to the source of nuisance calls. In particular, it's really useful if > that provider is in the same jurisdiction that they are. That would be the 'I' > SP rather than the 'V' SP that you keep trying to steer the focus back to. > > Cheers, > Martin > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Brian Rosen > Sent: Saturday, 31 October 2009 5:29 AM > To: Marc Linsner > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered > > I'm the messenger here. PSAPs prefer service providers to be on the path of > a call, and they have bad experiences when they aren't. > > Given their experiences, I can't fault them. > > The reason the text is in phonebcp is as you said it is: because "normal" is > likely to work. The fact that "normal" means SP path in 99.999% of cases > gets the PSAPs what they want. They don't care about why we did it, they > care they get the right result. > > I don't believe we are going to see vanity domains used on calls, and even > if they were in "From", they won't be the domain in P-Asserted-Identity, or > the SubjectAltName of the Identity signature. If some service that used > email addresses as identities sent us calls, the email address (with its > domain) is the "userpart" of the identity, not the whole thing. There are > some interesting problems when you have URI to something like the MS IM > systems. The first "@' (br@brianrosen.net@msn.com) gets escaped. We've > built systems that handle that. > > The Firewall/Session Border controls will have several criteria when PSAPs > are overloaded, but AFAIK, no existing firewalls or SBCs do what you suggest > other than the repeat offender rule, which is the first line of defense. > They do filter based on criteria that equate to IP Address or Domain of the > SP, which we can deal with. We'll use what works for the other users of > these systems, we're unlikely to be able to have emergency services special > firewalls or SBCs. > > In most cases we're going to have hard connections, or more likely VPNs from > service providers to the ESInet routers. That will probably handle 90+ > percent of calls, but we'll still have substantial numbers coming from the > big I Internet. We do want to know where they are coming from, and we will > have SOME form of identity that we trust to separate those we know about > from those we don't. > > This is a percentages game. Most of the time, calls will be accepted no > matter how they get to the ESInet. If you want your calls to get through > when things are bad, send them the way you send all your other calls; that > will work okay. If you break that (by encouraging people to send them > direct), then we'll have more problems. > > I'm back to the basic tenet: if you can use the service to create media > sessions to others, you can use it to send emergency calls, and we want the > calls sent the same path (because it will work). If you can't use the > service (like, you can't register for one reason or another), we don't want > you to be able to make emergency calls. > > To be fair, there is at least one country I know of that doesn't agree. > They have documented a small number of good calls in with the tens of > thousands of bad ones, and think its worth it to handle the bad ones in > order to get to the good ones. Most PSAPs I know of don't. > > And furthermore, there are some regulations around this that are nation > specific, and I think we don't need the IETF to wade into trying to figure > out how to meet those regulations. In most cases, we don't really know how > the regulator intends the regulations to cover devices on the Internet. > > Brian > > On 10/30/09 1:46 PM, "Marc Linsner" wrote: > >> Brian, >> >> "Normal Call Path" was NOT added to phonebcp for the purpose of the >> perceived security you describe. The advantage (and the reason it's in >> phonebcp) to using the normal call path is due to it being the most likely >> mechanism to work. Unused/untested mechanisms are more likely to fail when >> tried for the first time verses mechanisms that are used/tested daily. >> Emergency time is not the time to test a new mechanism, hence use the normal >> call path, the same one you just used to call grandma, to summons emergency >> assistance. (This is a negative against this proposed mechanism.) >> >> If you are evangelizing within the PS community that 'sip:johnny@att.com' is >> less of a threat than 'sip:johnny@vanitydomain.com', I suggest that is the >> wrong message to be spreading. Please stop now. This will only lead to the >> thousands of personal injury lawyers making big $$ at the expense of the PS >> community. >> >> As you are intimately aware, there are millions of 'vanity' domains in use >> and it's growing. Its growing not just in the individual market, but in the >> small/medium business market. You also know there are thousands of hosting >> companies providing services to the owners of vanity domains (email, web, >> ftp, etc.). I expect in the near future that hosting providers will add sip >> proxy services to their list of wares. >> >> My guess would be that PS officials would like to treat their customer known >> as -'sip:johnny@vanitydomain.com' the same as their customer known as >> -'sip:johnny@att.com'. The domain name does not dictate the level of >> urgency in the request for emergency assistance, nor the veracity of the >> caller. >> >> When an overload of the ESInet exists, I would suggest to look for other >> parameters to use in decision process of how to populate the various queues. >> >> - Are the calls from all the same location? >> - Is it reasonable that the IP address/network can be at the reported >> location? >> - How many calls have we received over a period of time from this AOR? IP >> address/network? Location? >> >> Simply using the domain/AOR as the black and white rule, as you suggest, >> will lead to big problems. >> >> Just my opinion, >> >> -Marc- >> >> On 10/30/09 9:47 AM, "Brian Rosen" wrote: >> >>> I want it to say MUST NOT use that mechanism :) >>> >>> I don't want alternative ways to make emergency calls. I want what phonebcp >>> already says: send the call on the normal path and a normal identity and >>> callback (which implies using a normal registration). >>> >>> I understand that the local authority can disable the ESRP registration >>> mechanism. If this draft goes forward against my advice, then I will ask >>> that there be text that says if the registration cannot be completed, the >>> device MUST NOT send emergency calls direct to that ESRP, and must use its >>> normal call path for emergency calls. >>> >>> We can't stop calls from entering the emergency services IP network without >>> passing through a service provider. I have no wish to add any mechanism >>> which would attempt to do so. If it would help, I would be happy to beef >>> up language in framework that discusses this problem and what "normal call >>> path" means. I would even be very happy to add a item to phonebcp that says >>> "if you can't make normal calls, you can't make emergency calls", although >>> we might get hung up on defining "normal", because if at some time when you >>> need help the only number that could actually answer your call, sent down >>> the same call path as you would normally send any call, is the emergency >>> service, then we want that call. >>> >>> We frequently use you as an example. If you have a SIP Registrar and proxy >>> server in your home (or boat) and you have a phone that registers with it, >>> and you normally make calls to your family and friends with that setup, then >>> I suspect that there is some service provider helping your proxy server >>> connect to your family and friends. We would prefer your emergency calls go >>> through that service provider. However, if for some reason, your proxy >>> server forwarded an emergency call direct to the ESInet, it will normally go >>> through. >>> >>> Unfortunately for you, if someone decides to attack the emergency call >>> system, and it gets overloaded for some period of time until we can mitigate >>> the attack, we may have to make choices on which calls we answer and which >>> ones we don't. Your call sent through your proxy server to the ESInet >>> direct may get lower priority than the same call sent through the service >>> provider, if we notice that most of the attack calls are coming direct from >>> the Internet, rather than going through a service provider we know about. >>> We're building in explicit attack mitigation strategies like that. It's not >>> unreasonable: if you have 5 sources entering your network, and one of them >>> is the place where all (or most) of the attack is coming from, you shut off >>> that source until you have a better filter. >>> >>> If a whole lot of devices assume the direct path is the preferred path, that >>> would be bad for them. >>> >>> Furthermore, there is additional data sent to the emergency system (in the >>> U.S.) with the call from the service provider. That information may be >>> useful in helping you. The device can actually send the information, but >>> while while we are pretty sure we can get most service providers to give it >>> to us, we are pessimistic most devices will. Devices that have sensors, >>> where the sensor data is useful for emergency calls may very well do it. >>> Medical monitoring devices for example. NENA will be asking the IETF to >>> standardize this soon, so that all service providers anywhere could provide >>> it to all emergency services. It has things like subscriber (as opposed to >>> caller) contact data, class of service information, SP contact data, etc. >>> When things go wrong, the PSAP will often contact the SP and get help. The >>> SP often has tools and mechanisms that CAN help. >>> >>> Brian >>> >>> >>> On 10/29/09 5:46 PM, "Marc Linsner" wrote: >>> >>>> Brian, >>>> >>>> I didn't read anything in the draft that stated devices 'should' use this >>>> mechanism (if it's there, it needs removed). I read it more as a device >>>> 'could' use this mechanism (as in an alternative to other mechanisms). >>>> >>>> Further, since the ESRP is controlled by the PSAP, it certainly would be a >>>> PSAP policy decision whether to support this mechanism. As without the >>>> ESRP >>>> support of unknown UA registrations, the mechanism doesn't work. >>>> >>>> BTW, the term 'unregistered' is not in phonebcp. I think your are >>>> stretching the 'normal call path' to include registration with >>>> something(?). >>>> I find nothing in phonebcp that disallows 'direct' calls to an ESRP. If I >>>> contact an ESRP from my UA 'directly', as long as the PSAP can call-back >>>> using the Contact header I sent in the invite and my AOR leads back to my >>>> UA, I've satisfied phonebcp. >>>> >>>> What am I missing? >>>> >>>> -Marc- >>>> >>>> >>>> On 10/29/09 4:35 PM, "Brian Rosen" wrote: >>>> >>>>> The IETF writing standards that describe how devices should bypass their >>>>> service provider and place emergency calls direct is not a PSAP policy >>>>> issue. >>>>> >>>>> I'm satisfied with the current -phonebcp dictum to send calls on the >>>>> normal >>>>> call path. For an "unregistered" device, that will not allow any "calls" >>>>> including emergency calls. >>>>> >>>>> I discussed this draft on the NENA LTD meeting this morning. That may >>>>> generate some list discussion from some PSAP people who are subscribed. I >>>>> would also like to hear from more PSAP folks on this subject. >>>>> >>>>> Brian >>>>> >>>>> >>>>> On 10/29/09 3:27 PM, "Marc Linsner" wrote: >>>>> >>>>>> These are all PSAP policy decisions. Just as it's a PSAP policy decision >>>>>> to >>>>>> support the suggested mechanism in the draft. Existence of the document >>>>>> describing the mechanism doesn't force PSAP policy. >>>>>> >>>>>> I personally would like to see some PSAPs and/or PS jurisdictions line up >>>>>> behind the draft before it proceeds, but I don't see any harm in it going >>>>>> forward. >>>>>> >>>>>> Of course, I'm dreaming about this special place where a PSAP actually >>>>>> wants >>>>>> to enable communication with all their customers and not force them to be >>>>>> a >>>>>> member of a special club. >>>>>> >>>>>> [non-chair hat on] >>>>>> >>>>>> -Marc- >>>>>> >>>>>> >>>>>> On 10/29/09 2:35 PM, "Brian Rosen" wrote: >>>>>> >>>>>>> Thank you. That is what I meant, and you said it better than I was >>>>>>> going >>>>>>> to. >>>>>>> >>>>>>> We may also have some transitive relationships: that is, if there is a >>>>>>> "local" PSAP that trusts that they have done so, other PSAPs may trust >>>>>>> that >>>>>>> they have done so. >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>> On 10/29/09 11:48 AM, "DRAGE, Keith (Keith)" >>>>>>> wrote: >>>>>>> >>>>>>>> I suspect that what Brian is saying is that anyone can be a service >>>>>>>> provider >>>>>>>> (or whatever else you want to call it) in this case provided that: >>>>>>>> >>>>>>>> 1) they make that agreement with the PSAP providers they route >>>>>>>> calls >>>>>>>> to; >>>>>>>> >>>>>>>> 2) they authenticate the calls requests to a level of security >>>>>>>> that >>>>>>>> meets >>>>>>>> the PSAPs (and any legal) requirements; >>>>>>>> >>>>>>>> 3) the PSAP trusts that they have done so. >>>>>>>> >>>>>>>> While this would normally be what we would understand as public >>>>>>>> telecommuncation operators, it doesn't mean they have to be. >>>>>>>> >>>>>>>> regards >>>>>>>> >>>>>>>> Keith >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>>>>>>>> On Behalf Of Marc Linsner >>>>>>>>> Sent: Thursday, October 29, 2009 12:32 PM >>>>>>>>> To: Brian Rosen >>>>>>>>> Cc: ecrit@ietf.org >>>>>>>>> Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>>>>>>> considered >>>>>>>>> >>>>>>>>> Brian, >>>>>>>>> >>>>>>>>> Please define what you consider to be a service provider. >>>>>>>>> >>>>>>>>> Is Skype a service? >>>>>>>>> Is Jabber a service? >>>>>>>>> Is Google Voice a service? >>>>>>>>> Is mydomain.com hosted on a commercial site a service? >>>>>>>>> Is mydomain.com hosted on a home server a service? >>>>>>>>> Is myEnterpriseVoIP.com a service? >>>>>>>>> >>>>>>>>> So, what you are saying that if I can make calls via all of >>>>>>>>> the above, it's OK for all of the above to contact an ESRP? >>>>>>>>> >>>>>>>>> Are you requiring that I have a full-time proxy on-line for >>>>>>>>> mydomain.com or can I simply run a transient UA and dynamic DNS? >>>>>>>>> >>>>>>>>> -Marc- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/28/09 11:17 PM, "Brian Rosen" wrote: >>>>>>>>> >>>>>>>>>> I'm not worried about security by obscurity. I don't want >>>>>>>>> phones (or >>>>>>>>>> other >>>>>>>>>> devices) built to call directly. >>>>>>>>>> >>>>>>>>>> -phonebcp says "send the call on your normal outbound call path". >>>>>>>>>> That's what I want it to say, and I don't want it to say "send it >>>>>>>>>> direct, bypass your service provider. >>>>>>>>>> >>>>>>>>>> I'm not stopping attack, I am stopping abuse. >>>>>>>>>> >>>>>>>>>> I don't want devices that are not subscribed to services to >>>>>>>>> be able to >>>>>>>>>> make emergency calls (that is, if they can't make "normal" >>>>>>>>> calls, they >>>>>>>>>> should not be able to make emergency calls). >>>>>>>>>> >>>>>>>>>> Brian >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 10/28/09 6:51 PM, "Marc Linsner" wrote: >>>>>>>>>> >>>>>>>>>>> Brian, >>>>>>>>>>> >>>>>>>>>>> What I hear you saying: 'if we don't document how to spoof a PSAP, >>>>>>>>>>> then nobody will figure it out.' Isn't that a little >>>>>>>>> short sighted? >>>>>>>>>>> >>>>>>>>>>> Joey@miscreant.org will figure out how to establish a SIP session >>>>>>>>>>> with any PSAP in the world within 10 minutes of that PSAP being >>>>>>>>>>> accessible via the Internet, regardless of documentation. >>>>>>>>>>> >>>>>>>>>>> I believe there's more harm created in not documenting this for >>>>>>>>>>> John.Q.Public@ordinary_citizen.com. >>>>>>>>>>> >>>>>>>>>>> Granted, nobody here is looking to cause harm to a PSAP. But >>>>>>>>>>> Joey@miscreant.org can certainly expend public safety resources by >>>>>>>>>>> reporting a bomb threat to a local school. Should we require that >>>>>>>>>>> all SIP calls to the local school come from a trusted SP? >>>>>>>>> Where does it end? >>>>>>>>>>> >>>>>>>>>>> This isn't the way to deal with spam. >>>>>>>>>>> >>>>>>>>>>> -Marc- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 10/27/09 11:00 AM, "Brian Rosen" wrote: >>>>>>>>>>> >>>>>>>>>>>> The first goal is to prevent bad calls. >>>>>>>>>>>> >>>>>>>>>>>> The second goal is to indentify the source of the bad calls. >>>>>>>>>>>> >>>>>>>>>>>> I'm starting with the first goal. I don't want you to be able to >>>>>>>>>>>> take a device out of a box, plug it into a network, and have the >>>>>>>>>>>> only call you can make be an emergency call. I want the >>>>>>>>> device to >>>>>>>>>>>> actually "work" (as in be able to place calls to all the entities >>>>>>>>>>>> that it was intended to) first, and then be able to place >>>>>>>>> emergency calls. >>>>>>>>>>>> >>>>>>>>>>>> Please spend some time in a PSAP while a kid with a >>>>>>>>> simless phone has "fun" >>>>>>>>>>>> with it. Imagine how much fun the test mechanism is as >>>>>>>>> opposed to >>>>>>>>>>>> placing real calls. >>>>>>>>>>>> >>>>>>>>>>>> If we somehow get a bad call, we need to send the cops. >>>>>>>>> That means >>>>>>>>>>>> we need an identity (and a location). >>>>>>>>>>>> >>>>>>>>>>>> I think a good cert could be the basis of a good identity, if we >>>>>>>>>>>> could get one. I don't see how we do that. >>>>>>>>>>>> >>>>>>>>>>>> Brian >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/27/09 10:39 AM, "Richard Barnes" wrote: >>>>>>>>>>>> >>>>>>>>>>>> Brian, >>>>>>>>>>>> >>>>>>>>>>>> Is the security goal here more access control (i.e., controlling >>>>>>>>>>>> who can send calls to a PSAP) or attribution/identification for >>>>>>>>>>>> post-hoc action. >>>>>>>>>>>> >>>>>>>>>>>> If it's the latter, then ISTM that the problem can largely be >>>>>>>>>>>> reduced to having a certificate infrastructure that binds >>>>>>>>>>>> authenticated identities to real-world entities. The >>>>>>>>> "extended validation" >>>>>>>>>>>> certificates that current commercial CAs issue seem to largely >>>>>>>>>>>> satisfy this requirement. >>>>>>>>>>>> >>>>>>>>>>>> --Richard >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Oct 27, 2009, at 4:31 PM, Brian Rosen wrote: >>>>>>>>>>>> >>>>>>>>>>>> Of course not all VSPs will have trust relationships with all >>>>>>>>>>>> PSAPs. One can hope that long term, we can evolve to >>>>>>>>> transitive >>>>>>>>>>>> trust relationships that work pretty well cross border. >>>>>>>>>>>> >>>>>>>>>>>> The emergency guys are actually terrified of private/individual >>>>>>>>>>>> domains sending them calls, and we're telling them we >>>>>>>>> expect that >>>>>>>>>>>> to be possible, but rare, and we're giving them mechanisms that >>>>>>>>>>>> will effectively allow them to turn off calls >>>>>>>>> selectively, based >>>>>>>>>>>> on factors including what domain the call comes from. >>>>>>>>> They expect >>>>>>>>>>>> that such calls will be one of the loopholes where they get >>>>>>>>>>>> equivalents to sim-less calls, which drive them nuts. >>>>>>>>> They don't >>>>>>>>>>>> want ANY calls that don't come from service providers, although >>>>>>>>>>>> they seem to be okay with the notion that the SP may not have >>>>>>>>>>>> great identity (AOL being a poster child). So, while >>>>>>>>> indeed they >>>>>>>>>>>> understand, and have concerns about having to take calls from >>>>>>>>>>>> Sierra Leone VoIP services Pty, they would much rather >>>>>>>>> have a call >>>>>>>>>>>> that went through them then a call that went through no service >>>>>>>>>>>> provider at all. >>>>>>>>>>>> >>>>>>>>>>>> I'm not trying to make calls direct from devices or private >>>>>>>>>>>> domains impossible, but I think the notion that we're promoting >>>>>>>>>>>> them is a very bad idea until we have effective mechanisms to >>>>>>>>>>>> prevent abuse. >>>>>>>>>>>> >>>>>>>>>>>> Brian >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/27/09 9:02 AM, "Marc Linsner" wrote: >>>>>>>>>>>> >>>>>>>>>>>> Brian, >>>>>>>>>>>> >>>>>>>>>>>> I'm a little confused. I don't remember you objecting to >>>>>>>>>>>> requirement RE1 from RFC5012 and I remember your use >>>>>>>>> case about a >>>>>>>>>>>> Sierra Leone VSP. >>>>>>>>>>>> >>>>>>>>>>>> Are you implying that *all* VSPs will have a trust >>>>>>>>> relationships >>>>>>>>>>>> with *all* PSAPs? >>>>>>>>>>>> >>>>>>>>>>>> What is the difference between a call coming from a private/ >>>>>>>>>>>> individual domain (as in not a commercial VSP) and a >>>>>>>>> VSP on the >>>>>>>>>>>> other side of the world (outside the jurisdiction)? >>>>>>>>>>>> >>>>>>>>>>>> I'm trying to figure out whether you're objecting to anonymous >>>>>>>>>>>> calls to the PSAP or the mechanisms proposed in this draft? >>>>>>>>>>>> >>>>>>>>>>>> [Don't take this as my endorsement of the draft, as >>>>>>>>> I'm not sure >>>>>>>>>>>> I agree with UAs registering with the ESRP.] >>>>>>>>>>>> >>>>>>>>>>>> -Marc- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/26/09 8:59 PM, "Brian Rosen" wrote: >>>>>>>>>>>> >>>>>>>>>>>> First of all, I put it on the wrong email list, sorry >>>>>>>>> about that. >>>>>>>>>>>> >>>>>>>>>>>> Then, we have carefully arranged it so that there is >>>>>>>>> no identity >>>>>>>>>>>> coming from the access network provider, and because the >>>>>>>>>>>> location is coming from that provider, we really >>>>>>>>> don't want to. >>>>>>>>>>>> But even if we did, we would need a really good >>>>>>>>> identifier, and >>>>>>>>>>>> there isn't one. >>>>>>>>>>>> >>>>>>>>>>>> The problem we have with -direct is anonymous callers, and if >>>>>>>>>>>> they have any option, they would also be >>>>>>>>> location-less. Until >>>>>>>>>>>> and unless we get rid of anonymity, we can't >>>>>>>>> encourage service >>>>>>>>>>>> provider-less calls. The draft does not make any >>>>>>>>> provision to >>>>>>>>>>>> provide any kind of identity. Many networks (think free wifi >>>>>>>>>>>> for example) would make providing good identity difficult. >>>>>>>>>>>> >>>>>>>>>>>> The fact is that there is a SERVICE provider in >>>>>>>>> nearly all of the >>>>>>>>>>>> communications systems. The SERVICE provider is in >>>>>>>>> a position to >>>>>>>>>>>> assist >>>>>>>>>>>> the emergency calling system when it needs more information. >>>>>>>>>>>> That's what a >>>>>>>>>>>> good SERVICE provider does. Cutting them out is not a great >>>>>>>>>>>> idea. Most of the attempts to provide real time >>>>>>>>> communications >>>>>>>>>>>> between people have evolved to using service providers, even >>>>>>>>>>>> when there were alternatives. File transfer via >>>>>>>>> something like >>>>>>>>>>>> Torrent is a counterexample (which isn't real time), but even >>>>>>>>>>>> there, you end up with service providers like The Pirate Bay >>>>>>>>>>>> (R.I.P) to provide introduction services. I don't >>>>>>>>> think we're >>>>>>>>>>>> going to see changes that eliminate service providers, and in >>>>>>>>>>>> this case, they provide value to the emergency >>>>>>>>> calling systems. >>>>>>>>>>>> All of the emergency professionals I know have issues with >>>>>>>>>>>> service providers, but they would react with horror if you >>>>>>>>>>>> suggested cutting them out. Ask them, please. >>>>>>>>>>>> >>>>>>>>>>>> So, I claim you have a solution in search of a >>>>>>>>> problem. We have >>>>>>>>>>>> solved the "calling network isn't the access network" problem >>>>>>>>>>>> already. Service providers ARE in the path now, in >>>>>>>>> nearly every >>>>>>>>>>>> case (in fact a counter example escapes me, although there >>>>>>>>>>>> probably are some). There is no movement I can detect which >>>>>>>>>>>> would change that any time soon; quite the opposite. >>>>>>>>> We have a >>>>>>>>>>>> known killer problem without some kind of subscription to a >>>>>>>>>>>> service that provides a good identity, for which you >>>>>>>>> provide no >>>>>>>>>>>> answers. >>>>>>>>>>>> We have >>>>>>>>>>>> experience with the killer problem: sim-less calling was >>>>>>>>>>>> supposed to provide a way to make an emergency call >>>>>>>>> in exactly >>>>>>>>>>>> the kinds of circumstances you are describing. Our >>>>>>>>> real world >>>>>>>>>>>> experience is that you create a huge problem that diverts >>>>>>>>>>>> resources from helping people to chasing scammers and >>>>>>>>>>>> flea-market sellers. >>>>>>>>>>>> >>>>>>>>>>>> Nothing is perfect: you can get a AIM screen name >>>>>>>>> without a very >>>>>>>>>>>> good identity for example. However, the notion that >>>>>>>>> we're going >>>>>>>>>>>> to provide direct access without a service provider >>>>>>>>>>>> deliberately, especially without really good identity >>>>>>>>> from the >>>>>>>>>>>> access network is, in my opinion not only a no, it's >>>>>>>>> a heck no. >>>>>>>>>>>> I'll line up as many emergency service professionals as you >>>>>>>>>>>> would like to tell you this is a harmful idea. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/26/09 7:56 PM, "Dawson, Martin" >>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> I am glad this has come up. It's a debate that has >>>>>>>>> to happen if >>>>>>>>>>>> we are to move beyond a long standing legacy misconception. >>>>>>>>>>>> >>>>>>>>>>>> In the circuit service world - whether it was POTS >>>>>>>>> or mobile, >>>>>>>>>>>> the access network had full responsibility for >>>>>>>>> delivering the >>>>>>>>>>>> emergency call. In that world, routing an emergency >>>>>>>>> call meant >>>>>>>>>>>> getting a circuit established to the correct call center. In >>>>>>>>>>>> most parts of the world, this was done using the >>>>>>>>> regional part >>>>>>>>>>>> of the PSTN to switch the circuit to a call center >>>>>>>>> on the PSTN. >>>>>>>>>>>> In some jurisdictions, such as the US, it was done directly >>>>>>>>>>>> from the local exchange carrier to the call center. >>>>>>>>> Either way, >>>>>>>>>>>> there was no third party involved. >>>>>>>>>>>> >>>>>>>>>>>> Now we have the Internet. We still have public >>>>>>>>> access network >>>>>>>>>>>> providers. >>>>>>>>>>>> They >>>>>>>>>>>> switch packets onto the Internet for their subscribers. They >>>>>>>>>>>> can similarly ensure that packets reach the local emergency >>>>>>>>>>>> call centers. >>>>>>>>>>>> >>>>>>>>>>>> The fact is that there was no equivalent of a VSP in the >>>>>>>>>>>> traditional environment. VoIP is a presence service, >>>>>>>>> and it had >>>>>>>>>>>> no common equivalent in the PSTN world. It could >>>>>>>>> have, but the >>>>>>>>>>>> narrowband state of technology and the common market >>>>>>>>> use cases >>>>>>>>>>>> didn't support its development. By the time ISDN >>>>>>>>> arrived, the >>>>>>>>>>>> PSTN had already slipped into its palliative stage without >>>>>>>>>>>> realizing it. >>>>>>>>>>>> >>>>>>>>>>>> It's an entrenched misconception that because the circuit >>>>>>>>>>>> service provided by exchange carriers was most commonly used >>>>>>>>>>>> for "voice" (but, it should be noted, also for fax, >>>>>>>>> telex, tty, >>>>>>>>>>>> security system monitoring and, even, IP data) that VSPs are >>>>>>>>>>>> somehow equivalent to exchange carriers. They are not. >>>>>>>>>>>> >>>>>>>>>>>> Indeed, involving VSPs in emergency calls is the Internet >>>>>>>>>>>> equivalent of involving long distance providers in POTS >>>>>>>>>>>> emergency calls. They are neither necessary nor particularly >>>>>>>>>>>> helpful; they can't be guaranteed to be within the emergency >>>>>>>>>>>> jurisdiction; depending on them actually diminishes the >>>>>>>>>>>> efficacy of emergency service access. It does not help the >>>>>>>>>>>> caller, the emergency service, nor the third party >>>>>>>>> to insist on >>>>>>>>>>>> the third party's involvement. >>>>>>>>>>>> >>>>>>>>>>>> It can't be helped if you have over sold the benefits of VSP >>>>>>>>>>>> involvement to yourself and others Brian. It is time >>>>>>>>> to have a >>>>>>>>>>>> reasoned debate. >>>>>>>>>>>> From my >>>>>>>>>>>> perspective, the argument that there is no "subscription" >>>>>>>>>>>> involved is >>>>>>>>>>>> patently >>>>>>>>>>>> false. There has to be a subscription of some description in >>>>>>>>>>>> order to get to the Internet. Yes, there is free public >>>>>>>>>>>> Internet access (just as there are free courtesy >>>>>>>>> phones on the >>>>>>>>>>>> PSTN and free access to emergency services from pay >>>>>>>>> phones. All >>>>>>>>>>>> these services are still connected to the public Internet >>>>>>>>>>>> infrastructure and they all represent an "operator" >>>>>>>>> with some >>>>>>>>>>>> level of information about the caller. >>>>>>>>>>>> >>>>>>>>>>>> With the over-emphasis on VSPs, what is missing from >>>>>>>>> the ECRIT >>>>>>>>>>>> and i3 models is the direct interface for querying >>>>>>>>> the access >>>>>>>>>>>> network for subscriber data (should it prove >>>>>>>>> necessary). These >>>>>>>>>>>> models need to take the long view of how emergency >>>>>>>>> calling is >>>>>>>>>>>> done in the Internet age; they should not be protracting an >>>>>>>>>>>> unnecessary reliance on VSPs. >>>>>>>>>>>> >>>>>>>>>>>> I have deleted the premature and prejudicial text from the >>>>>>>>>>>> subject heading. >>>>>>>>>>>> And I'll leave this on ECRIT as the most appropriate WG. >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> Martin >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: ecrit-bounces@ietf.org >>>>>>>>> [mailto:ecrit-bounces@ietf.org] On >>>>>>>>>>>> Behalf Of Hannes Tschofenig >>>>>>>>>>>> Sent: Tuesday, 27 October 2009 8:23 AM >>>>>>>>>>>> To: ecrit@ietf.org >>>>>>>>>>>> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>>>>>>>>>> considered harmful, at least given our current experiences >>>>>>>>>>>> >>>>>>>>>>>> FYI: feedback from Brian regarding a recent ECRIT >>>>>>>>> contribution. >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: geopriv-bounces@ietf.org >>>>>>>>>>>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian >>>>>>>>>>>> Sent: 26 October, 2009 23:10 >>>>>>>>>>>> To: geopriv@ietf.org >>>>>>>>>>>> Subject: [Geopriv] Winterbottom-ecrit-direct considered >>>>>>>>>>>> harmful, at least given our current experiences >>>>>>>>>>>> >>>>>>>>>>>> The notion behind -direct is to not use a service >>>>>>>>> provider to >>>>>>>>>>>> place an emergency call. Instead, the device >>>>>>>>> registers with >>>>>>>>>>>> an Emergency Services Routing Proxy immediately before the >>>>>>>>>>>> call and the call is routed directly from the >>>>>>>>> device to the ESRP. >>>>>>>>>>>> >>>>>>>>>>>> At least at the moment, this is an exceedingly bad idea. >>>>>>>>>>>> >>>>>>>>>>>> Emergency calling authorities like service providers, a lot. >>>>>>>>>>>> They like them because they can hold them >>>>>>>>> accountable, and the >>>>>>>>>>>> service providers don't like theft of service, which is >>>>>>>>>>>> something the emergency call guys have an analog to. >>>>>>>>>>>> >>>>>>>>>>>> The facts are that where unaccountable access to emergency >>>>>>>>>>>> calling is allowed, huge numbers of false calls >>>>>>>>> occur, with no >>>>>>>>>>>> way to stop them, and no way to tell the good ones from the >>>>>>>>>>>> bad ones. This has been seen multiple times where >>>>>>>>> so called >>>>>>>>>>>> "simless" or "unauthenticated" calls are allowed. >>>>>>>>>>>> >>>>>>>>>>>> -direct precisely duplicates simless calling. The only >>>>>>>>>>>> "registration" is an emergency registration, only emergency >>>>>>>>>>>> calls are allowed, any device can make an emergency call if >>>>>>>>>>>> all it has is a (radio) connection to any network. >>>>>>>>>>>> We can predict, with a very high degree of >>>>>>>>> certainty, that the >>>>>>>>>>>> feature will be horribly abused: for example to test that a >>>>>>>>>>>> phone without a service plan works. >>>>>>>>>>>> >>>>>>>>>>>> There have been studies which show tens of thousands of bad >>>>>>>>>>>> calls with zero good ones. Nearly every authority I know >>>>>>>>>>>> where the regulator has insisted on simless calling >>>>>>>>> wants it >>>>>>>>>>>> repealed. There is one counter example I know >>>>>>>>> where the fact >>>>>>>>>>>> that they got a couple, literally, of good calls among the >>>>>>>>>>>> tens of thousands of bad calls was considered >>>>>>>>> enough reason to >>>>>>>>>>>> put up with the problem. >>>>>>>>>>>> >>>>>>>>>>>> Service providers give us information that may be useful: a >>>>>>>>>>>> subscriber name and address for example, which is not >>>>>>>>>>>> spoofable by the caller. They have ways to trace callers, >>>>>>>>>>>> especially bad callers. They don't want their >>>>>>>>> systems abused >>>>>>>>>>>> any more than the emergency calling authorities do. >>>>>>>>>>>> >>>>>>>>>>>> This is a bad idea. A very bad idea. Please stop it. >>>>>>>>>>>> >>>>>>>>>>>> Someday, we may have better ways to prevent abuse. Until we >>>>>>>>>>>> do, service providers are a good thing on an emergency call. >>>>>>>>>>>> We don't want them cut out. >>>>>>>>>>>> >>>>>>>>>>>> Brian >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Geopriv mailing list >>>>>>>>>>>> Geopriv@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From Martin.Dawson@andrew.com Sat Oct 31 17:47:12 2009 Return-Path: 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 46F253A6882 for ; Sat, 31 Oct 2009 17:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.41 X-Spam-Level: X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] 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 A322LpZ0euTU for ; Sat, 31 Oct 2009 17:47:08 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.243]) by core3.amsl.com (Postfix) with ESMTP id 45DCF3A67FB for ; Sat, 31 Oct 2009 17:47:08 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:3716 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S4901620AbZKAAr0 convert rfc822-to-8bit (ORCPT ); Sat, 31 Oct 2009 19:47:26 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.393.1; Sat, 31 Oct 2009 19:47:25 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Sun, 1 Nov 2009 08:47:08 +0800 From: "Dawson, Martin" To: Brian Rosen , Marc Linsner Date: Sun, 1 Nov 2009 08:47:04 +0800 Thread-Topic: [Ecrit] Winterbottom-ecrit-direct considered Thread-Index: AcpXFjX6AVDILxTnCU+O5mZMC6KRmwBCvMdzAAlO2D4AE1y5CAAGs5+wAAX4z4UAAdMnZQACY9dzAAJ55ZEAIY7SzwAIVkuoAAGCY3EADhIEsAAa3yqpABUu8dA= Message-ID: <8B0A9FCBB9832F43971E38010638454F0F251C4C@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F0F251C34@SISPE7MB1.commscope.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Dawson@andrew.com Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Sun, 01 Nov 2009 00:47:12 -0000 Promoting unnecessary elements in architectures tends to result in weak arguments being made; I think this is a good example of that. Looking at each rhetorical device in turn: > However, calls don't come from access providers, they come > from service providers No. They come from people making emergency calls. > ...providers who provide some sort of real time two way > media session service You keep pushing this meme... but I don't get it. You demand an alternative example? There's this thing called the world wide web. It's in pretty common use; you may have heard of it. Services exist on the WWW; people interact in two way multimedia sessions with those services. There are certainly some "agencies" who would like all access to those services to be mediated and proxied by... well... themselves; and they'd like to pick up a tariff on the way through of course. It's not really working out because, as above, it's a unnecessary to the architecture. I'll repeat; there's no analogue for this from the PSTN/circuit-service world. People could dial whatever "address" on the PSTN they wanted without somebody "insisting" they had to be a gateway. > Unlike the calling network, where there is at least a > rudimentary authentication system in place always, there are many > access networks that have no authentication at all 1. "Calling Network"? What is that exactly? There's just one network of interest here; it's the Internet. You appear to be elevating VSPs to "network" status. 2. You're saying it's impossible to have a VSP that doesn't require authentication? 3. Please list these "many" access networks that don't require authentication. Regrettably, there's a paucity of them and I think they are becoming less, not more, common. In any case, for every "free café hotspot" there's a public Internet provider on the other side that knows very well who owns that subscription - just as there was a LEC who knew who owned the diner payphone from which a 9-1-1 call could be made from. > IP addresses make lousy identifiers. They are addresses, not > identifiers. I'm not as steeped in phoneBCP as some. Where is the bit that says the ESRP sees a call from a proxy (VSP) as coming from anything other than an IP address? Where does phoneBCP enforce the A&A you appear to be kina sorta mandating? On the other hand, the thing that's nice about the access provider being the "identity" source is that, being in the same jurisdiction as the ESRP, it becomes a local jurisdiction issue as to how the interaction to obtain that "call related" information occurs. The IETF doesn't actually have to worry about that bit; NENA should for the US though. It also becomes a local jurisdictional issue as to how calls that originate from recognized local ISP address allocations are handled. It's much more tractable (tenable) than trying to apply a local policy to foreign proxy addresses that could be popping in from all over the planet. I suggest that these may be the calls that end up down the priority queue in the long run. > It means that devices have to have a SIP stack, regardless of > what they actually use to place calls. "Have to"? Only if the device vendor wants to surely. Personally, I like the idea of being able to download an ECRIT-direct reference client implementation to my Android device and being able to use it however and wherever I connect to the Internet. And I like the idea that it'll work regardless of the numerous presence subscriptions that come and go on my device. Even better, I like the idea of it being baked into a future release of Android altogether. Same goes for iPhones... if they're your cup of tea. You keep saying "SP", Brian. But there are at least an "I" SP, a "V" SP, and the "E" SP involved in the plot you describe. You are talking about the VSP; I wonder why you try so hard to avoid that specificity. Cheers, Martin -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Sunday, 1 November 2009 1:02 AM To: Dawson, Martin; Marc Linsner Cc: ecrit@ietf.org Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered There is no doubt that the PSAPs care about the access provider, because the access provider is responsible for location. They want a good identity from that location provider, and they want the data that it provides to have some kind of integrity protection. It is an advantage that the access provider is local. However, calls don't come from access providers, they come from service providers who provide some sort of real time two way media session service (recognizing that often the access network and the SP that provides the calling service are the same entity). That's the SP we're talking about. Unlike the calling network, where there is at least a rudimentary authentication system in place always, there are many access networks that have no authentication at all, which gives rise to the abuse problem that makes this idea not tenable. There is no reason to believe that is going to change. I also point out, once again, that using the access network as the source of authentication means that we are using an IP address as an identifier. IP addresses make lousy identifiers. They are addresses, not identifiers. Oh, one more thing about this idea: It means that devices have to have a SIP stack, regardless of what they actually use to place calls. That's okay for some devices, but of course there are many, many more devices and services that don't use SIP from the device to the service provider. It's one thing to say that the SP has to gateway to SIP if its devices don't already speak SIP. It's quite another to say that every device has to be able to speak SIP for emergency calls regardless of what it uses for everything else. There would be similar daunting problems for codecs. On 10/30/09 9:18 PM, "Dawson, Martin" wrote: > Hey Brian, > > Maybe if you keep saying "service provider" we'll all start believing it means > "VSP" and it really does have some quintessential significance to emergency > calling... > > However, to quote Watto (Phantom Menace): > > "What? You think you're some kind of Jedi, waving your > hand around like that?" > > :) > > Sure PSAP providers like to have a "service provider" they can point their > finger at. They like someone who might be a source of forensic information > related to the source of nuisance calls. In particular, it's really useful if > that provider is in the same jurisdiction that they are. That would be the 'I' > SP rather than the 'V' SP that you keep trying to steer the focus back to. > > Cheers, > Martin > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Brian Rosen > Sent: Saturday, 31 October 2009 5:29 AM > To: Marc Linsner > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered > > I'm the messenger here. PSAPs prefer service providers to be on the path of > a call, and they have bad experiences when they aren't. > > Given their experiences, I can't fault them. > > The reason the text is in phonebcp is as you said it is: because "normal" is > likely to work. The fact that "normal" means SP path in 99.999% of cases > gets the PSAPs what they want. They don't care about why we did it, they > care they get the right result. > > I don't believe we are going to see vanity domains used on calls, and even > if they were in "From", they won't be the domain in P-Asserted-Identity, or > the SubjectAltName of the Identity signature. If some service that used > email addresses as identities sent us calls, the email address (with its > domain) is the "userpart" of the identity, not the whole thing. There are > some interesting problems when you have URI to something like the MS IM > systems. The first "@' (br@brianrosen.net@msn.com) gets escaped. We've > built systems that handle that. > > The Firewall/Session Border controls will have several criteria when PSAPs > are overloaded, but AFAIK, no existing firewalls or SBCs do what you suggest > other than the repeat offender rule, which is the first line of defense. > They do filter based on criteria that equate to IP Address or Domain of the > SP, which we can deal with. We'll use what works for the other users of > these systems, we're unlikely to be able to have emergency services special > firewalls or SBCs. > > In most cases we're going to have hard connections, or more likely VPNs from > service providers to the ESInet routers. That will probably handle 90+ > percent of calls, but we'll still have substantial numbers coming from the > big I Internet. We do want to know where they are coming from, and we will > have SOME form of identity that we trust to separate those we know about > from those we don't. > > This is a percentages game. Most of the time, calls will be accepted no > matter how they get to the ESInet. If you want your calls to get through > when things are bad, send them the way you send all your other calls; that > will work okay. If you break that (by encouraging people to send them > direct), then we'll have more problems. > > I'm back to the basic tenet: if you can use the service to create media > sessions to others, you can use it to send emergency calls, and we want the > calls sent the same path (because it will work). If you can't use the > service (like, you can't register for one reason or another), we don't want > you to be able to make emergency calls. > > To be fair, there is at least one country I know of that doesn't agree. > They have documented a small number of good calls in with the tens of > thousands of bad ones, and think its worth it to handle the bad ones in > order to get to the good ones. Most PSAPs I know of don't. > > And furthermore, there are some regulations around this that are nation > specific, and I think we don't need the IETF to wade into trying to figure > out how to meet those regulations. In most cases, we don't really know how > the regulator intends the regulations to cover devices on the Internet. > > Brian > > On 10/30/09 1:46 PM, "Marc Linsner" wrote: > >> Brian, >> >> "Normal Call Path" was NOT added to phonebcp for the purpose of the >> perceived security you describe. The advantage (and the reason it's in >> phonebcp) to using the normal call path is due to it being the most likely >> mechanism to work. Unused/untested mechanisms are more likely to fail when >> tried for the first time verses mechanisms that are used/tested daily. >> Emergency time is not the time to test a new mechanism, hence use the normal >> call path, the same one you just used to call grandma, to summons emergency >> assistance. (This is a negative against this proposed mechanism.) >> >> If you are evangelizing within the PS community that 'sip:johnny@att.com' is >> less of a threat than 'sip:johnny@vanitydomain.com', I suggest that is the >> wrong message to be spreading. Please stop now. This will only lead to the >> thousands of personal injury lawyers making big $$ at the expense of the PS >> community. >> >> As you are intimately aware, there are millions of 'vanity' domains in use >> and it's growing. Its growing not just in the individual market, but in the >> small/medium business market. You also know there are thousands of hosting >> companies providing services to the owners of vanity domains (email, web, >> ftp, etc.). I expect in the near future that hosting providers will add sip >> proxy services to their list of wares. >> >> My guess would be that PS officials would like to treat their customer known >> as -'sip:johnny@vanitydomain.com' the same as their customer known as >> -'sip:johnny@att.com'. The domain name does not dictate the level of >> urgency in the request for emergency assistance, nor the veracity of the >> caller. >> >> When an overload of the ESInet exists, I would suggest to look for other >> parameters to use in decision process of how to populate the various queues. >> >> - Are the calls from all the same location? >> - Is it reasonable that the IP address/network can be at the reported >> location? >> - How many calls have we received over a period of time from this AOR? IP >> address/network? Location? >> >> Simply using the domain/AOR as the black and white rule, as you suggest, >> will lead to big problems. >> >> Just my opinion, >> >> -Marc- >> >> On 10/30/09 9:47 AM, "Brian Rosen" wrote: >> >>> I want it to say MUST NOT use that mechanism :) >>> >>> I don't want alternative ways to make emergency calls. I want what phonebcp >>> already says: send the call on the normal path and a normal identity and >>> callback (which implies using a normal registration). >>> >>> I understand that the local authority can disable the ESRP registration >>> mechanism. If this draft goes forward against my advice, then I will ask >>> that there be text that says if the registration cannot be completed, the >>> device MUST NOT send emergency calls direct to that ESRP, and must use its >>> normal call path for emergency calls. >>> >>> We can't stop calls from entering the emergency services IP network without >>> passing through a service provider. I have no wish to add any mechanism >>> which would attempt to do so. If it would help, I would be happy to beef >>> up language in framework that discusses this problem and what "normal call >>> path" means. I would even be very happy to add a item to phonebcp that says >>> "if you can't make normal calls, you can't make emergency calls", although >>> we might get hung up on defining "normal", because if at some time when you >>> need help the only number that could actually answer your call, sent down >>> the same call path as you would normally send any call, is the emergency >>> service, then we want that call. >>> >>> We frequently use you as an example. If you have a SIP Registrar and proxy >>> server in your home (or boat) and you have a phone that registers with it, >>> and you normally make calls to your family and friends with that setup, then >>> I suspect that there is some service provider helping your proxy server >>> connect to your family and friends. We would prefer your emergency calls go >>> through that service provider. However, if for some reason, your proxy >>> server forwarded an emergency call direct to the ESInet, it will normally go >>> through. >>> >>> Unfortunately for you, if someone decides to attack the emergency call >>> system, and it gets overloaded for some period of time until we can mitigate >>> the attack, we may have to make choices on which calls we answer and which >>> ones we don't. Your call sent through your proxy server to the ESInet >>> direct may get lower priority than the same call sent through the service >>> provider, if we notice that most of the attack calls are coming direct from >>> the Internet, rather than going through a service provider we know about. >>> We're building in explicit attack mitigation strategies like that. It's not >>> unreasonable: if you have 5 sources entering your network, and one of them >>> is the place where all (or most) of the attack is coming from, you shut off >>> that source until you have a better filter. >>> >>> If a whole lot of devices assume the direct path is the preferred path, that >>> would be bad for them. >>> >>> Furthermore, there is additional data sent to the emergency system (in the >>> U.S.) with the call from the service provider. That information may be >>> useful in helping you. The device can actually send the information, but >>> while while we are pretty sure we can get most service providers to give it >>> to us, we are pessimistic most devices will. Devices that have sensors, >>> where the sensor data is useful for emergency calls may very well do it. >>> Medical monitoring devices for example. NENA will be asking the IETF to >>> standardize this soon, so that all service providers anywhere could provide >>> it to all emergency services. It has things like subscriber (as opposed to >>> caller) contact data, class of service information, SP contact data, etc. >>> When things go wrong, the PSAP will often contact the SP and get help. The >>> SP often has tools and mechanisms that CAN help. >>> >>> Brian >>> >>> >>> On 10/29/09 5:46 PM, "Marc Linsner" wrote: >>> >>>> Brian, >>>> >>>> I didn't read anything in the draft that stated devices 'should' use this >>>> mechanism (if it's there, it needs removed). I read it more as a device >>>> 'could' use this mechanism (as in an alternative to other mechanisms). >>>> >>>> Further, since the ESRP is controlled by the PSAP, it certainly would be a >>>> PSAP policy decision whether to support this mechanism. As without the >>>> ESRP >>>> support of unknown UA registrations, the mechanism doesn't work. >>>> >>>> BTW, the term 'unregistered' is not in phonebcp. I think your are >>>> stretching the 'normal call path' to include registration with >>>> something(?). >>>> I find nothing in phonebcp that disallows 'direct' calls to an ESRP. If I >>>> contact an ESRP from my UA 'directly', as long as the PSAP can call-back >>>> using the Contact header I sent in the invite and my AOR leads back to my >>>> UA, I've satisfied phonebcp. >>>> >>>> What am I missing? >>>> >>>> -Marc- >>>> >>>> >>>> On 10/29/09 4:35 PM, "Brian Rosen" wrote: >>>> >>>>> The IETF writing standards that describe how devices should bypass their >>>>> service provider and place emergency calls direct is not a PSAP policy >>>>> issue. >>>>> >>>>> I'm satisfied with the current -phonebcp dictum to send calls on the >>>>> normal >>>>> call path. For an "unregistered" device, that will not allow any "calls" >>>>> including emergency calls. >>>>> >>>>> I discussed this draft on the NENA LTD meeting this morning. That may >>>>> generate some list discussion from some PSAP people who are subscribed. I >>>>> would also like to hear from more PSAP folks on this subject. >>>>> >>>>> Brian >>>>> >>>>> >>>>> On 10/29/09 3:27 PM, "Marc Linsner" wrote: >>>>> >>>>>> These are all PSAP policy decisions. Just as it's a PSAP policy decision >>>>>> to >>>>>> support the suggested mechanism in the draft. Existence of the document >>>>>> describing the mechanism doesn't force PSAP policy. >>>>>> >>>>>> I personally would like to see some PSAPs and/or PS jurisdictions line up >>>>>> behind the draft before it proceeds, but I don't see any harm in it going >>>>>> forward. >>>>>> >>>>>> Of course, I'm dreaming about this special place where a PSAP actually >>>>>> wants >>>>>> to enable communication with all their customers and not force them to be >>>>>> a >>>>>> member of a special club. >>>>>> >>>>>> [non-chair hat on] >>>>>> >>>>>> -Marc- >>>>>> >>>>>> >>>>>> On 10/29/09 2:35 PM, "Brian Rosen" wrote: >>>>>> >>>>>>> Thank you. That is what I meant, and you said it better than I was >>>>>>> going >>>>>>> to. >>>>>>> >>>>>>> We may also have some transitive relationships: that is, if there is a >>>>>>> "local" PSAP that trusts that they have done so, other PSAPs may trust >>>>>>> that >>>>>>> they have done so. >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>> On 10/29/09 11:48 AM, "DRAGE, Keith (Keith)" >>>>>>> wrote: >>>>>>> >>>>>>>> I suspect that what Brian is saying is that anyone can be a service >>>>>>>> provider >>>>>>>> (or whatever else you want to call it) in this case provided that: >>>>>>>> >>>>>>>> 1) they make that agreement with the PSAP providers they route >>>>>>>> calls >>>>>>>> to; >>>>>>>> >>>>>>>> 2) they authenticate the calls requests to a level of security >>>>>>>> that >>>>>>>> meets >>>>>>>> the PSAPs (and any legal) requirements; >>>>>>>> >>>>>>>> 3) the PSAP trusts that they have done so. >>>>>>>> >>>>>>>> While this would normally be what we would understand as public >>>>>>>> telecommuncation operators, it doesn't mean they have to be. >>>>>>>> >>>>>>>> regards >>>>>>>> >>>>>>>> Keith >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>>>>>>>> On Behalf Of Marc Linsner >>>>>>>>> Sent: Thursday, October 29, 2009 12:32 PM >>>>>>>>> To: Brian Rosen >>>>>>>>> Cc: ecrit@ietf.org >>>>>>>>> Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>>>>>>> considered >>>>>>>>> >>>>>>>>> Brian, >>>>>>>>> >>>>>>>>> Please define what you consider to be a service provider. >>>>>>>>> >>>>>>>>> Is Skype a service? >>>>>>>>> Is Jabber a service? >>>>>>>>> Is Google Voice a service? >>>>>>>>> Is mydomain.com hosted on a commercial site a service? >>>>>>>>> Is mydomain.com hosted on a home server a service? >>>>>>>>> Is myEnterpriseVoIP.com a service? >>>>>>>>> >>>>>>>>> So, what you are saying that if I can make calls via all of >>>>>>>>> the above, it's OK for all of the above to contact an ESRP? >>>>>>>>> >>>>>>>>> Are you requiring that I have a full-time proxy on-line for >>>>>>>>> mydomain.com or can I simply run a transient UA and dynamic DNS? >>>>>>>>> >>>>>>>>> -Marc- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/28/09 11:17 PM, "Brian Rosen" wrote: >>>>>>>>> >>>>>>>>>> I'm not worried about security by obscurity. I don't want >>>>>>>>> phones (or >>>>>>>>>> other >>>>>>>>>> devices) built to call directly. >>>>>>>>>> >>>>>>>>>> -phonebcp says "send the call on your normal outbound call path". >>>>>>>>>> That's what I want it to say, and I don't want it to say "send it >>>>>>>>>> direct, bypass your service provider. >>>>>>>>>> >>>>>>>>>> I'm not stopping attack, I am stopping abuse. >>>>>>>>>> >>>>>>>>>> I don't want devices that are not subscribed to services to >>>>>>>>> be able to >>>>>>>>>> make emergency calls (that is, if they can't make "normal" >>>>>>>>> calls, they >>>>>>>>>> should not be able to make emergency calls). >>>>>>>>>> >>>>>>>>>> Brian >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 10/28/09 6:51 PM, "Marc Linsner" wrote: >>>>>>>>>> >>>>>>>>>>> Brian, >>>>>>>>>>> >>>>>>>>>>> What I hear you saying: 'if we don't document how to spoof a PSAP, >>>>>>>>>>> then nobody will figure it out.' Isn't that a little >>>>>>>>> short sighted? >>>>>>>>>>> >>>>>>>>>>> Joey@miscreant.org will figure out how to establish a SIP session >>>>>>>>>>> with any PSAP in the world within 10 minutes of that PSAP being >>>>>>>>>>> accessible via the Internet, regardless of documentation. >>>>>>>>>>> >>>>>>>>>>> I believe there's more harm created in not documenting this for >>>>>>>>>>> John.Q.Public@ordinary_citizen.com. >>>>>>>>>>> >>>>>>>>>>> Granted, nobody here is looking to cause harm to a PSAP. But >>>>>>>>>>> Joey@miscreant.org can certainly expend public safety resources by >>>>>>>>>>> reporting a bomb threat to a local school. Should we require that >>>>>>>>>>> all SIP calls to the local school come from a trusted SP? >>>>>>>>> Where does it end? >>>>>>>>>>> >>>>>>>>>>> This isn't the way to deal with spam. >>>>>>>>>>> >>>>>>>>>>> -Marc- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 10/27/09 11:00 AM, "Brian Rosen" wrote: >>>>>>>>>>> >>>>>>>>>>>> The first goal is to prevent bad calls. >>>>>>>>>>>> >>>>>>>>>>>> The second goal is to indentify the source of the bad calls. >>>>>>>>>>>> >>>>>>>>>>>> I'm starting with the first goal. I don't want you to be able to >>>>>>>>>>>> take a device out of a box, plug it into a network, and have the >>>>>>>>>>>> only call you can make be an emergency call. I want the >>>>>>>>> device to >>>>>>>>>>>> actually "work" (as in be able to place calls to all the entities >>>>>>>>>>>> that it was intended to) first, and then be able to place >>>>>>>>> emergency calls. >>>>>>>>>>>> >>>>>>>>>>>> Please spend some time in a PSAP while a kid with a >>>>>>>>> simless phone has "fun" >>>>>>>>>>>> with it. Imagine how much fun the test mechanism is as >>>>>>>>> opposed to >>>>>>>>>>>> placing real calls. >>>>>>>>>>>> >>>>>>>>>>>> If we somehow get a bad call, we need to send the cops. >>>>>>>>> That means >>>>>>>>>>>> we need an identity (and a location). >>>>>>>>>>>> >>>>>>>>>>>> I think a good cert could be the basis of a good identity, if we >>>>>>>>>>>> could get one. I don't see how we do that. >>>>>>>>>>>> >>>>>>>>>>>> Brian >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/27/09 10:39 AM, "Richard Barnes" wrote: >>>>>>>>>>>> >>>>>>>>>>>> Brian, >>>>>>>>>>>> >>>>>>>>>>>> Is the security goal here more access control (i.e., controlling >>>>>>>>>>>> who can send calls to a PSAP) or attribution/identification for >>>>>>>>>>>> post-hoc action. >>>>>>>>>>>> >>>>>>>>>>>> If it's the latter, then ISTM that the problem can largely be >>>>>>>>>>>> reduced to having a certificate infrastructure that binds >>>>>>>>>>>> authenticated identities to real-world entities. The >>>>>>>>> "extended validation" >>>>>>>>>>>> certificates that current commercial CAs issue seem to largely >>>>>>>>>>>> satisfy this requirement. >>>>>>>>>>>> >>>>>>>>>>>> --Richard >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Oct 27, 2009, at 4:31 PM, Brian Rosen wrote: >>>>>>>>>>>> >>>>>>>>>>>> Of course not all VSPs will have trust relationships with all >>>>>>>>>>>> PSAPs. One can hope that long term, we can evolve to >>>>>>>>> transitive >>>>>>>>>>>> trust relationships that work pretty well cross border. >>>>>>>>>>>> >>>>>>>>>>>> The emergency guys are actually terrified of private/individual >>>>>>>>>>>> domains sending them calls, and we're telling them we >>>>>>>>> expect that >>>>>>>>>>>> to be possible, but rare, and we're giving them mechanisms that >>>>>>>>>>>> will effectively allow them to turn off calls >>>>>>>>> selectively, based >>>>>>>>>>>> on factors including what domain the call comes from. >>>>>>>>> They expect >>>>>>>>>>>> that such calls will be one of the loopholes where they get >>>>>>>>>>>> equivalents to sim-less calls, which drive them nuts. >>>>>>>>> They don't >>>>>>>>>>>> want ANY calls that don't come from service providers, although >>>>>>>>>>>> they seem to be okay with the notion that the SP may not have >>>>>>>>>>>> great identity (AOL being a poster child). So, while >>>>>>>>> indeed they >>>>>>>>>>>> understand, and have concerns about having to take calls from >>>>>>>>>>>> Sierra Leone VoIP services Pty, they would much rather >>>>>>>>> have a call >>>>>>>>>>>> that went through them then a call that went through no service >>>>>>>>>>>> provider at all. >>>>>>>>>>>> >>>>>>>>>>>> I'm not trying to make calls direct from devices or private >>>>>>>>>>>> domains impossible, but I think the notion that we're promoting >>>>>>>>>>>> them is a very bad idea until we have effective mechanisms to >>>>>>>>>>>> prevent abuse. >>>>>>>>>>>> >>>>>>>>>>>> Brian >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/27/09 9:02 AM, "Marc Linsner" wrote: >>>>>>>>>>>> >>>>>>>>>>>> Brian, >>>>>>>>>>>> >>>>>>>>>>>> I'm a little confused. I don't remember you objecting to >>>>>>>>>>>> requirement RE1 from RFC5012 and I remember your use >>>>>>>>> case about a >>>>>>>>>>>> Sierra Leone VSP. >>>>>>>>>>>> >>>>>>>>>>>> Are you implying that *all* VSPs will have a trust >>>>>>>>> relationships >>>>>>>>>>>> with *all* PSAPs? >>>>>>>>>>>> >>>>>>>>>>>> What is the difference between a call coming from a private/ >>>>>>>>>>>> individual domain (as in not a commercial VSP) and a >>>>>>>>> VSP on the >>>>>>>>>>>> other side of the world (outside the jurisdiction)? >>>>>>>>>>>> >>>>>>>>>>>> I'm trying to figure out whether you're objecting to anonymous >>>>>>>>>>>> calls to the PSAP or the mechanisms proposed in this draft? >>>>>>>>>>>> >>>>>>>>>>>> [Don't take this as my endorsement of the draft, as >>>>>>>>> I'm not sure >>>>>>>>>>>> I agree with UAs registering with the ESRP.] >>>>>>>>>>>> >>>>>>>>>>>> -Marc- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/26/09 8:59 PM, "Brian Rosen" wrote: >>>>>>>>>>>> >>>>>>>>>>>> First of all, I put it on the wrong email list, sorry >>>>>>>>> about that. >>>>>>>>>>>> >>>>>>>>>>>> Then, we have carefully arranged it so that there is >>>>>>>>> no identity >>>>>>>>>>>> coming from the access network provider, and because the >>>>>>>>>>>> location is coming from that provider, we really >>>>>>>>> don't want to. >>>>>>>>>>>> But even if we did, we would need a really good >>>>>>>>> identifier, and >>>>>>>>>>>> there isn't one. >>>>>>>>>>>> >>>>>>>>>>>> The problem we have with -direct is anonymous callers, and if >>>>>>>>>>>> they have any option, they would also be >>>>>>>>> location-less. Until >>>>>>>>>>>> and unless we get rid of anonymity, we can't >>>>>>>>> encourage service >>>>>>>>>>>> provider-less calls. The draft does not make any >>>>>>>>> provision to >>>>>>>>>>>> provide any kind of identity. Many networks (think free wifi >>>>>>>>>>>> for example) would make providing good identity difficult. >>>>>>>>>>>> >>>>>>>>>>>> The fact is that there is a SERVICE provider in >>>>>>>>> nearly all of the >>>>>>>>>>>> communications systems. The SERVICE provider is in >>>>>>>>> a position to >>>>>>>>>>>> assist >>>>>>>>>>>> the emergency calling system when it needs more information. >>>>>>>>>>>> That's what a >>>>>>>>>>>> good SERVICE provider does. Cutting them out is not a great >>>>>>>>>>>> idea. Most of the attempts to provide real time >>>>>>>>> communications >>>>>>>>>>>> between people have evolved to using service providers, even >>>>>>>>>>>> when there were alternatives. File transfer via >>>>>>>>> something like >>>>>>>>>>>> Torrent is a counterexample (which isn't real time), but even >>>>>>>>>>>> there, you end up with service providers like The Pirate Bay >>>>>>>>>>>> (R.I.P) to provide introduction services. I don't >>>>>>>>> think we're >>>>>>>>>>>> going to see changes that eliminate service providers, and in >>>>>>>>>>>> this case, they provide value to the emergency >>>>>>>>> calling systems. >>>>>>>>>>>> All of the emergency professionals I know have issues with >>>>>>>>>>>> service providers, but they would react with horror if you >>>>>>>>>>>> suggested cutting them out. Ask them, please. >>>>>>>>>>>> >>>>>>>>>>>> So, I claim you have a solution in search of a >>>>>>>>> problem. We have >>>>>>>>>>>> solved the "calling network isn't the access network" problem >>>>>>>>>>>> already. Service providers ARE in the path now, in >>>>>>>>> nearly every >>>>>>>>>>>> case (in fact a counter example escapes me, although there >>>>>>>>>>>> probably are some). There is no movement I can detect which >>>>>>>>>>>> would change that any time soon; quite the opposite. >>>>>>>>> We have a >>>>>>>>>>>> known killer problem without some kind of subscription to a >>>>>>>>>>>> service that provides a good identity, for which you >>>>>>>>> provide no >>>>>>>>>>>> answers. >>>>>>>>>>>> We have >>>>>>>>>>>> experience with the killer problem: sim-less calling was >>>>>>>>>>>> supposed to provide a way to make an emergency call >>>>>>>>> in exactly >>>>>>>>>>>> the kinds of circumstances you are describing. Our >>>>>>>>> real world >>>>>>>>>>>> experience is that you create a huge problem that diverts >>>>>>>>>>>> resources from helping people to chasing scammers and >>>>>>>>>>>> flea-market sellers. >>>>>>>>>>>> >>>>>>>>>>>> Nothing is perfect: you can get a AIM screen name >>>>>>>>> without a very >>>>>>>>>>>> good identity for example. However, the notion that >>>>>>>>> we're going >>>>>>>>>>>> to provide direct access without a service provider >>>>>>>>>>>> deliberately, especially without really good identity >>>>>>>>> from the >>>>>>>>>>>> access network is, in my opinion not only a no, it's >>>>>>>>> a heck no. >>>>>>>>>>>> I'll line up as many emergency service professionals as you >>>>>>>>>>>> would like to tell you this is a harmful idea. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/26/09 7:56 PM, "Dawson, Martin" >>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> I am glad this has come up. It's a debate that has >>>>>>>>> to happen if >>>>>>>>>>>> we are to move beyond a long standing legacy misconception. >>>>>>>>>>>> >>>>>>>>>>>> In the circuit service world - whether it was POTS >>>>>>>>> or mobile, >>>>>>>>>>>> the access network had full responsibility for >>>>>>>>> delivering the >>>>>>>>>>>> emergency call. In that world, routing an emergency >>>>>>>>> call meant >>>>>>>>>>>> getting a circuit established to the correct call center. In >>>>>>>>>>>> most parts of the world, this was done using the >>>>>>>>> regional part >>>>>>>>>>>> of the PSTN to switch the circuit to a call center >>>>>>>>> on the PSTN. >>>>>>>>>>>> In some jurisdictions, such as the US, it was done directly >>>>>>>>>>>> from the local exchange carrier to the call center. >>>>>>>>> Either way, >>>>>>>>>>>> there was no third party involved. >>>>>>>>>>>> >>>>>>>>>>>> Now we have the Internet. We still have public >>>>>>>>> access network >>>>>>>>>>>> providers. >>>>>>>>>>>> They >>>>>>>>>>>> switch packets onto the Internet for their subscribers. They >>>>>>>>>>>> can similarly ensure that packets reach the local emergency >>>>>>>>>>>> call centers. >>>>>>>>>>>> >>>>>>>>>>>> The fact is that there was no equivalent of a VSP in the >>>>>>>>>>>> traditional environment. VoIP is a presence service, >>>>>>>>> and it had >>>>>>>>>>>> no common equivalent in the PSTN world. It could >>>>>>>>> have, but the >>>>>>>>>>>> narrowband state of technology and the common market >>>>>>>>> use cases >>>>>>>>>>>> didn't support its development. By the time ISDN >>>>>>>>> arrived, the >>>>>>>>>>>> PSTN had already slipped into its palliative stage without >>>>>>>>>>>> realizing it. >>>>>>>>>>>> >>>>>>>>>>>> It's an entrenched misconception that because the circuit >>>>>>>>>>>> service provided by exchange carriers was most commonly used >>>>>>>>>>>> for "voice" (but, it should be noted, also for fax, >>>>>>>>> telex, tty, >>>>>>>>>>>> security system monitoring and, even, IP data) that VSPs are >>>>>>>>>>>> somehow equivalent to exchange carriers. They are not. >>>>>>>>>>>> >>>>>>>>>>>> Indeed, involving VSPs in emergency calls is the Internet >>>>>>>>>>>> equivalent of involving long distance providers in POTS >>>>>>>>>>>> emergency calls. They are neither necessary nor particularly >>>>>>>>>>>> helpful; they can't be guaranteed to be within the emergency >>>>>>>>>>>> jurisdiction; depending on them actually diminishes the >>>>>>>>>>>> efficacy of emergency service access. It does not help the >>>>>>>>>>>> caller, the emergency service, nor the third party >>>>>>>>> to insist on >>>>>>>>>>>> the third party's involvement. >>>>>>>>>>>> >>>>>>>>>>>> It can't be helped if you have over sold the benefits of VSP >>>>>>>>>>>> involvement to yourself and others Brian. It is time >>>>>>>>> to have a >>>>>>>>>>>> reasoned debate. >>>>>>>>>>>> From my >>>>>>>>>>>> perspective, the argument that there is no "subscription" >>>>>>>>>>>> involved is >>>>>>>>>>>> patently >>>>>>>>>>>> false. There has to be a subscription of some description in >>>>>>>>>>>> order to get to the Internet. Yes, there is free public >>>>>>>>>>>> Internet access (just as there are free courtesy >>>>>>>>> phones on the >>>>>>>>>>>> PSTN and free access to emergency services from pay >>>>>>>>> phones. All >>>>>>>>>>>> these services are still connected to the public Internet >>>>>>>>>>>> infrastructure and they all represent an "operator" >>>>>>>>> with some >>>>>>>>>>>> level of information about the caller. >>>>>>>>>>>> >>>>>>>>>>>> With the over-emphasis on VSPs, what is missing from >>>>>>>>> the ECRIT >>>>>>>>>>>> and i3 models is the direct interface for querying >>>>>>>>> the access >>>>>>>>>>>> network for subscriber data (should it prove >>>>>>>>> necessary). These >>>>>>>>>>>> models need to take the long view of how emergency >>>>>>>>> calling is >>>>>>>>>>>> done in the Internet age; they should not be protracting an >>>>>>>>>>>> unnecessary reliance on VSPs. >>>>>>>>>>>> >>>>>>>>>>>> I have deleted the premature and prejudicial text from the >>>>>>>>>>>> subject heading. >>>>>>>>>>>> And I'll leave this on ECRIT as the most appropriate WG. >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> Martin >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: ecrit-bounces@ietf.org >>>>>>>>> [mailto:ecrit-bounces@ietf.org] On >>>>>>>>>>>> Behalf Of Hannes Tschofenig >>>>>>>>>>>> Sent: Tuesday, 27 October 2009 8:23 AM >>>>>>>>>>>> To: ecrit@ietf.org >>>>>>>>>>>> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct >>>>>>>>>>>> considered harmful, at least given our current experiences >>>>>>>>>>>> >>>>>>>>>>>> FYI: feedback from Brian regarding a recent ECRIT >>>>>>>>> contribution. >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: geopriv-bounces@ietf.org >>>>>>>>>>>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian >>>>>>>>>>>> Sent: 26 October, 2009 23:10 >>>>>>>>>>>> To: geopriv@ietf.org >>>>>>>>>>>> Subject: [Geopriv] Winterbottom-ecrit-direct considered >>>>>>>>>>>> harmful, at least given our current experiences >>>>>>>>>>>> >>>>>>>>>>>> The notion behind -direct is to not use a service >>>>>>>>> provider to >>>>>>>>>>>> place an emergency call. Instead, the device >>>>>>>>> registers with >>>>>>>>>>>> an Emergency Services Routing Proxy immediately before the >>>>>>>>>>>> call and the call is routed directly from the >>>>>>>>> device to the ESRP. >>>>>>>>>>>> >>>>>>>>>>>> At least at the moment, this is an exceedingly bad idea. >>>>>>>>>>>> >>>>>>>>>>>> Emergency calling authorities like service providers, a lot. >>>>>>>>>>>> They like them because they can hold them >>>>>>>>> accountable, and the >>>>>>>>>>>> service providers don't like theft of service, which is >>>>>>>>>>>> something the emergency call guys have an analog to. >>>>>>>>>>>> >>>>>>>>>>>> The facts are that where unaccountable access to emergency >>>>>>>>>>>> calling is allowed, huge numbers of false calls >>>>>>>>> occur, with no >>>>>>>>>>>> way to stop them, and no way to tell the good ones from the >>>>>>>>>>>> bad ones. This has been seen multiple times where >>>>>>>>> so called >>>>>>>>>>>> "simless" or "unauthenticated" calls are allowed. >>>>>>>>>>>> >>>>>>>>>>>> -direct precisely duplicates simless calling. The only >>>>>>>>>>>> "registration" is an emergency registration, only emergency >>>>>>>>>>>> calls are allowed, any device can make an emergency call if >>>>>>>>>>>> all it has is a (radio) connection to any network. >>>>>>>>>>>> We can predict, with a very high degree of >>>>>>>>> certainty, that the >>>>>>>>>>>> feature will be horribly abused: for example to test that a >>>>>>>>>>>> phone without a service plan works. >>>>>>>>>>>> >>>>>>>>>>>> There have been studies which show tens of thousands of bad >>>>>>>>>>>> calls with zero good ones. Nearly every authority I know >>>>>>>>>>>> where the regulator has insisted on simless calling >>>>>>>>> wants it >>>>>>>>>>>> repealed. There is one counter example I know >>>>>>>>> where the fact >>>>>>>>>>>> that they got a couple, literally, of good calls among the >>>>>>>>>>>> tens of thousands of bad calls was considered >>>>>>>>> enough reason to >>>>>>>>>>>> put up with the problem. >>>>>>>>>>>> >>>>>>>>>>>> Service providers give us information that may be useful: a >>>>>>>>>>>> subscriber name and address for example, which is not >>>>>>>>>>>> spoofable by the caller. They have ways to trace callers, >>>>>>>>>>>> especially bad callers. They don't want their >>>>>>>>> systems abused >>>>>>>>>>>> any more than the emergency calling authorities do. >>>>>>>>>>>> >>>>>>>>>>>> This is a bad idea. A very bad idea. Please stop it. >>>>>>>>>>>> >>>>>>>>>>>> Someday, we may have better ways to prevent abuse. Until we >>>>>>>>>>>> do, service providers are a good thing on an emergency call. >>>>>>>>>>>> We don't want them cut out. >>>>>>>>>>>> >>>>>>>>>>>> Brian >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Geopriv mailing list >>>>>>>>>>>> Geopriv@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 bernard_aboba@hotmail.com Sat Oct 31 18:16:03 2009 Return-Path: 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 B14053A67E3 for ; Sat, 31 Oct 2009 18:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.018 X-Spam-Level: X-Spam-Status: No, score=0.018 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.56] 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 q0zz+LripNmT for ; Sat, 31 Oct 2009 18:16:03 -0700 (PDT) Received: from blu0-omc2-s13.blu0.hotmail.com (blu0-omc2-s13.blu0.hotmail.com [65.55.111.88]) by core3.amsl.com (Postfix) with ESMTP id D16ED3A672E for ; Sat, 31 Oct 2009 18:16:02 -0700 (PDT) Received: from BLU137-W26 ([65.55.111.73]) by blu0-omc2-s13.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 31 Oct 2009 18:16:21 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_d53bf852-28f1-42ac-8104-64a941983daa_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: , , Date: Sat, 31 Oct 2009 18:16:21 -0700 Importance: Normal In-Reply-To: References: X-OriginalArrivalTime: 01 Nov 2009 01:16:21.0061 (UTC) FILETIME=[EBC1AF50:01CA5A90] Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered 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: , X-List-Received-Date: Sun, 01 Nov 2009 01:16:03 -0000 MIME-Version: 1.0 --_d53bf852-28f1-42ac-8104-64a941983daa_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > It's not that I necessarily believe there will be a lack of SPs. I belie= ve > the mix of SPs and the products they offer will change dramatically at a > pace that PSAPs won't be able to keep up. This week Google=2C next week > Noggle=2C the next week Boogle=2C etc. If in fact the PSAP requires > relationships with every SP that may send an emergency call their way=2C = it > will only stifle innovation. There is a fundamental scaling problem here that can't just be wished away.= =20 It doesn't strike me as realistic for PSAPs to maintain a large number of bi-lateral relationships=2C whether they be with SPs anywhere on earth=2C=20 enterprise networks operating in their service areas=2C or local access networks. This isn't a constraint that is created by the choice of security technology (e.g. certificates vs. passwords or=20 pre-shared keys)=3B it's fundamental.=20 The only way to get around this scaling problem is by introducing hierarchy. However=2C we shouldn't necessarily assume that the hierarchy=20 corresponds to today's notion of a "service provider". =20 = --_d53bf852-28f1-42ac-8104-64a941983daa_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B It's not that I necessarily believe there will be a lack of SPs.= I believe
>=3B the mix of SPs and the products they offer will chang= e dramatically at a
>=3B pace that PSAPs won't be able to keep up. Th= is week Google=2C next week
>=3B Noggle=2C the next week Boogle=2C etc= . If in fact the PSAP requires
>=3B relationships with every SP that = may send an emergency call their way=2C it
>=3B will only stifle innov= ation.

There is a fundamental scaling problem here that can't just b= e wished away.
It doesn't strike me as realistic for PSAPs to maintain = a large number of
bi-lateral relationships=2C whether they be with SPs a= nywhere on earth=2C
enterprise networks operating in their service area= s=2C or local
access networks. =3B This isn't a constraint that is c= reated by the
choice of security technology (e.g. certificates vs. passw= ords or
pre-shared keys)=3B =3B it's fundamental.

The only = way to get around this scaling problem is by introducing
hierarchy. = =3B However=2C we shouldn't necessarily assume that the hierarchy
corre= sponds to today's notion of a "service provider". =3B
<= /body> = --_d53bf852-28f1-42ac-8104-64a941983daa_--