From jbakker@rim.com Thu Dec 3 11:44: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 675003A6907 for ; Thu, 3 Dec 2009 11:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[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 vmtYiuKt4bGB for ; Thu, 3 Dec 2009 11:44:49 -0800 (PST) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 3BE903A68C2 for ; Thu, 3 Dec 2009 11:44:48 -0800 (PST) X-AuditID: 0a666446-b7beeae0000071a4-51-4b181526e3f3 Received: from XCH38YKF.rim.net ( [10.64.31.208]) by mhs04ykf.rim.net (RIM Mail) with SMTP id 9A.7D.29092.625181B4; Thu, 3 Dec 2009 14:44:38 -0500 (EST) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH38YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Dec 2009 14:44:38 -0500 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: Thu, 3 Dec 2009 13:44:36 -0600 Message-ID: In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4501D64FE1@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] draft-schulzrinne-ecrit-psap-callback-01 thread-index: AcpbUEVjLlYbx2LVSRq34DcCu/C/5QY+w5yg References: <3D3C75174CB95F42AD6BCC56E5555B4501D64FE1@FIESEXC015.nsn-intra.net> From: "John-Luc Bakker" To: X-OriginalArrivalTime: 03 Dec 2009 19:44:38.0516 (UTC) FILETIME=[0C8C1340:01CA7451] X-Brightmail-Tracker: AAAAAwAAAZER89XLEfPVzA== Subject: Re: [Ecrit] draft-schulzrinne-ecrit-psap-callback-01 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, 03 Dec 2009 19:44:50 -0000 Hello all, When reading the -01 version of the draft I noticed the analyses of solutions for "verifying the caller is a PSAP": To fulfill the requirements of verifying the caller is a PSAP, mechanisms such as those described in RFC 4474 [RFC4474] or in RFC 3325 [RFC3325] are recommended to be used. Such an approach would mitigate security vulnerabilities, but does not explicitly mark the request generated from the PSAP as a request for callback. Additional information, such a PSAP whitelist, would have to be known. This is, however, only likely to work in a smaller scale rather than world wide. I will note that I have not been part of some related discussions so bear with me, please. I agree that usage of RFC 4474 or RFC 3325 does not indicate the call as being related to a previous call. These descriptions in these RFCs are used to verify a caller. They don't seem to address the property of being able to distinguish between a stand-alone call attempt and a call attempt related to a previous call. The Reply-To header approach (discussed earlier in the draft) could perhaps be used to address that property. Can somebody clarify the need for the suggested PSAP whitelist? If the PSAP is identified by means of a service URN, e.g. specified in RFC5031, then no whitelists seems needed or, if not all emergency service URN are allowed to bypass e.g. call hold, each white lists would still have a quite manageable size? I don't understand the sentence "This is, however, only likely to work in a smaller scale rather than world wide". Isn't it so that this solution is applicable where at least RFC 4474 or RFC 3325 are implemented? Kind regards, John-Luc --- John-Luc Bakker Standards Manager Research In Motion BlackBerry: +1 (908) 463 7321 Office: +1 (972) 373-1761 Internal: (820) 63761 E-mail: jbakker@rim.com -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Sunday, November 01, 2009 7:33 PM To: ecrit@ietf.org Subject: [Ecrit] draft-schulzrinne-ecrit-psap-callback-01 Hi all, please take a look at the updated PSAP callback marking document. With this version Milan helped us to incorporate more text about the solution approaches. When Marc and I had a discussion with Cullen and Robert about the milestone updates Cullen indicated that he would like to see an agreement from the group on the solution approach before the document can be added to the milestone list. Furthermore, in the recent 3GPP-IETF conference call we learned that there is interest from the 3GPP in a solution about PSAP callback marking. Milan and Keith are keeping an eye on the requirements from the 3GPP side. Milan has also written another document that could be interesting to consider in this specific context, namely draft-patel-dispatch-cpc-oli-parameter. It provides a solution for an environment that relies on a chain of trust. That's certainly a starting point. But when considering an Internet context then this security model might not be appropriate and we may need an additional solutions. This is similar to the PAI vs. SIP Identity story. It would be great to hear your thoughts about this issue and have a look at the updated document: http://tools.ietf.org/html/draft-schulzrinne-ecrit-psap-callback-01 Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From hannes.tschofenig@nsn.com Fri Dec 4 00:27: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 238A43A688C for ; Fri, 4 Dec 2009 00:27:37 -0800 (PST) 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=[AWL=0.000, 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 HT3zfkanu6G4 for ; Fri, 4 Dec 2009 00:27:36 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 31E1D3A67AE for ; Fri, 4 Dec 2009 00:27:34 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nB48RNOa025816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 4 Dec 2009 09:27:23 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nB48RMcW030216; Fri, 4 Dec 2009 09:27:23 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Dec 2009 09:27:22 +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: Fri, 4 Dec 2009 10:30:56 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4501F4EB92@FIESEXC015.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] draft-schulzrinne-ecrit-psap-callback-01 Thread-Index: AcpbUEVjLlYbx2LVSRq34DcCu/C/5QY+w5ygABtzpiA= References: <3D3C75174CB95F42AD6BCC56E5555B4501D64FE1@FIESEXC015.nsn-intra.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext John-Luc Bakker" , X-OriginalArrivalTime: 04 Dec 2009 08:27:22.0828 (UTC) FILETIME=[9A33E8C0:01CA74BB] Subject: Re: [Ecrit] draft-schulzrinne-ecrit-psap-callback-01 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, 04 Dec 2009 08:27:37 -0000 Hi John-Luc,=20 >Hello all, > >When reading the -01 version of the draft I noticed the=20 >analyses of solutions for "verifying the caller is a PSAP": > > To fulfill the requirements of verifying the caller is a PSAP, > mechanisms such as those described in RFC 4474 [RFC4474] or in RFC > 3325 [RFC3325] are recommended to be used. Such an approach would > mitigate security vulnerabilities, but does not explicitly mark the > request generated from the PSAP as a request for callback. > Additional information, such a PSAP whitelist, would have to be > known. This is, however, only likely to work in a smaller scale > rather than world wide. > >I will note that I have not been part of some related=20 >discussions so bear with me, please. > >I agree that usage of RFC 4474 or RFC 3325 does not indicate=20 >the call as being related to a previous call. >These=20 >descriptions in these RFCs are used to verify a caller. Correct. It is purely about asserting the identity of the party that = issued the callback (or any other communication attempt).=20 > They=20 >don't seem to address the property of being able to=20 >distinguish between a stand-alone call attempt and a call=20 >attempt related to a previous call. Completely true.=20 >The Reply-To header=20 >approach (discussed earlier in the draft) could perhaps be=20 >used to address that property. Yes. This, however, requires that devices along the path say the initial = call attempt from the emergency caller to the PSAP and that these = devices stored some state.=20 This is then more or less what is in Phone BCP already.=20 As I wrote in the introduction there are cases where the path taken by = the callback is different from the initial call and then no such state = would be available. I was asking the group of how big that problem is and I did not really = got any feedback.=20 =20 > >Can somebody clarify the need for the suggested PSAP=20 >whitelist? If the PSAP is identified by means of a service=20 >URN, e.g. specified in RFC5031, then no whitelists seems=20 >needed or, if not all emergency service URN are allowed to=20 >bypass e.g. call hold, each white lists would still have a=20 >quite manageable size? The PSAP whitelist is a sort of "na=EFve" approach. Assume you know the = identities of all PSAPs (in a region or in the world), because it is = stored somewhere in a registry, then one could create a white list = (assuming that the identities provided in the SIP exchange are of any = value) and perform the desired treatment.=20 When you think of a regional setting then this is indeed something that = would work as it is quite likely that VSPs and PSAPs are going to = establish some "relationship".=20 For the broader Internet sense this would not work but there one can = argue that it might not be necessary since most users would come from a = small set of VSPs/ASPs anyway.=20 Just thinking loud... > >I don't understand the sentence "This is, however, only likely=20 >to work in a smaller scale rather than world wide". Isn't it=20 >so that this solution is applicable where at least RFC 4474 or=20 >RFC 3325 are implemented? These two RFCs only provide the identity assurance but they do not say = anything about the authorization decision being performed with these = identities afterwards. Often the authorization mechanism is more complex = than the plain identity assurance.=20 So, in our case the usage of a white list was suggested but this = requires that someone creates such a white list and more important keeps = it up-to-date. This party has to assure that the entires are actually = legitimate PSAPs, i.e. the quality of the registration process is sort = of important. As the number of PSAPs (or in general devices that may issue the = communication towards a VSP/ASP) grows the management of the white list = becomes non-trivial. Why do I say that? Because we can observe these = problems in other areas as well (e.g., Email security, Internet Identity = Management, etc.) Does my response make any sense?=20 Ciao Hannes > >Kind regards, > > John-Luc > >--- >John-Luc Bakker >Standards Manager >Research In Motion >BlackBerry: +1 (908) 463 7321 >Office: +1 (972) 373-1761 >Internal: (820) 63761 >E-mail: jbakker@rim.com >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) >Sent: Sunday, November 01, 2009 7:33 PM >To: ecrit@ietf.org >Subject: [Ecrit] draft-schulzrinne-ecrit-psap-callback-01 > >Hi all,=20 > >please take a look at the updated PSAP callback marking=20 >document. With this version Milan helped us to incorporate=20 >more text about the solution approaches.=20 > >When Marc and I had a discussion with Cullen and Robert about=20 >the milestone updates Cullen indicated that he would like to=20 >see an agreement from the group on the solution approach=20 >before the document can be added to the milestone list. > >Furthermore, in the recent 3GPP-IETF conference call we=20 >learned that there is interest from the 3GPP in a solution=20 >about PSAP callback marking. Milan and Keith are keeping an=20 >eye on the requirements from the 3GPP side. =20 > >Milan has also written another document that could be=20 >interesting to consider in this specific context, namely=20 >draft-patel-dispatch-cpc-oli-parameter. It provides a solution=20 >for an environment that relies on a chain of trust.=20 > >That's certainly a starting point. But when considering an=20 >Internet context then this security model might not be=20 >appropriate and we may need an additional solutions. This is=20 >similar to the PAI vs. SIP Identity story.=20 > >It would be great to hear your thoughts about this issue and=20 >have a look at the updated document: >http://tools.ietf.org/html/draft-schulzrinne-ecrit-psap-callback-01 > >Ciao >Hannes >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > >--------------------------------------------------------------------- >This transmission (including any attachments) may contain=20 >confidential information, privileged material (including=20 >material protected by the solicitor-client or other applicable=20 >privileges), or constitute non-public information. Any use of=20 >this information by anyone other than the intended recipient=20 >is prohibited. If you have received this transmission in=20 >error, please immediately reply to the sender and delete this=20 >information from your system. Use, dissemination,=20 >distribution, or reproduction of this transmission by=20 >unintended recipients is not authorized and may be unlawful. >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > From br@brianrosen.net Mon Dec 7 07:17:11 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 7D61028C198 for ; Mon, 7 Dec 2009 07:17:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=0.262, 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 uvR-xA6j6Qp9 for ; Mon, 7 Dec 2009 07:17:10 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 2170628C191 for ; Mon, 7 Dec 2009 07:17:10 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.231]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1NHfKT-0002Vt-GT; Mon, 07 Dec 2009 09:16:49 -0600 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Mon, 07 Dec 2009 10:16:44 -0500 From: Brian Rosen To: "Tschofenig, Hannes (NSN - FI/Espoo)" , ext John-Luc Bakker , Message-ID: Thread-Topic: [Ecrit] draft-schulzrinne-ecrit-psap-callback-01 Thread-Index: AcpbUEVjLlYbx2LVSRq34DcCu/C/5QY+w5ygABtzpiAApcmnhg== In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4501F4EB92@FIESEXC015.nsn-intra.net> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable 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] draft-schulzrinne-ecrit-psap-callback-01 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, 07 Dec 2009 15:17:11 -0000 We have looked into whitelist mechanisms for use in the U.S. on the current emergency call system. It is very complex. The problem is that the outgoing call really is a normal enterprise/local government phone call. I= t thus goes through a myriad of connection arrangements, carriers and facilities, that are not documented in any way that would allow a whitelist to be created. We were looking into establishing list of telephone numbers that could be used for call backs. We were willing to have a failsafe policy of allowing numbers where every call may not be a callback, but at least some calls from that TN could be a callback. The complexity of creating such a database, here at least, is very high. It would require identifying the responsible telecom contacts in all 6000+ PSAPs, get them (all) to cooperate in identifying trunks that the PSAP could place callbacks, determining the TNs associated with those trunks, and effectivel= y surveying these people periodically to find out if anything changed. While we might be able to make the situation somewhat better for our next generation IP based systems, I think it will be hard to build a whitelist. Brian =20 On 12/4/09 3:30 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" wrote: > Hi John-Luc,=20 >=20 >> Hello all, >>=20 >> When reading the -01 version of the draft I noticed the >> analyses of solutions for "verifying the caller is a PSAP": >>=20 >> To fulfill the requirements of verifying the caller is a PSAP, >> mechanisms such as those described in RFC 4474 [RFC4474] or in RFC >> 3325 [RFC3325] are recommended to be used. Such an approach would >> mitigate security vulnerabilities, but does not explicitly mark the >> request generated from the PSAP as a request for callback. >> Additional information, such a PSAP whitelist, would have to be >> known. This is, however, only likely to work in a smaller scale >> rather than world wide. >>=20 >> I will note that I have not been part of some related >> discussions so bear with me, please. >>=20 >> I agree that usage of RFC 4474 or RFC 3325 does not indicate >> the call as being related to a previous call. >> These=20 >> descriptions in these RFCs are used to verify a caller. >=20 >=20 > Correct. It is purely about asserting the identity of the party that issu= ed > the callback (or any other communication attempt). >=20 >=20 >> They=20 >> don't seem to address the property of being able to >> distinguish between a stand-alone call attempt and a call >> attempt related to a previous call. >=20 > Completely true.=20 >=20 >> The Reply-To header >> approach (discussed earlier in the draft) could perhaps be >> used to address that property. >=20 > Yes. This, however, requires that devices along the path say the initial = call > attempt from the emergency caller to the PSAP and that these devices stor= ed > some state.=20 >=20 > This is then more or less what is in Phone BCP already. >=20 > As I wrote in the introduction there are cases where the path taken by th= e > callback is different from the initial call and then no such state would = be > available. >=20 > I was asking the group of how big that problem is and I did not really go= t any > feedback.=20 >=20 > =20 >>=20 >> Can somebody clarify the need for the suggested PSAP >> whitelist? If the PSAP is identified by means of a service >> URN, e.g. specified in RFC5031, then no whitelists seems >> needed or, if not all emergency service URN are allowed to >> bypass e.g. call hold, each white lists would still have a >> quite manageable size? >=20 > The PSAP whitelist is a sort of "na=EFve" approach. Assume you know the > identities of all PSAPs (in a region or in the world), because it is stor= ed > somewhere in a registry, then one could create a white list (assuming tha= t the > identities provided in the SIP exchange are of any value) and perform the > desired treatment. >=20 > When you think of a regional setting then this is indeed something that w= ould > work as it is quite likely that VSPs and PSAPs are going to establish som= e > "relationship".=20 >=20 > For the broader Internet sense this would not work but there one can argu= e > that it might not be necessary since most users would come from a small s= et of > VSPs/ASPs anyway. >=20 > Just thinking loud... >=20 >>=20 >> I don't understand the sentence "This is, however, only likely >> to work in a smaller scale rather than world wide". Isn't it >> so that this solution is applicable where at least RFC 4474 or >> RFC 3325 are implemented? >=20 > These two RFCs only provide the identity assurance but they do not say > anything about the authorization decision being performed with these > identities afterwards. Often the authorization mechanism is more complex = than > the plain identity assurance. >=20 > So, in our case the usage of a white list was suggested but this requires= that > someone creates such a white list and more important keeps it up-to-date.= This > party has to assure that the entires are actually legitimate PSAPs, i.e. = the > quality of the registration process is sort of important. >=20 > As the number of PSAPs (or in general devices that may issue the communic= ation > towards a VSP/ASP) grows the management of the white list becomes non-tri= vial. > Why do I say that? Because we can observe these problems in other areas a= s > well (e.g., Email security, Internet Identity Management, etc.) >=20 > Does my response make any sense? >=20 > Ciao > Hannes >=20 >>=20 >> Kind regards, >>=20 >> John-Luc >>=20 >> --- >> John-Luc Bakker >> Standards Manager >> Research In Motion >> BlackBerry: +1 (908) 463 7321 >> Office: +1 (972) 373-1761 >> Internal: (820) 63761 >> E-mail: jbakker@rim.com >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) >> Sent: Sunday, November 01, 2009 7:33 PM >> To: ecrit@ietf.org >> Subject: [Ecrit] draft-schulzrinne-ecrit-psap-callback-01 >>=20 >> Hi all,=20 >>=20 >> please take a look at the updated PSAP callback marking >> document. With this version Milan helped us to incorporate >> more text about the solution approaches. >>=20 >> When Marc and I had a discussion with Cullen and Robert about >> the milestone updates Cullen indicated that he would like to >> see an agreement from the group on the solution approach >> before the document can be added to the milestone list. >>=20 >> Furthermore, in the recent 3GPP-IETF conference call we >> learned that there is interest from the 3GPP in a solution >> about PSAP callback marking. Milan and Keith are keeping an >> eye on the requirements from the 3GPP side. >>=20 >> Milan has also written another document that could be >> interesting to consider in this specific context, namely >> draft-patel-dispatch-cpc-oli-parameter. It provides a solution >> for an environment that relies on a chain of trust. >>=20 >> That's certainly a starting point. But when considering an >> Internet context then this security model might not be >> appropriate and we may need an additional solutions. This is >> similar to the PAI vs. SIP Identity story. >>=20 >> It would be great to hear your thoughts about this issue and >> have a look at the updated document: >> http://tools.ietf.org/html/draft-schulzrinne-ecrit-psap-callback-01 >>=20 >> Ciao >> Hannes >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain >> confidential information, privileged material (including >> material protected by the solicitor-client or other applicable >> privileges), or constitute non-public information. Any use of >> this information by anyone other than the intended recipient >> is prohibited. If you have received this transmission in >> error, please immediately reply to the sender and delete this >> information from your system. Use, dissemination, >> distribution, or reproduction of this transmission by >> unintended recipients is not authorized and may be unlawful. >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >>=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From hannes.tschofenig@nsn.com Mon Dec 28 01:32: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 72D4D3A67E9 for ; Mon, 28 Dec 2009 01:32:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 zORbPmlX1IDt for ; Mon, 28 Dec 2009 01:32:51 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 47E4B3A67DB for ; Mon, 28 Dec 2009 01:32:51 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nBS9WSQP028635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 28 Dec 2009 10:32:28 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nBS9WSCY011138; Mon, 28 Dec 2009 10:32:28 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Dec 2009 10:32:28 +0100 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: Mon, 28 Dec 2009 11:36:15 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B450204C462@FIESEXC015.nsn-intra.net> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F0F2E5450@SISPE7MB1.commscope.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] AI for Data-Only Emergency Calls Thread-Index: AcpiicEdDmWcJqFNR++NjdoPuA2/RwAAQEQwCUTZkTA= References: <004201ca6289$c1eee160$4b725d85@nsnintra.net> <8B0A9FCBB9832F43971E38010638454F0F2E5450@SISPE7MB1.commscope.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Thomson, Martin" , "Hannes Tschofenig" , X-OriginalArrivalTime: 28 Dec 2009 09:32:28.0695 (UTC) FILETIME=[AC31EA70:01CA87A0] Subject: Re: [Ecrit] AI for Data-Only Emergency Calls 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, 28 Dec 2009 09:32:52 -0000 Hi Martin,=20 Thanks for your response.=20 There are a few options to solve the encountered problem: A) Wait for a future CAP specification that allows PIDF-LO functionality to be conveyed.=20 B) Investigate the usage of GeoRSS instead C) Define our own approach for encoding additional location fields (civic and geo) into the CAP message D) Include a pointer in the CAP message to point to a PIDF-LO carried outside.=20 E) Accept the fact that CAP is quite limited with regard to location F) Define our own format (instead of CAP or GeoRSS) Which option do you prefer? =20 Ciao Hannes >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of ext Thomson, Martin >Sent: 11 November, 2009 06:55 >To: Hannes Tschofenig; ecrit@ietf.org >Subject: Re: [Ecrit] AI for Data-Only Emergency Calls > >I suggested that we already have a mechanism for this and that=20 >there wasn't any need for change. Brian expressed the desire=20 >that the location used for routing the message be identical to=20 >that included in the actual alert. > >For that, I'd recommend that Brian talk to those who define=20 >CAP. I don't see there being much that we could do here,=20 >aside from noting how the CAP might be populated. For now,=20 >perhaps we need to accept that the CAP document will contain=20 >less information (or less detailed information) than is=20 >included for routing. > >--Martin > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf=20 >> Of Hannes Tschofenig >> Sent: Wednesday, 11 November 2009 1:45 PM >> To: ecrit@ietf.org >> Subject: [Ecrit] AI for Data-Only Emergency Calls >>=20 >> draft-rosen-ecrit-data-only-ea-00.txt describes a solution for=20 >> conveying a CAP message in a SIP MESSAGE. >>=20 >> There is one big open issue in the document: How do we carry=20 >location=20 >> information in or attached to the CAP message (since CAP does not=20 >> carry what we need with respect to location information). >>=20 >> So, we will need a discussion of what could be sensible to do. >>=20 >> Ciao >> Hannes >>=20 >> _______________________________________________ >> 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 >