From bernard_aboba@hotmail.com Fri Jul 1 15:02:33 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D8321F8737 for ; Fri, 1 Jul 2011 15:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.184 X-Spam-Level: X-Spam-Status: No, score=-100.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FaLBthgtLTXo for ; Fri, 1 Jul 2011 15:02:32 -0700 (PDT) Received: from blu0-omc3-s26.blu0.hotmail.com (blu0-omc3-s26.blu0.hotmail.com [65.55.116.101]) by ietfa.amsl.com (Postfix) with ESMTP id AE83C11E8188 for ; Fri, 1 Jul 2011 15:02:32 -0700 (PDT) Received: from BLU152-W12 ([65.55.116.72]) by blu0-omc3-s26.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Jul 2011 15:02:32 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_b647812f-05d3-44eb-9403-9c50126da8fd_" X-Originating-IP: [64.134.138.28] From: Bernard Aboba To: Date: Fri, 1 Jul 2011 15:02:31 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 01 Jul 2011 22:02:32.0124 (UTC) FILETIME=[9386B7C0:01CC383A] Subject: [Ecrit] EC mandate M/493 (fwd) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 22:02:33 -0000 --_b647812f-05d3-44eb-9403-9c50126da8fd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.112.be/ressource/static/files/m493_en.pdf >From page two: For the telephone service provided by traditional circuit switched networks= =2C mobile networks and IP-based networks the determination and conveyance of location information of emergency callers is not sufficiently standardized=2C hamper= ing progress at national level (i.e. use of proprietary technical solutions). European stan= dards do not provide complete architectural models and do not specify all protocol eleme= nts needed to support location enhanced emergency calling on existing infrastructures and= future networks. Hence=2C implementable solutions are not readily available but re= quired in Member States. The lack of commonly agreed specifications and standards in support of the = processing of caller location information in electronic communications networks for th= e purpose of the location enhanced emergency call service in Europe is a barrier for imp= lementing future proof solutions which fulfil the requirements of article 26 of the a= mended Directive 2002/22/EC. The objective of this Mandate is to stimulate further standardisation work in this field to support harmonized European solutions= also with regard to cost effective implementations. = --_b647812f-05d3-44eb-9403-9c50126da8fd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.112.be/ressource/static/files/m493_en.pdf

From page two:<= br>
For the telephone service provided by traditional circuit switched n= etworks=2C mobile
networks and IP-based networks the determination and c= onveyance of location
information of emergency callers is not sufficient= ly standardized=2C hampering progress at
national level (i.e. use of pro= prietary technical solutions). European standards do not
provide complet= e architectural models and do not specify all protocol elements needed tosupport location enhanced emergency calling on existing infrastructures a= nd future
networks. Hence=2C implementable solutions are not readily ava= ilable but required in
Member States.

The lack of commonly agreed= specifications and standards in support of the processing
of caller loc= ation information in electronic communications networks for the purpose of<= br>the location enhanced emergency call service in Europe is a barrier for = implementing
future proof solutions which fulfil the requirements of art= icle 26 of the amended
Directive 2002/22/EC. The objective of this Manda= te is to stimulate further
standardisation work in this field to support= harmonized European solutions also with
regard to cost effective implem= entations.


= --_b647812f-05d3-44eb-9403-9c50126da8fd_-- From hannes.tschofenig@gmx.net Tue Jul 5 13:16:01 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F113121F8915 for ; Tue, 5 Jul 2011 13:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqmtV2-F5D1c for ; Tue, 5 Jul 2011 13:16:01 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 2583521F890B for ; Tue, 5 Jul 2011 13:15:54 -0700 (PDT) Received: (qmail invoked by alias); 05 Jul 2011 20:15:52 -0000 Received: from letku214.adsl.netsonic.fi (EHLO [10.0.0.2]) [194.29.195.214] by mail.gmx.net (mp008) with SMTP; 05 Jul 2011 22:15:52 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/R6iIoNyfRSta3bEPay4+h+pb8k6SgSjPkgZnmra cYi7fO5NEam1yD Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <8B0A9FCBB9832F43971E38010638454F040B26CBA8@SISPE7MB1.commscope.com> Date: Tue, 5 Jul 2011 23:15:51 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5A5CA3CF-3853-472D-A0A1-1F4799EB6459@gmx.net> References: <8B0A9FCBB9832F43971E38010638454F040B26CBA8@SISPE7MB1.commscope.com> To: "Thomson, Martin" X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: ecrit Subject: Re: [Ecrit] Unauthenticated access review X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 20:16:02 -0000 Hi Martin,=20 thank you for your review comments.=20 On Jun 29, 2011, at 9:37 AM, Thomson, Martin wrote: > -02 is a considerable improvement over earlier iterations of this = work. >=20 Glad to hear that.=20 > I'm a little concerned about the suggested flow for NAA, specifically = the potential for abuse and what options are available for an operator. = The security considerations discusses this issue reasonably well, but it = takes a fairly weak position, preferring to shunt the problem than deal = with it outright. The No Access Authentication (NAA) case is indeed interesting and the = current definition covers the case where the emergency caller does not = possess valid credential for network access when those are needed for = getting access to the Internet.=20 In many cases today a host is able to use the Internet without having to = go through a network access authentication procedure. These free = hotspots are not really discussed in that section and wouldn't really = present a problem as such.=20 Having said that the security consideration section, as you state indeed = discusses the issue and proposed one possible solution approach. The = main issue I believe is that the LoST server can be provisioned to = return any ESRP URI back. Quite naturally that URI may not be the URI = of the PSAP but it may just get the call closer to the PSAP. Hence, if = the LoST server contains a ESRP URI that points to a VSP/ASP someone = then the ISP would configure the firewall setting in such a way that it = would essentially allow communication with that arbitrary VSP/ASP.=20 You phrase it in another way but I believe we are essentially saying the = same:=20 >=20 > =46rom the perspective of an operator, the potential for abuse is = increased when they have to permit signaling to an arbitrary ASP. = Permitting the path to anything other than NASP from NAA reduces an = operator's ability to constrain network access. In NASP, the ISP need = only provide access to a LIS, a LoST server and the emergency services = network. Normal call procedures are great, but it is a lot harder to = constrain access when you can't predict what ASP a device is going to = use. =20 >=20 So, there is nothing wrong with the currently presented solution but it = maybe we need to highlight a bit more that an ISP may want to make sure = that the entries in the LoST server actually point to ESRPs belonging to = the ESINet for that specific region if the described threat is a = concern.=20 Since we demand LoST server discovery using DHCP I don't see a problem = with the ISP ensuring that the presented information is indeed what is = desired (unless there is no way to configure the end host with a DHCP = server; a discussion we also had in the past ....).=20 =20 =20 > Of course, constraints might not be Boolean condition - an operator = might limit bandwidth on emergency-only access. But in a world where IP = over DNS is/was a reality, I'd want to be able to do better than that. >=20 >=20 > Does this work better for Section 4? >=20 >>>>=20 > ZBP includes all cases where a subscriber is known to an ASP, but = lacks the necessary authorization to access regular ASP services. = Example ZBP cases include empty prepaid accounts, barred accounts, = roaming and mobility restrictions, or any other conditions set by ASP = policy. > =09 > Local regulation might demand that emergency calls are always = authorized. An ASP can identify emergency sessions by identifying the = service URN [50xx] used in call setup. Emergency calls can then be = authorized accordingly. The ZBP case therefore only affects the ASP. >=20 > Permitting a call with limited authorization could present an = opportunity for abuse. The ASP MAY choose to validate session = initiation messages for valid destinations, see Section 7. >=20 > An ASP without a regulatory requirement to authorize emergency calls = can deny emergency call setup. Where an ASP does not authorize an = emergency call, the caller can fall back to NASP procedures. > <<< >=20 I am not sure I understand this comment. Is this a text proposal? Would = it replace the text in Section 4 or is it additional text?=20 >=20 > Section 5 >=20 > Section 5 duplicates a lot of the recommendations from phone-bcp. In = fact, it's difficult to identify how this draft differs from phone-bcp. = It should only be necessary to call out the points of divergence here = (which are few). For instance, the ESRP section could just say "follow = [phone-bcp]". Even the ISP/IAP section could say the same, with a = possible reference to the NAA section regarding constrained access. >=20 > What is missing from 5.1.2 is the SIP-based discovery of the ESRP - if = the End Host is sending signaling straight to the ESRP, it will probably = have to use RFC 3263. >=20 >=20 This is indeed a matter of taste. Referencing Phone BCP and to tell what = is different is one option. Another one is presented in this document - = we spell out what needs to be done for the presented case. I believe = that this is shorter and easier to understand.=20 I don't think that a reference to RFC 3263 is needed. The URI scheme of = the ESRP URI will determine what discovery mechanisms is to be used. We = aren't going to reference XMPP specs here either although one could = image that a LoST response may contain such a URI.=20 > Section 6 >=20 > In spite of considerable improvements over prior iterations, I still = think that Section 6 is too specific in parts and too vague in others. =20= >=20 > - (Section 6.1) The reasons for NOT doing something do not need to be = so exhaustively enumerated. In particular, I found the last two points = (EAP and NAI) a little baffling and non-sequitur. >=20 > - Section 6.2 makes some non-specific recommendations about securing = layer 2 communications, but doesn't really elucidate why. One good = reason for securing layer 2, with strong mutual authentication is that = most of the configuration (LIS, LoST, SIP) use a DHCP bootstrap, and = DHCP has no authentication framework. Again, for the reasons cited in = Section 6.1, anything more concrete is going to be hard to justify. >=20 > Oh, and... >=20 > Expand Acronyms Prior to using them. They are Not Always Intuitive. >=20 I will have to ask Dirk for feedback since he wrote this section. I only = want to say that this section is informative since the procedures for = link layer emergency service indications are, as the name indications, = link layer specific and therefore outside the IETF. We will have to = follow whatever the link layer procedures are, I believe. =20 Ciao Hannes >=20 > Cheers, > Martin > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From hannes.tschofenig@gmx.net Wed Jul 6 09:27:37 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE8721F880C for ; Wed, 6 Jul 2011 09:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id of3z3CkRBnhe for ; Wed, 6 Jul 2011 09:27:36 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 6582621F86C7 for ; Wed, 6 Jul 2011 09:27:36 -0700 (PDT) Received: (qmail invoked by alias); 06 Jul 2011 16:27:34 -0000 Received: from letku214.adsl.netsonic.fi (EHLO [10.0.0.6]) [194.29.195.214] by mail.gmx.net (mp058) with SMTP; 06 Jul 2011 18:27:34 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18uB3tfzXkux/THZtprMf5vmnCiGNChso9VrJ/T/h yg/FjX4GCCvesy Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <2D03AE89-9AA0-43D1-8B66-83061E7BA481@cisco.com> Date: Wed, 6 Jul 2011 19:27:33 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D03AE89-9AA0-43D1-8B66-83061E7BA481@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: ECRIT Subject: Re: [Ecrit] draft-ietf-ecrit-data-only-ea-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 16:27:37 -0000 Hi Cullen,=20 I missed this comment.=20 The CAP messages are sent to the PSAP.=20 ATOCA does the early warning stuff and there the messages are sent from = a PSAP (or some other entity) to a wider audience.=20 As such, having this work in ECRIT and the early warning work in ATOCA = is correct.=20 Ciao Hannes On Nov 8, 2010, at 12:52 AM, Cullen Jennings wrote: >=20 > Would these CAP messages be sent to a PSAP? >=20 > If not I sort of wonder how this is ECRIT and wonder if it would be = better to move this over to ATOCA.=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From hannes.tschofenig@gmx.net Wed Jul 6 09:27:49 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA9421F86C7 for ; Wed, 6 Jul 2011 09:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7L11JgMCBEz2 for ; Wed, 6 Jul 2011 09:27:48 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 54AC321F84DA for ; Wed, 6 Jul 2011 09:27:48 -0700 (PDT) Received: (qmail invoked by alias); 06 Jul 2011 16:27:46 -0000 Received: from letku214.adsl.netsonic.fi (EHLO [10.0.0.6]) [194.29.195.214] by mail.gmx.net (mp058) with SMTP; 06 Jul 2011 18:27:46 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18ThSk0SVITzc7Z7hMckjzSgRt+25uJecJqqM8wpD z22U6b6mwD5DkS Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Hannes Tschofenig In-Reply-To: Date: Wed, 6 Jul 2011 19:27:45 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0D3EEBED-6F66-45D7-96B2-0A4ECFA085D5@gmx.net> References: To: Marc Linsner X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-data-only-ea-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 16:27:49 -0000 Hi Marc,=20 thank you for your comments.=20 On Mar 30, 2011, at 6:04 PM, Marc Linsner wrote: > Brian, Hannes, >=20 > I find the scenario describing figure 2, bottom of page 5, in the = draft confusing (it could be just me), >=20 > "In case the LoST resolution is done at an emergency services routing = proxy rather than at the entity issuing the alert since it may not know = the address of the receiver." >=20 > =95 I believe it should read: "In this case=85=85" > =95 LoST resolves finding the target uri given location & = desired service. So I don't understand 'since it may not know the = address of the receiver.' Assuming the 'address of the receiver' is = synonymous with the location of the intended target of the alert, if the = sender doesn't know the intended target location for the alert, how = would the proxy? > Thanks, I fixed the text in this scenario. It was indeed confusing as others = have noticed as well.=20 The basic idea is that Phone BCP is re-used for this document and there = the routing of the emergency calls may happen at various stages and = these two examples are trying to illustrate that.=20 Ciao Hannes >=20 > -Marc- > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From hannes.tschofenig@gmx.net Wed Jul 6 09:34:47 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6662521F8882 for ; Wed, 6 Jul 2011 09:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwVKHUpkoo6B for ; Wed, 6 Jul 2011 09:34:46 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 2B10021F8880 for ; Wed, 6 Jul 2011 09:34:46 -0700 (PDT) Received: (qmail invoked by alias); 06 Jul 2011 16:28:04 -0000 Received: from letku214.adsl.netsonic.fi (EHLO [10.0.0.6]) [194.29.195.214] by mail.gmx.net (mp058) with SMTP; 06 Jul 2011 18:28:04 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/qPUczA5fq1YeB3pQSN4Nd5sQQ05bZQhQfjk7/0s dSWt45KXw+YXMv Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Hannes Tschofenig In-Reply-To: <8B0A9FCBB9832F43971E38010638454F04029590A6@SISPE7MB1.commscope.com> Date: Wed, 6 Jul 2011 19:28:03 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <89E5185C-B706-4C60-A65F-DB7B73595FBD@gmx.net> References: <8B0A9FCBB9832F43971E38010638454F04029590A6@SISPE7MB1.commscope.com> To: "Thomson, Martin" X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 16:34:47 -0000 Hi Martin,=20 thank you for your feedback.=20 On Apr 13, 2011, at 5:20 AM, Thomson, Martin wrote: > The document is OK, modulo a few comments and nits: >=20 Good to hear that.=20 > Comments: >=20 > Section 3, Figure 2: Why does the sensor not perform the route = selection itself? If it doesn't, then this is little different to the = first scenario, where proxy =3D=3D aggregator. In the ECRIT architecture emergency "call" routing may at various = places. These two scenarios are trying to demonstrate these different = deployment options.=20 > This text is strange: >=20 > [...] In case the LoST > resolution is done at an emergency services routing proxy rather = than > at the entity issuing the alert since it may not know the address of > the receiver. =20 This text reads indeed strange. It should read:=20 " An emergency services routing proxy (ESRP) may use LoST to determine = the next hop proxy to route the alert message to.=20 " >=20 > The reason given doesn't make any sense to me. A proxy might perform = routing because the sensor has limited capabilities, but that smells = more like the scenario in Figure 1 instead. Suggest reworking this = example to either provide better justification, or to have the sensor do = the LoST lookup. There are many reasons why the sensor may not do the LoST lookup itself = but I don't think we need to go into that topic in this document itself. = We just work with the existing ECRIT emergency services architecture.=20 =20 >=20 > Section 4.2: It's unclear what interoperability gain is achieved by = constraining the CAP contents in this manner. In particular, the scope = seems like a strange constraint. =20 >=20 CAP is a specification that defines the semantic of the elements in a = very relaxed fashion. For interoperability that's not particularly = useful. If we don't care about interoperability we could just say that = any human readable text is allowed, such as a Word document.=20 Since we don't want that we provide some additional guidance of what = makes sense for our use case.=20 You mention the scope element. The CAP specification says that it can = have the following values (and it is a required element): =93Public=94 - For general dissemination to unrestricted audiences =93Restricted=94 - For dissemination only to users with a known = operational requirement (see , below) =93Private=94 - For dissemination only to specified addresses (see =
, below) =46rom these values alerts issued by sensor's are not public. For = restricted there is an additional (optional) element that provides a = textual description of the restriction - not very helpful.=20 In case of private we may indicate an address of the recipient. We could = put the Service URN or the PSAP/ESRP URI there but it does not make = sense since we have that information already in another place. So, we = omit it altogether. Just passing information around for the fun of it = does not strike me as a good idea (also keeping in mind that XML-encoded = alerts are already big enough in size).=20 =20 > Section 6.1: This seems to advocate the use of XML digital signatures. = That would be a bad idea. Even CMS is better. JOES would be better = still. CAP comes with XML digitial signatures. What should I do?=20 I agree that JSON would be better and I would be happy to standardize a = JSON based encoding of CAP in the IETF, to be honest.=20 CMS is not lightweight either.=20 I have no good story here.=20 >=20 > Was "application/cap+xml" already taken? I don't think so. That would be better. I will switch to cap+xml.=20 >=20 > Nits: >=20 > The example has a few errors: > - It needs to be updated for the latest = sipcore-location-conveyance version > - The namespace prefix for the usage rules in the PIDF-LO are = incorrect > - The use of a mac: URI for identifying the device requires the = definition of the mac: URI scheme. >=20 OK. Took the example from the latest SIP Location Conveyance document.=20= > What is the right case for scope? I didn't check what the right = answer is, but the example and the MUST use different case - one of them = is probably wrong. >=20 "Private".=20 Fixed.=20 > Who is "phrank"? [citation required] >=20 I'll remove it=20 > Section 6.3: hanging sentence in the threat description: "In scenario = [...]" Good catch.=20 Ciao Hannes >=20 > --Martin >=20 > On 2011-03-31 at 01:49:46, Marc Linsner wrote: >> This message starts the Working Group Last Call for draft "Common=20 >> Alerting Protocol (CAP) based Data-Only Emergency Alerts using >>=20 >> the Session Initiation Protocol (SIP) >>=20 >> " (http://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-01). >>=20 >> This draft fulfills the WG milestone: >>=20 >> Apr 2011 Submit 'Common Alerting Protocol (CAP) based Data-Only=20 >> Emergency Alerts using the Session Initiation Protocol (SIP)' >>=20 >> Please submit comments to the list by COB on Friday April 15, 2011. >>=20 >>=20 >> Thanks, >>=20 >>=20 >> -Marc Linsner- >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From hannes.tschofenig@gmx.net Wed Jul 6 09:34:54 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E799021F8880 for ; Wed, 6 Jul 2011 09:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywrMmqAwSLB8 for ; Wed, 6 Jul 2011 09:34:54 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 0ECF521F8887 for ; Wed, 6 Jul 2011 09:34:53 -0700 (PDT) Received: (qmail invoked by alias); 06 Jul 2011 16:28:11 -0000 Received: from letku214.adsl.netsonic.fi (EHLO [10.0.0.6]) [194.29.195.214] by mail.gmx.net (mp058) with SMTP; 06 Jul 2011 18:28:11 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19aCQF69r9aWYCJNAlBOj8mle4wd98+MkRJp0fBgq /Hir/1DZy/Ej+B Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <5A55A45AE77F5941B18E5457ECAC818801210235F1BA@SISPE7MB1.commscope.com> Date: Wed, 6 Jul 2011 19:28:10 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8B0A9FCBB9832F43971E38010638454F04029590A6@SISPE7MB1.commscope.com> <5A55A45AE77F5941B18E5457ECAC818801210235F1BA@SISPE7MB1.commscope.com> To: "Winterbottom, James" X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 16:34:55 -0000 Hi James,=20 On Apr 13, 2011, at 6:48 AM, Winterbottom, James wrote: > On the mac URI scheme, we originally had this in the HELD identity = extensions but it was suggested in no uncertain terms that this had = buckley's chance of getting through. This led us to use an explicit XML = entity, though I seem to recall somebody suggesting that we may have = been able to do something with UUIDs. Hmmm.=20 When I copied the example from the latest version of SIP location = conveyance then I see that it says the same as in the ecrit-data-only-ea = draft.=20 I believe we need to consistently use something here.=20 So, what would you suggest? The HELD identity extension cannot be used = here out of the box since this is a completely different specification. = In RFC 5491 we had also used the = mac:8asd7d7d70cf notation.... Ciao Hannes From hannes.tschofenig@gmx.net Wed Jul 6 09:45:39 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD7021F88C0 for ; Wed, 6 Jul 2011 09:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiuvzgkSlHbP for ; Wed, 6 Jul 2011 09:45:38 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 543BD21F88BF for ; Wed, 6 Jul 2011 09:45:38 -0700 (PDT) Received: (qmail invoked by alias); 06 Jul 2011 16:45:36 -0000 Received: from letku214.adsl.netsonic.fi (EHLO [10.0.0.6]) [194.29.195.214] by mail.gmx.net (mp043) with SMTP; 06 Jul 2011 18:45:36 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+eCuhhzw6e2hGo3jaMVPAib9QrgWhCHVubgmWjI4 /IbXKeDVNvKkk/ Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Wed, 6 Jul 2011 19:45:35 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Shida Schubert X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 16:45:39 -0000 Hi Shida,=20 thank you for your review comments.=20 On Apr 20, 2011, at 5:27 AM, Shida Schubert wrote: >=20 > I reviewed the document and followings are some comments/questions.=20 >=20 > In general, I am having a hard time understanding the intent of the=20= > draft. Is it defining a CAP document composition rule (4.2) for = delivering=20 > the CAP message from citizen to authority only? OR is it defining a = SIP=20 > usage to transport CAP message as well? If it's latter I think more = should=20 > be said about how SIP entities should behave. I understand it is an=20 > experimental document but I think we need to clarify the scope of the=20= > document somewhat.=20 Based on the received feedback the introduction section was enhanced.=20 I hope the purpose is now clearer.=20 >=20 > 1. For scenario 1, I really don't think in reality a sensor will be=20= > implementing a SIP stack simply to support the transport of=20 > CAP message, it just seems like an overkill. I understand how=20 > aggregator to PSAP should be SIP to re-use what is defined=20 > in Phone-BCP and pre-exising infrastructure. May be text can=20 > be added that some other means may be used to deliver a CAP=20 > message from CAP to aggregator. =20 Actually, sensors implement IP protocols, and various IETF protocols = (including SIP, XMPP, and HTTP).=20 No kidding.=20 >=20 > 2. I am assuming that any SIP device can use MESSAGE to=20 > send CAP to PSAP. If so, some device will be able to handle=20 > call-back and some won't. Do we need to distinguish devices=20 > that will be issuing the MESSAGE to see whether call-back=20 > can be established etc? (I guess PSAP can look at allow header=20= > to see if the device can accept INVITE etc.) Interesting comment and aligns nicely with the remark Bernard has made.=20= I will post a separate mail about this topic.=20 > =20 > 3. For both cases, should there be any recommendation on how=20 > sensor should behave in case 200 OK is not received or error=20 > is received from downstream? Again related to the scoping of=20 > the document, this may not be necessary if the main intent is=20 > to recommend CAP document composition rule.=20 >=20 This aspect relates to the previous question. See also separate mail.=20 > 4. If non SIP device is used what should be set in "sender" of CAP?=20= > What if the CAP message is sent by a sensor which doesn't support=20= > SIP and it is the aggregator that acts as the SIP intermediary = and=20 > SIP endpoint? >=20 You are saying that you don't like it that the text in the document = equates the sender identity of the SIP message with the sender identity = in the CAP message.=20 Bernard seems to argue in the same direction and maybe we should not = make this restriction and say that if the author and the originator are = the same then we just copy the SIP sending identity into the CAP sender = element.=20 OK?=20 > 5. Use of P-Asserted-Identity doesn't provide any integrity so I = would=20 > take it out of section 6.3. >=20 Input taken. Text will change based on Bernard's suggestion to = restructure the security consideration section.=20 > 6. Why is RFC3265/RFC3903 a normative reference? I think they=20 > should be in an informative reference as there is no normative = text=20 > surrounding their uses.=20 Fixed. A bug.=20 >=20 > 7. Shouldn't RFC3261(SIP)/RFC3428(MESSAGE)/location-conveyance/ > RFC4119(PIDF-LO) be in a normative reference? >=20 Yes; The are indirectly imported through the PhoneBCP document. I moved = the Phone BCP I-D to the normative reference section.=20 >=20 > **Some nits** >=20 > Section 6:=20 >=20 > OLD ".. this document and the discussion in.." > =20 > NEW ".. this document and are discussed in.." >=20 OK. Fixed.=20 > Section 6.2 >=20 > OLD "..alerts and reply them at a later time.." >=20 > NEW "..alerts and replay them at a later time.." >=20 OK. Fixed.=20 Ciao Hannes >=20 > Regards > Shida >=20 > On Mar 30, 2011, at 11:49 PM, Marc Linsner wrote: >=20 >> This message starts the Working Group Last Call for draft "Common = Alerting Protocol (CAP) based Data-Only Emergency Alerts using the = Session Initiation Protocol (SIP)" = (http://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-01). >>=20 >> This draft fulfills the WG milestone: >>=20 >> Apr 2011 Submit 'Common Alerting Protocol (CAP) based Data-Only = Emergency Alerts using the Session Initiation Protocol (SIP)' >>=20 >> Please submit comments to the list by COB on Friday April 15, 2011. >>=20 >> Thanks, >>=20 >> -Marc Linsner- >> _______________________________________________ >> 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@gmx.net Wed Jul 6 09:55:09 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1F521F87C2 for ; Wed, 6 Jul 2011 09:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOX27qnDmlGk for ; Wed, 6 Jul 2011 09:55:07 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 4694B21F8620 for ; Wed, 6 Jul 2011 09:55:01 -0700 (PDT) Received: (qmail invoked by alias); 06 Jul 2011 16:28:19 -0000 Received: from letku214.adsl.netsonic.fi (EHLO [10.0.0.6]) [194.29.195.214] by mail.gmx.net (mp058) with SMTP; 06 Jul 2011 18:28:19 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19IXSVdnqVIXebrFfagrpiIX0w7diFXYDQ866oq5v NBRWo0wTQmBEXi Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Wed, 6 Jul 2011 19:28:18 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2C95DA9E-658B-4CEA-ACFB-4283CC477E0C@gmx.net> References: , To: Bernard Aboba X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 16:55:09 -0000 Hi Bernard,=20 thank you for your detailed review and text suggestions.=20 On Apr 21, 2011, at 12:55 AM, Bernard Aboba wrote: > [BA] Overall, I echo Shida's comments about potential additional > usage scenarios and have a few additional comments about the > Security Considerations section.=20 >=20 > Specific comments below: >=20 > Abstract >=20 > The Common Alerting Protocol (CAP) is a document format for > exchanging emergency alerts and public warnings. CAP is mainly = used > for conveying alerts and warnings between authorities and from > authorities to citizen/individuals. This document describes how > data-only emergency alerts allow devices to issue alerts using the > CAP document format. >=20 > [BA] It seems to me that the use of the term "Data-Only" may not be > appropriate to describe all the potential usage scenarios. For > example, might it also not be possible to include CAP within an = INVITE? > Suggestion is that the draft be renamed "CAP Emergency Alerts Using = SIP", > and that the Abstract be changed as follows: >=20 > The Common Alerting Protocol (CAP) is a document format for > exchanging emergency alerts and public warnings. CAP is mainly = used > for conveying alerts and warnings between authorities and from > authorities to citizen/individuals. This document describes how > the CAP document format can be used to allow devices to issue > emergency alerts. >=20 > ---------------------------- >=20 I am fine with the suggested text.=20 > Data-only emergency alerts are similar to regular emergency calls = in > the sense that they require emergency call routing functionality = and > may even have the same location requirements. On the other hand, = the > initial communication interaction will not lead to the = establishment > of a voice or video channel. >=20 > [BA] There are a number of potential uses for CAP, some of which could = not > be characterized as "Data-only". For example, CAP could be included = in an > INVITE which also included an SDP offer. Also an INVITE might be sent > without CAP and then when a response was received indicating that = MESSAGE > was allowed then a CAP alert could subsequently be sent. So I = wouldn't > necessarily emphasize the "Data-only" aspect. Suggested change: >=20 > Eergency alerts containing data are similar to regular emergency = calls in > the sense that they require emergency call routing functionality = and > may even have the same location requirements. On the other hand, = the > communication interaction may occur without establishment > of a voice or video channel.=20 >=20 > ---------------------------- >=20 Good for me as well.=20 > Based on the deployment experience with non-IP based systems we > distinguish between two types of environments, namely (1) data-only > emergency alerts that are targeted directly to a recipient > responsible for evaluating the alerts and for taking the necessary > steps, including triggering an emergency call towards a Public = Safety > Answering Point (PSAP) and (2) alerts that are targeted to a = Service > URN as used for regular IP-based emergency calls where the = recipient > is not known to the originator. We describe these two cases in = more > detail in Section 3. >=20 >=20 > [BA] The term "emergency call" as opposed to "emergency alert" = suggests=20 > that the aggregator could potentially convey the CAP message along = with=20 > establishing non-data channels. My suggestion is to rewrite as = follows: >=20 > Based on the deployment experience with non-IP based systems, two > major deployment scenarios are envisaged: >=20 > 1) Emergency alerts containing only data are targeted to a=20 > recipient responsible for evaluating the next steps, which > could include: >=20 > a. Sending an alert containing only data toward a Public > Safety Answering Point (PSAP); > b. Establishing an emergency call with a PSAP that could > include audio/video as well as data >=20 > 2) Emergency alerts targeted to a Service URN used for IP-based=20 > emergency calls where the recipient is not known to=20 > the originator. In this scenario, the alert may contain > only data (e.g. MESSAGE) or could be included along with > establishment of an audio/video channel (e.g. INVITE) >=20 > We describe these two cases in more detail in Section 3. >=20 Thanks for the improved text proposal.=20 > ---------------------------- >=20 > Section 3 >=20 > There is a basic issue in scenario described in Figure 2, which > is handling of failure conditions. >=20 > If we assume that the PSAPs do not deploy new capabilities uniformly, > then the sender may not know beforehand what capabilities the PSAP=20 > can support. For example, a given PSAP may or may not support = MESSAGE, > may or may not support CAP or PIDF-LO, etc.=20 >=20 > If at all possible, you want to avoid multiple error-terminated = conversations > between the sender and receiver, consuming precious time during an = emergency.=20 >=20 > This is one argument for "silent call" approaches which utilize a > "known good" mechanism for initiating an emergency call (e.g. an = INVITE), > then follow up with additional messages once the capabilities of > the responder are known (e.g. from an Allow: header).=20 >=20 This is an interesting issue that I will address this issue in a = separate mail.=20 > ---------------------------- >=20 > Section 4.1 >=20 > Alternatively, the SIP PUBLISH mechanism or other SIP messages > could be used. However, the usage of SIP MESSAGE is a simple > enough approach from an implementation point of view. >=20 > [BA] I'm not thrilled with using PUBLISH, so I'd remove that but it > does occur to me that INVITE would make sense.=20 >=20 The question is also whether we need to restrict the way a CAP payload = is sent to a recipient.=20 One could argue that it does not really matter whether it is an INVITE, = a MESSAGE, or a PUBLISH.=20 Which one is best depends on a specific environment.=20 But you seem to be arguing that we should rather stick with the INVITE = instead of using MESSAGE.=20 This would at least allow us to get the message understood by every SIP = device.=20 > ---------------------------- >=20 > Section 5 >=20 > Via: SIP/2.0/TCP sensor1.domain.com;branch=3Dz9hG4bK776sgdkse >=20 > [BA] Use of TCP transport makes sense, particularly in scenarios where = both CAP > and a PIDF-LO might be included. You might consider saying something = about this > since TCP transport for MESSAGE is not that common today.=20 >=20 This is just an example. Using TCP indeed makes sense for XML-based = payloads.=20 I don't think we want to mandate that TCP is mandatory-to-use.=20 > ---------------------------- >=20 > Section 6.1 >=20 > Does it really make sense to sign the CAP alert when the sender might = be a sensor > that may not even by IP-connected, and the signer might be an = aggregator with a > different identity from the or the identity in the From: = field of the > SIP message? If you are going to recommend that, you really need to = describe > what if anything the receiver can do to validate the signature.=20 >=20 I assume that the device that issues the alert is actually an IP-based = device.=20 For me the story begins with the first IP device.=20 > ---------------------------- >=20 > Section 6.2 >=20 > Additionally, it is RECOMMENDED to make use of SIP security > mechanisms, such as SIP Identity [RFC4474], to tie the CAP = message > to the SIP message. >=20 > [BA] Since the sender of the CAP message and the SIP message can be > different, RFC 4474 only can guarantee that the message isn't = modified; > it doesn't really "tie them together". For example, an attacker could > snoop on a signed CAP message, insert it in a SIP MESSAGE and then > use RFC 4474, and the sender wouldn't be able to verify that they are > unrelated though the sender would be accountable for the mis-behavior.=20= >=20 With SIP Identity the identity header is either added by the end point = (unlikely) or by the outbound proxy.=20 If it is added by the outbound proxy then there has to be TLS between = the end point and the outbound proxy.=20 This would provide proper protection of the message exchange and would = fulfill our purpose here. Wouldn't you say so?=20 > ---------------------------- >=20 > Section 6.3 >=20 > For some types of data-only emergency calls author/originator = and > the receiver/recipient have a relationship with each other and > hence it is possible (using cryptographic techniques) to verify > whether a message was indeed issued by an authorized entity. > Figure 1 is such an environment. Standard SIP security = mechanisms > can be re-used for this purpose. For example, identity based > access control is a viable approach utilizing the asserted > identity of the alert originator using P-Asserted-Identity > [RFC3325] or SIP Identity [RFC4474]. >=20 > [BA] What is the distinction between "forgery" and "Injecting false = alerts"?=20 The former is a man-in-the-middle attack that requires the adversary to = be on-path. With the latter one the adversary does not need to be along = the communication path, i.e. does not need to have seen any earlier = message exchanges.=20 > Verifying the identity of the sender of the SIP message may tell you = who > is accountable for sending the emergency alert, but that isn't the = same > as verifying the authenticity of the alert itself. =20 True. There is the SIP identity of the sender, the field in the CAP = message (sender field), and then there is cryptographic material in case = of a signature that will have some identity information associated with = it.=20 Currently, the draft says that we should set the sender field of the CAP = message to the value of the sender of the SIP message. Useful to set to = two equal? >=20 > I might suggest that the threat model focus on the following instead: >=20 > 1. Prevention of modification of data in transit (e.g. sending MESSAGE = over TLS) > 2. Verification of the sender identity (Section 6.3) > 3. Signing of alerts (Section 6.1) >=20 I am OK with not focusing on security threats as the document currently = does, but instead focus on the solutions.=20 Using the terminology from the ATOCA requirements document maybe it is = better to talk about=20 1) Verification of the alert originator (this is the SIP stuff)=20 2) Verification of the alert author (this is the alert stuff) 3) Integrity of alerts in transit (the TLS) OK for you?=20 Ciao Hannes > From: shida@ntt-at.com > Date: Wed, 20 Apr 2011 11:27:33 +0900 > To: ecrit@ietf.org > Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01 >=20 >=20 > I reviewed the document and followings are some comments/questions.=20 >=20 > In general, I am having a hard time understanding the intent of the=20= > draft. Is it defining a CAP document composition rule (4.2) for = delivering=20 > the CAP message from citizen to authority only? OR is it defining a = SIP=20 > usage to transport CAP message as well? If it's latter I think more = should=20 > be said about how SIP entities should behave. I understand it is an=20 > experimental document but I think we need to clarify the scope of the=20= > document somewhat.=20 >=20 > 1. For scenario 1, I really don't think in reality a sensor will be=20= > implementing a SIP stack simply to support the transport of=20 > CAP message, it just seems like an overkill. I understand how=20 > aggregator to PSAP should be SIP to re-use what is defined=20 > in Phone-BCP and pre-exising infrastructure. May be text can=20 > be added that some other means may be used to deliver a CAP=20 > message from CAP to aggregator. =20 >=20 > 2. I am assuming that any SIP device can use MESSAGE to=20 > send CAP to PSAP. If so, some device will be able to handle=20 > call-back and some won't. Do we need to distinguish devices=20 > that will be issuing the MESSAGE to see whether call-back=20 > can be established etc? (I guess PSAP can look at allow header=20= > to see if the device can accept INVITE etc.) > =20 > 3. For both cases, should there be any recommendation on how=20 > sensor should behave in case 200 OK is not received or error=20 > is received from downstream? Again related to the scoping of=20 > the document, this may not be necessary if the main intent is=20 > to recommend CAP document composition rule.=20 >=20 > 4. If non SIP device is used what should be set in "sender" of CAP?=20= > What if the CAP message is sent by a sensor which doesn't support=20= > SIP and it is the aggregator that acts as the SIP intermediary = and=20 > SIP endpoint? >=20 > 5. Use of P-Asserted-Identity doesn't provide any integrity so I = would=20 > take it out of section 6.3. >=20 > 6. Why is RFC3265/RFC3903 a normative reference? I think they=20 > should be in an informative reference as there is no normative = text=20 > surrounding their uses.=20 >=20 > 7. Shouldn't RFC3261(SIP)/RFC3428(MESSAGE)/location-conveyance/ > RFC4119(PIDF-LO) be in a normative reference? >=20 >=20 > **Some nits** >=20 > Section 6:=20 >=20 > OLD ".. this document and the discussion in.." > =20 > NEW ".. this document and are discussed in.." >=20 > Section 6.2 >=20 > OLD "..alerts and reply them at a later time.." >=20 > NEW "..alerts and replay them at a later time.." >=20 >=20 > Regards > Shida >=20 > On Mar 30, 2011, at 11:49 PM, Marc Linsner wrote: >=20 > This message starts the Working Group Last Call for draft "Common = Alerting Protocol (CAP) based Data-Only Emergency Alerts using the = Session Initiation Protocol (SIP)" = (http://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-01). >=20 > This draft fulfills the WG milestone: >=20 > Apr 2011 Submit 'Common Alerting Protocol (CAP) based Data-Only = Emergency Alerts using the Session Initiation Protocol (SIP)' >=20 > Please submit comments to the list by COB on Friday April 15, 2011. >=20 > Thanks, >=20 > -Marc Linsner- > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 >=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 From fluffy@cisco.com Wed Jul 6 10:14:57 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C998F21F8889 for ; Wed, 6 Jul 2011 10:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.518 X-Spam-Level: X-Spam-Status: No, score=-110.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sM-gaioVFx0G for ; Wed, 6 Jul 2011 10:14:57 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC5721F8893 for ; Wed, 6 Jul 2011 10:14:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=842; q=dns/txt; s=iport; t=1309972497; x=1311182097; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=+6yXlWOdsUcB9WRL+00Ti5u1dPctpeUhFLACrh+vzrc=; b=KCm9IK4TUpbKPfdo7bpTieOkrKJ3aPwv3g1xQ5dZsApbyxjy6QiXU1PW Uf3AE3yoAIJxxBHESnJqLCWJ0KAV0nNKuPqJuXxACUab5EpAHLsugNfce d+oC0Je5gSDRo+IiCsFj8brtJeoH+MaH45ZM/oHT1FxlAeAwjcrAm5wJ7 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAK+XFE6rRDoH/2dsb2JhbABTqAV3iHqlQ54ShjcEh0aKe4R6i2I X-IronPort-AV: E=Sophos;i="4.65,488,1304294400"; d="scan'208";a="362497129" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-5.cisco.com with ESMTP; 06 Jul 2011 17:14:55 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p66HEsUa016559; Wed, 6 Jul 2011 17:14:54 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Wed, 6 Jul 2011 11:14:56 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3D575116-5046-4123-90C0-B6CDD6C7B6DF@cisco.com> References: <2D03AE89-9AA0-43D1-8B66-83061E7BA481@cisco.com> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1084) Cc: ECRIT Subject: Re: [Ecrit] draft-ietf-ecrit-data-only-ea-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 17:14:58 -0000 sounds good to me - thanks On Jul 6, 2011, at 10:27 AM, Hannes Tschofenig wrote: > Hi Cullen, >=20 > I missed this comment. >=20 > The CAP messages are sent to the PSAP. > ATOCA does the early warning stuff and there the messages are sent = from a PSAP (or some other entity) to a wider audience. >=20 > As such, having this work in ECRIT and the early warning work in ATOCA = is correct. >=20 > Ciao > Hannes >=20 >=20 > On Nov 8, 2010, at 12:52 AM, Cullen Jennings wrote: >=20 > > > > Would these CAP messages be sent to a PSAP? > > > > If not I sort of wonder how this is ECRIT and wonder if it would be = better to move this over to ATOCA. > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit >=20 >=20 From jmpolk@cisco.com Wed Jul 6 14:42:50 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991FD21F8B93 for ; Wed, 6 Jul 2011 14:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ee3x5RrGE3Ba for ; Wed, 6 Jul 2011 14:42:50 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1119C21F8B7F for ; Wed, 6 Jul 2011 14:42:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1242; q=dns/txt; s=iport; t=1309988570; x=1311198170; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=Q1C1LtDYly7DDF9DYR1PvqNy4VNB3x0QGz9by9coUG4=; b=Ig2tfsZv2OEU4W+9PD8M5l+8fr6SdylvX2ahkNBcln+/wLxtNzZBkMFV OFtA1v0261zYAWrq1gFDPdB18yZgyYf8e+cs0jvBKIYKudvJhco28Xha1 SRR2yPumhUQxgQL5WAHcSegFakiBLmcoiwlfIOqHUkpt1LTarDfFJJnNZ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFfWFE6tJV2b/2dsb2JhbABGDagLd616ngyDIoMVBIdGm1Y X-IronPort-AV: E=Sophos;i="4.65,489,1304294400"; d="scan'208";a="467932" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 06 Jul 2011 21:42:41 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p66Lgdpu010951; Wed, 6 Jul 2011 21:42:39 GMT Message-Id: <201107062142.p66Lgdpu010951@rcdn-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 06 Jul 2011 16:42:37 -0500 To: Hannes Tschofenig , "Winterbottom, James" From: "James M. Polk" In-Reply-To: References: <8B0A9FCBB9832F43971E38010638454F04029590A6@SISPE7MB1.commscope.com> <5A55A45AE77F5941B18E5457ECAC818801210235F1BA@SISPE7MB1.commscope.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 21:42:50 -0000 At 11:28 AM 7/6/2011, Hannes Tschofenig wrote: >Hi James, > >On Apr 13, 2011, at 6:48 AM, Winterbottom, James wrote: > > > On the mac URI scheme, we originally had this in the HELD > identity extensions but it was suggested in no uncertain terms that > this had buckley's chance of getting through. This led us to use an > explicit XML entity, though I seem to recall somebody suggesting > that we may have been able to do something with UUIDs. > >Hmmm. > >When I copied the example from the latest version of SIP location >conveyance then I see that it says the same as in the >ecrit-data-only-ea draft. >I believe we need to consistently use something here. > >So, what would you suggest? The HELD identity extension cannot be >used here out of the box since this is a completely different >specification. In RFC 5491 we had also used the >mac:8asd7d7d70cf notation.... I'm not tracking what the issue is wrt SIP Location Conveyance. I guess I'm not "getting it", so could someone explain it differently to me? James >Ciao >Hannes > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From hannes.tschofenig@gmx.net Thu Jul 7 01:27:42 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5324921F8714 for ; Thu, 7 Jul 2011 01:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWyahCXTzRY2 for ; Thu, 7 Jul 2011 01:27:41 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 33E5B21F870A for ; Thu, 7 Jul 2011 01:27:40 -0700 (PDT) Received: (qmail invoked by alias); 07 Jul 2011 08:27:39 -0000 Received: from letku214.adsl.netsonic.fi (EHLO [10.0.0.6]) [194.29.195.214] by mail.gmx.net (mp016) with SMTP; 07 Jul 2011 10:27:39 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19+lEYcVj5+zImB5GYgWMqvp9vWQM5ZxOF4RJQSGv NXD2Yn5zr7agwJ From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Jul 2011 11:27:37 +0300 Message-Id: <6D0B17CC-6F5C-4C69-9248-C9E94493E8E2@gmx.net> To: James Polk Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: ecrit@ietf.org Subject: [Ecrit] Device Identity in PIDF-LO (from draft-ietf-ecrit-data-only-ea-01 and SIP Location Conveyance) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 08:27:42 -0000 Hi James,=20 the example in draft-ietf-ecrit-data-only-ea-01 uses the device id in = the PIDF-LO: 32.86726 -97.16054 yes 2010-07-30T20:00:00Z 802.11 *** mac:1234567890ab *** 2010-07-28T20:57:29Z The example was copied from SIP Location Conveyance and modified = slightly.=20 Now, Martin indicated that this usage of the deviceID requires the = definition of the mac: URI scheme. James noted that this mac: URI scheme = approach dated back to the time when we worked on the HELD identity = extension but in the end a different approach was chosen (namely using = separate XML elements).=20 So, for me the question is now what to put in there. I could just omit = this example altogether but how do we put a MAC address as a device id = into a PIDF-LO then.=20 Ciao Hannes From hannes.tschofenig@gmx.net Thu Jul 7 03:43:01 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF9721F87C3 for ; Thu, 7 Jul 2011 03:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgFbn11kQwr9 for ; Thu, 7 Jul 2011 03:42:59 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 4B2B721F8599 for ; Thu, 7 Jul 2011 03:42:59 -0700 (PDT) Received: (qmail invoked by alias); 07 Jul 2011 10:42:56 -0000 Received: from letku214.adsl.netsonic.fi (EHLO [10.0.0.6]) [194.29.195.214] by mail.gmx.net (mp055) with SMTP; 07 Jul 2011 12:42:56 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18+P51nT5U+33OgD9iwDhdeLE9zgfSNXbi+wY0ux2 H6qO+jpJ3n9py6 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <2C95DA9E-658B-4CEA-ACFB-4283CC477E0C@gmx.net> Date: Thu, 7 Jul 2011 13:42:54 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <83BD5C56-EC06-40A9-9E60-2A1D5B39781A@gmx.net> References: , <2C95DA9E-658B-4CEA-ACFB-4283CC477E0C@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 10:43:01 -0000 Regarding the security consideration section here is a proposed update:=20= = http://www.tschofenig.priv.at/svn/draft-rosen-ecrit-data-only-ea/draft-iet= f-ecrit-data-only-ea-02.txt Ciao Hannes On Jul 6, 2011, at 7:28 PM, Hannes Tschofenig wrote: > Hi Bernard,=20 >=20 > thank you for your detailed review and text suggestions.=20 >=20 > On Apr 21, 2011, at 12:55 AM, Bernard Aboba wrote: >=20 >> [BA] Overall, I echo Shida's comments about potential additional >> usage scenarios and have a few additional comments about the >> Security Considerations section.=20 >>=20 >> Specific comments below: >>=20 >> Abstract >>=20 >> The Common Alerting Protocol (CAP) is a document format for >> exchanging emergency alerts and public warnings. CAP is mainly = used >> for conveying alerts and warnings between authorities and from >> authorities to citizen/individuals. This document describes how >> data-only emergency alerts allow devices to issue alerts using the >> CAP document format. >>=20 >> [BA] It seems to me that the use of the term "Data-Only" may not be >> appropriate to describe all the potential usage scenarios. For >> example, might it also not be possible to include CAP within an = INVITE? >> Suggestion is that the draft be renamed "CAP Emergency Alerts Using = SIP", >> and that the Abstract be changed as follows: >>=20 >> The Common Alerting Protocol (CAP) is a document format for >> exchanging emergency alerts and public warnings. CAP is mainly = used >> for conveying alerts and warnings between authorities and from >> authorities to citizen/individuals. This document describes how >> the CAP document format can be used to allow devices to issue >> emergency alerts. >>=20 >> ---------------------------- >>=20 > I am fine with the suggested text.=20 >=20 >> Data-only emergency alerts are similar to regular emergency calls = in >> the sense that they require emergency call routing functionality = and >> may even have the same location requirements. On the other hand, = the >> initial communication interaction will not lead to the = establishment >> of a voice or video channel. >>=20 >> [BA] There are a number of potential uses for CAP, some of which = could not >> be characterized as "Data-only". For example, CAP could be included = in an >> INVITE which also included an SDP offer. Also an INVITE might be = sent >> without CAP and then when a response was received indicating that = MESSAGE >> was allowed then a CAP alert could subsequently be sent. So I = wouldn't >> necessarily emphasize the "Data-only" aspect. Suggested change: >>=20 >> Eergency alerts containing data are similar to regular emergency = calls in >> the sense that they require emergency call routing functionality = and >> may even have the same location requirements. On the other hand, = the >> communication interaction may occur without establishment >> of a voice or video channel.=20 >>=20 >> ---------------------------- >>=20 >=20 > Good for me as well.=20 >=20 >> Based on the deployment experience with non-IP based systems we >> distinguish between two types of environments, namely (1) data-only >> emergency alerts that are targeted directly to a recipient >> responsible for evaluating the alerts and for taking the necessary >> steps, including triggering an emergency call towards a Public = Safety >> Answering Point (PSAP) and (2) alerts that are targeted to a = Service >> URN as used for regular IP-based emergency calls where the = recipient >> is not known to the originator. We describe these two cases in = more >> detail in Section 3. >>=20 >>=20 >> [BA] The term "emergency call" as opposed to "emergency alert" = suggests=20 >> that the aggregator could potentially convey the CAP message along = with=20 >> establishing non-data channels. My suggestion is to rewrite as = follows: >>=20 >> Based on the deployment experience with non-IP based systems, two >> major deployment scenarios are envisaged: >>=20 >> 1) Emergency alerts containing only data are targeted to a=20 >> recipient responsible for evaluating the next steps, which >> could include: >>=20 >> a. Sending an alert containing only data toward a Public >> Safety Answering Point (PSAP); >> b. Establishing an emergency call with a PSAP that could >> include audio/video as well as data >>=20 >> 2) Emergency alerts targeted to a Service URN used for IP-based=20 >> emergency calls where the recipient is not known to=20 >> the originator. In this scenario, the alert may contain >> only data (e.g. MESSAGE) or could be included along with >> establishment of an audio/video channel (e.g. INVITE) >>=20 >> We describe these two cases in more detail in Section 3. >>=20 > Thanks for the improved text proposal.=20 >=20 >> ---------------------------- >>=20 >> Section 3 >>=20 >> There is a basic issue in scenario described in Figure 2, which >> is handling of failure conditions. >>=20 >> If we assume that the PSAPs do not deploy new capabilities uniformly, >> then the sender may not know beforehand what capabilities the PSAP=20 >> can support. For example, a given PSAP may or may not support = MESSAGE, >> may or may not support CAP or PIDF-LO, etc.=20 >>=20 >> If at all possible, you want to avoid multiple error-terminated = conversations >> between the sender and receiver, consuming precious time during an = emergency.=20 >>=20 >> This is one argument for "silent call" approaches which utilize a >> "known good" mechanism for initiating an emergency call (e.g. an = INVITE), >> then follow up with additional messages once the capabilities of >> the responder are known (e.g. from an Allow: header).=20 >>=20 >=20 > This is an interesting issue that I will address this issue in a = separate mail.=20 >=20 >> ---------------------------- >>=20 >> Section 4.1 >>=20 >> Alternatively, the SIP PUBLISH mechanism or other SIP messages >> could be used. However, the usage of SIP MESSAGE is a simple >> enough approach from an implementation point of view. >>=20 >> [BA] I'm not thrilled with using PUBLISH, so I'd remove that but it >> does occur to me that INVITE would make sense.=20 >>=20 >=20 > The question is also whether we need to restrict the way a CAP payload = is sent to a recipient.=20 > One could argue that it does not really matter whether it is an = INVITE, a MESSAGE, or a PUBLISH.=20 > Which one is best depends on a specific environment.=20 >=20 > But you seem to be arguing that we should rather stick with the INVITE = instead of using MESSAGE.=20 > This would at least allow us to get the message understood by every = SIP device.=20 >=20 >> ---------------------------- >>=20 >> Section 5 >>=20 >> Via: SIP/2.0/TCP sensor1.domain.com;branch=3Dz9hG4bK776sgdkse >>=20 >> [BA] Use of TCP transport makes sense, particularly in scenarios = where both CAP >> and a PIDF-LO might be included. You might consider saying something = about this >> since TCP transport for MESSAGE is not that common today.=20 >>=20 >=20 > This is just an example. Using TCP indeed makes sense for XML-based = payloads.=20 > I don't think we want to mandate that TCP is mandatory-to-use.=20 >=20 >=20 >> ---------------------------- >>=20 >> Section 6.1 >>=20 >> Does it really make sense to sign the CAP alert when the sender might = be a sensor >> that may not even by IP-connected, and the signer might be an = aggregator with a >> different identity from the or the identity in the From: = field of the >> SIP message? If you are going to recommend that, you really need to = describe >> what if anything the receiver can do to validate the signature.=20 >>=20 >=20 > I assume that the device that issues the alert is actually an IP-based = device.=20 > For me the story begins with the first IP device.=20 >=20 >> ---------------------------- >>=20 >> Section 6.2 >>=20 >> Additionally, it is RECOMMENDED to make use of SIP security >> mechanisms, such as SIP Identity [RFC4474], to tie the CAP = message >> to the SIP message. >>=20 >> [BA] Since the sender of the CAP message and the SIP message can be >> different, RFC 4474 only can guarantee that the message isn't = modified; >> it doesn't really "tie them together". For example, an attacker = could >> snoop on a signed CAP message, insert it in a SIP MESSAGE and then >> use RFC 4474, and the sender wouldn't be able to verify that they are >> unrelated though the sender would be accountable for the = mis-behavior.=20 >>=20 > With SIP Identity the identity header is either added by the end point = (unlikely) or by the outbound proxy.=20 > If it is added by the outbound proxy then there has to be TLS between = the end point and the outbound proxy.=20 > This would provide proper protection of the message exchange and would = fulfill our purpose here. Wouldn't you say so?=20 >=20 >> ---------------------------- >>=20 >> Section 6.3 >>=20 >> For some types of data-only emergency calls author/originator = and >> the receiver/recipient have a relationship with each other and >> hence it is possible (using cryptographic techniques) to verify >> whether a message was indeed issued by an authorized entity. >> Figure 1 is such an environment. Standard SIP security = mechanisms >> can be re-used for this purpose. For example, identity based >> access control is a viable approach utilizing the asserted >> identity of the alert originator using P-Asserted-Identity >> [RFC3325] or SIP Identity [RFC4474]. >>=20 >> [BA] What is the distinction between "forgery" and "Injecting false = alerts"?=20 >=20 > The former is a man-in-the-middle attack that requires the adversary = to be on-path. With the latter one the adversary does not need to be = along the communication path, i.e. does not need to have seen any = earlier message exchanges.=20 >=20 >> Verifying the identity of the sender of the SIP message may tell you = who >> is accountable for sending the emergency alert, but that isn't the = same >> as verifying the authenticity of the alert itself. =20 >=20 > True. There is the SIP identity of the sender, the field in the CAP = message (sender field), and then there is cryptographic material in case = of a signature that will have some identity information associated with = it.=20 > Currently, the draft says that we should set the sender field of the = CAP message to the value of the sender of the SIP message. Useful to set = to two equal? >=20 >>=20 >> I might suggest that the threat model focus on the following instead: >>=20 >> 1. Prevention of modification of data in transit (e.g. sending = MESSAGE over TLS) >> 2. Verification of the sender identity (Section 6.3) >> 3. Signing of alerts (Section 6.1) >>=20 >=20 > I am OK with not focusing on security threats as the document = currently does, but instead focus on the solutions.=20 > Using the terminology from the ATOCA requirements document maybe it is = better to talk about=20 >=20 > 1) Verification of the alert originator (this is the SIP stuff)=20 > 2) Verification of the alert author (this is the alert stuff) > 3) Integrity of alerts in transit (the TLS) >=20 > OK for you?=20 >=20 > Ciao > Hannes >=20 >> From: shida@ntt-at.com >> Date: Wed, 20 Apr 2011 11:27:33 +0900 >> To: ecrit@ietf.org >> Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01 >>=20 >>=20 >> I reviewed the document and followings are some comments/questions.=20= >>=20 >> In general, I am having a hard time understanding the intent of the=20= >> draft. Is it defining a CAP document composition rule (4.2) for = delivering=20 >> the CAP message from citizen to authority only? OR is it defining a = SIP=20 >> usage to transport CAP message as well? If it's latter I think more = should=20 >> be said about how SIP entities should behave. I understand it is an=20= >> experimental document but I think we need to clarify the scope of the=20= >> document somewhat.=20 >>=20 >> 1. For scenario 1, I really don't think in reality a sensor will be=20= >> implementing a SIP stack simply to support the transport of=20 >> CAP message, it just seems like an overkill. I understand how=20 >> aggregator to PSAP should be SIP to re-use what is defined=20 >> in Phone-BCP and pre-exising infrastructure. May be text can=20 >> be added that some other means may be used to deliver a CAP=20 >> message from CAP to aggregator. =20 >>=20 >> 2. I am assuming that any SIP device can use MESSAGE to=20 >> send CAP to PSAP. If so, some device will be able to handle=20 >> call-back and some won't. Do we need to distinguish devices=20 >> that will be issuing the MESSAGE to see whether call-back=20 >> can be established etc? (I guess PSAP can look at allow header=20= >> to see if the device can accept INVITE etc.) >>=20 >> 3. For both cases, should there be any recommendation on how=20 >> sensor should behave in case 200 OK is not received or error=20 >> is received from downstream? Again related to the scoping of=20 >> the document, this may not be necessary if the main intent is=20 >> to recommend CAP document composition rule.=20 >>=20 >> 4. If non SIP device is used what should be set in "sender" of CAP?=20= >> What if the CAP message is sent by a sensor which doesn't support=20= >> SIP and it is the aggregator that acts as the SIP intermediary = and=20 >> SIP endpoint? >>=20 >> 5. Use of P-Asserted-Identity doesn't provide any integrity so I = would=20 >> take it out of section 6.3. >>=20 >> 6. Why is RFC3265/RFC3903 a normative reference? I think they=20 >> should be in an informative reference as there is no normative = text=20 >> surrounding their uses.=20 >>=20 >> 7. Shouldn't RFC3261(SIP)/RFC3428(MESSAGE)/location-conveyance/ >> RFC4119(PIDF-LO) be in a normative reference? >>=20 >>=20 >> **Some nits** >>=20 >> Section 6:=20 >>=20 >> OLD ".. this document and the discussion in.." >>=20 >> NEW ".. this document and are discussed in.." >>=20 >> Section 6.2 >>=20 >> OLD "..alerts and reply them at a later time.." >>=20 >> NEW "..alerts and replay them at a later time.." >>=20 >>=20 >> Regards >> Shida >>=20 >> On Mar 30, 2011, at 11:49 PM, Marc Linsner wrote: >>=20 >> This message starts the Working Group Last Call for draft "Common = Alerting Protocol (CAP) based Data-Only Emergency Alerts using the = Session Initiation Protocol (SIP)" = (http://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-01). >>=20 >> This draft fulfills the WG milestone: >>=20 >> Apr 2011 Submit 'Common Alerting Protocol (CAP) based Data-Only = Emergency Alerts using the Session Initiation Protocol (SIP)' >>=20 >> Please submit comments to the list by COB on Friday April 15, 2011. >>=20 >> Thanks, >>=20 >> -Marc Linsner- >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >>=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 >=20 From jmpolk@cisco.com Thu Jul 7 13:00:08 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A9711E80B1 for ; Thu, 7 Jul 2011 13:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.466 X-Spam-Level: X-Spam-Status: No, score=-106.466 tagged_above=-999 required=5 tests=[AWL=-3.867, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuu4xjHTQaih for ; Thu, 7 Jul 2011 13:00:07 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 7505311E80AF for ; Thu, 7 Jul 2011 13:00:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=2538; q=dns/txt; s=iport; t=1310068807; x=1311278407; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=lp4K4sLDLhqBFgMSEdr1rQmBCrHMTUc5vCbfxS4/ttw=; b=HgubamZnOa+Wk2DCi3s/8NhykQdF2EViJMW8Kc+oc78kF/Y74z/1+CZ/ WdSVf8CpXsR6Ao2X4XtIU7BmJ+m5mUCdFBLCAup8w4ezoedMgCnKCzMuF /tOFqHUd0V/QdFn78AFwkdDTaetpUhcTe+jtv0waN9swqo9MF+4oh1+hF 4=; X-IronPort-AV: E=Sophos;i="4.65,495,1304294400"; d="scan'208";a="797155" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-2.cisco.com with ESMTP; 07 Jul 2011 20:00:06 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p67K05Lb014503; Thu, 7 Jul 2011 20:00:05 GMT Message-Id: <201107072000.p67K05Lb014503@mtv-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 07 Jul 2011 15:00:04 -0500 To: Hannes Tschofenig , James Polk From: "James M. Polk" In-Reply-To: <6D0B17CC-6F5C-4C69-9248-C9E94493E8E2@gmx.net> References: <6D0B17CC-6F5C-4C69-9248-C9E94493E8E2@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ecrit@ietf.org Subject: Re: [Ecrit] Device Identity in PIDF-LO (from draft-ietf-ecrit-data-only-ea-01 and SIP Location Conveyance) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 20:00:08 -0000 At 03:27 AM 7/7/2011, Hannes Tschofenig wrote: >Hi James, > >the example in draft-ietf-ecrit-data-only-ea-01 uses the device id >in the PIDF-LO: > > > xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" > xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" > xmlns:gml="http://www.opengis.net/gml" > entity="pres:sensor1@domain.com"> > > > > > > > 32.86726 -97.16054 > > > > > yes > > 2010-07-30T20:00:00Z > > > 802.11 > >*** mac:1234567890ab *** > 2010-07-28T20:57:29Z > > > > >The example was copied from SIP Location Conveyance and modified slightly. thanks for including the example and where the mods were done. >Now, Martin indicated that this usage of the deviceID requires the >definition of the mac: URI scheme. sounds about right, but... >James noted that this mac: URI scheme approach dated back to the >time when we worked on the HELD identity extension but in the end a >different approach was chosen (namely using separate XML elements). ... just because the HELD identity work went in another direction, does that mean you can't use a mac: URI? There's gotta be one defined already as a deviceID within the presence docs. I think I remember RFC 3856 referring to it when discussing layer 2 devices like cellphones. >So, for me the question is now what to put in there. I could just >omit this example altogether but how do we put a MAC address as a >device id into a PIDF-LO then. I think this is already defined as a part of presence, but just because it was discussed in one of those RFCs doesn't mean it was defined there. James >Ciao >Hannes From hannes.tschofenig@gmx.net Thu Jul 7 13:13:24 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A7821F87AC for ; Thu, 7 Jul 2011 13:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73Bu-X0go9tR for ; Thu, 7 Jul 2011 13:13:23 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 3AB4321F87A3 for ; Thu, 7 Jul 2011 13:13:23 -0700 (PDT) Received: (qmail invoked by alias); 07 Jul 2011 20:13:21 -0000 Received: from letku101.adsl.netsonic.fi (EHLO [10.0.0.6]) [194.29.195.101] by mail.gmx.net (mp069) with SMTP; 07 Jul 2011 22:13:21 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1840T91dBc4Cd/wqVLgqzJrNm1+IqOO3eKltR7KmQ 4bCYK/PPjQwcnb Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <201107072000.p67K05Lb014503@mtv-core-1.cisco.com> Date: Thu, 7 Jul 2011 23:13:20 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2CB5DAFD-7732-4F69-8D4D-D54F69FF49D8@gmx.net> References: <6D0B17CC-6F5C-4C69-9248-C9E94493E8E2@gmx.net> <201107072000.p67K05Lb014503@mtv-core-1.cisco.com> To: "James M. Polk" X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: ecrit@ietf.org Subject: Re: [Ecrit] Device Identity in PIDF-LO (from draft-ietf-ecrit-data-only-ea-01 and SIP Location Conveyance) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 20:13:24 -0000 On Jul 7, 2011, at 11:00 PM, James M. Polk wrote: > , does that mean you can't use a mac: URI? There's gotta be one = defined already as a deviceID within the presence docs. I think I = remember RFC 3856 referring to it when discussing layer 2 devices like = cellphones. It would be great if someone has defined a URI scheme for this purpose = already. I have not seen it.=20 If we have to define one fine as well.=20 From James.Winterbottom@commscope.com Thu Jul 7 15:33:56 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2834921F8854 for ; Thu, 7 Jul 2011 15:33:56 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SL201TCKBrEh for ; Thu, 7 Jul 2011 15:33:55 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 663C121F883E for ; Thu, 7 Jul 2011 15:33:55 -0700 (PDT) X-AuditID: 0a0404e8-b7baaae0000009ea-1f-4e16345e33ef Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id D4.41.02538.E54361E4; Thu, 7 Jul 2011 17:34:06 -0500 (CDT) Received: from CDCE10HC2.commscope.com (10.86.20.22) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 7 Jul 2011 17:34:44 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by CDCE10HC2.commscope.com (10.86.20.22) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 7 Jul 2011 17:34:44 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Fri, 8 Jul 2011 06:34:41 +0800 From: "Winterbottom, James" To: Hannes Tschofenig , "James M. Polk" Date: Fri, 8 Jul 2011 06:34:40 +0800 Thread-Topic: [Ecrit] Device Identity in PIDF-LO (from draft-ietf-ecrit-data-only-ea-01 and SIP Location Conveyance) Thread-Index: Acw84nkbFbIhuCa2Ri68ex4BmG9CRQAEm5qQ Message-ID: <5A55A45AE77F5941B18E5457ECAC818801210B4D9026@SISPE7MB1.commscope.com> References: <6D0B17CC-6F5C-4C69-9248-C9E94493E8E2@gmx.net> <201107072000.p67K05Lb014503@mtv-core-1.cisco.com> <2CB5DAFD-7732-4F69-8D4D-D54F69FF49D8@gmx.net> In-Reply-To: <2CB5DAFD-7732-4F69-8D4D-D54F69FF49D8@gmx.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: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Device Identity in PIDF-LO (from draft-ietf-ecrit-data-only-ea-01 and SIP Location Conveyance) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 22:33:56 -0000 I don't believe that there is one already defined. The Presence Data Model document is the first place that I saw this used an= d I couldn't find one defined then and that is why an earlier version of th= e identity extensions document defined one. As far as I recall, Cullen was = one of the people that suggested getting a mac URI scheme would be nearly i= mpossible to get through the IESG and suggested that we use the UUID scheme= defined in RFC4122 instead. Cheers James James Winterbottom Global Product Manager CommScope GeoLENs IP Location Product Portfolio Email: james.winterbottom@commscope.com Phone: +61-2-42-212938 Mobile: +61-447-773-560 =20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Hannes Tschofenig > Sent: Friday, 8 July 2011 6:13 AM > To: James M. Polk > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Device Identity in PIDF-LO (from draft-ietf-ecrit- > data-only-ea-01 and SIP Location Conveyance) >=20 >=20 > On Jul 7, 2011, at 11:00 PM, James M. Polk wrote: >=20 > > , does that mean you can't use a mac: URI? There's gotta be one defined > already as a deviceID within the presence docs. I think I remember RFC > 3856 referring to it when discussing layer 2 devices like cellphones. >=20 > It would be great if someone has defined a URI scheme for this purpose > already. I have not seen it. > If we have to define one fine as well. >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From bernard_aboba@hotmail.com Thu Jul 7 16:49:25 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C964D21F8A90 for ; Thu, 7 Jul 2011 16:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.391 X-Spam-Level: X-Spam-Status: No, score=-101.391 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id natYeJ-YkDNt for ; Thu, 7 Jul 2011 16:49:25 -0700 (PDT) Received: from blu0-omc3-s19.blu0.hotmail.com (blu0-omc3-s19.blu0.hotmail.com [65.55.116.94]) by ietfa.amsl.com (Postfix) with ESMTP id E7DF521F8A8F for ; Thu, 7 Jul 2011 16:49:24 -0700 (PDT) Received: from BLU152-W38 ([65.55.116.72]) by blu0-omc3-s19.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Jul 2011 16:49:24 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_b36c50d9-9f84-4bb0-ba43-9d801d7e14f3_" X-Originating-IP: [64.134.134.7] From: Bernard Aboba To: Date: Thu, 7 Jul 2011 16:49:24 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 07 Jul 2011 23:49:24.0524 (UTC) FILETIME=[8017CEC0:01CC3D00] Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 23:49:25 -0000 --_b36c50d9-9f84-4bb0-ba43-9d801d7e14f3_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hannes said: The question is also whether we need to restrict the way a CAP payload is s= ent to a recipient.=20 One could argue that it does not really matter whether it is an INVITE=2C a= MESSAGE=2C or a PUBLISH.=20 Which one is best depends on a specific environment.=20 But you seem to be arguing that we should rather stick with the INVITE inst= ead of using MESSAGE.=20 This would at least allow us to get the message understood by every SIP dev= ice. [BA] I have no problem with including CAP in MESSAGE. My major concer= n was how to ensure interoperability and potential problems that could delay emergency calls.=20 This is just an example. Using TCP indeed makes sense for XML-based payload= s.=20 I don't think we want to mandate that TCP is mandatory-to-use. [BA] I agree= that we don't want to mandate use. But we are talking about emergency cal= ls=2C so making a recommendation on how to avoid problems is probably a goo= d idea.=20 I assume that the device that issues the alert is actually an IP-based devi= ce.=20 For me the story begins with the first IP device.=20 =20 [BA] My problem with signatures is in emergency contexts is the cost and va= lue of validating them. In ATOCA there may be a model for this (e.g. government signs the CAP)=2C but in a device scen= ario=2C it's not easy to figure out how a PSAP would validate the signature or what value it would have.=20 With SIP Identity the identity header is either added by the end point (unl= ikely) or by the outbound proxy.=20 If it is added by the outbound proxy then there has to be TLS between the e= nd point and the outbound proxy.=20 This would provide proper protection of the message exchange and would fulf= ill our purpose here. Wouldn't you say so? [BA] TLS is fine with me -- but = it solves a different problem than RFC 4474. True. There is the SIP identity of the sender=2C the field in the CAP messa= ge (sender field)=2C and then there is cryptographic material in case of a = signature that will have some identity information associated with it.=20 Currently=2C the draft says that we should set the sender field of the CAP = message to the value of the sender of the SIP message. Useful to set to two= equal?[BA] That is useful if the CAP sender and SIP sender are actually th= e same. If not=2C then the CAP sender field should reflect who composed th= e CAP.=20 I am OK with not focusing on security threats as the document currently doe= s=2C but instead focus on the solutions.=20 Using the terminology from the ATOCA requirements document maybe it is bett= er to talk about=20 1) Verification of the alert originator (this is the SIP stuff)=20 2) Verification of the alert author (this is the alert stuff) 3) Integrity of alerts in transit (the TLS) OK for you?=20 [BA] Yes=2C that is a better approach. = --_b36c50d9-9f84-4bb0-ba43-9d801d7e14f3_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hannes said:

The question is also whether we need to restrict t=
he way a CAP payload is sent to a recipient.=20
One could argue that it does not really matter whether it is an INVITE=2C a=
 MESSAGE=2C or a PUBLISH.=20
Which one is best depends on a specific environment.=20

But you seem to be arguing that we should rather stick with the INVITE inst=
ead of using MESSAGE.=20
This would at least allow us to get the message understood by every SIP dev=
ice. 
[BA] I have no problem with including CAP in MESSAGE. =3B My= major concern was how to ensure interoperability and potential
problems= that could delay emergency calls.

This is just an example. Us=
ing TCP indeed makes sense for XML-based payloads.=20
I don't think we want to mandate that TCP is mandatory-to-use. 
[BA] I= agree that we don't want to mandate use. =3B But we are talking about = emergency calls=2C so making a recommendation on how to avoid problems is p= robably a good idea.

I assume that the device that issues the =
alert is actually an IP-based device.=20
For me the story begins with the first IP device. 

[BA] My pr= oblem with signatures is in emergency contexts is the cost and value of val= idating them.  =3B =3B In ATOCA there may
be a model for this (e= .g. government signs the CAP)=2C but in a device scenario=2C it's not easy = to figure out how a PSAP would
validate the signature or what value it w= ould have.

With SIP Identity the identity header is either add=
ed by the end point (unlikely) or by the outbound proxy.=20
If it is added by the outbound proxy then there has to be TLS between the e=
nd point and the outbound proxy.=20
This would provide proper protection of the message exchange and would fulf=
ill our purpose here. Wouldn't you say so? 
[BA] TLS is fine with me -= - but it solves a different problem than RFC 4474.

True. There =
is the SIP identity of the sender=2C the field in the CAP message (sender f=
ield)=2C and then there is cryptographic material in case of a signature th=
at will have some identity information associated with it.=20
Currently=2C the draft says that we should set the sender field of the CAP =
message to the value of the sender of the SIP message. Useful to set to two=
 equal?
[BA] That is useful if the CAP sender and SIP sender are actua= lly the same. =3B If not=2C then the CAP sender field should reflect wh= o composed the CAP.

I am OK with not focusing on security thre=
ats as the document currently does=2C but instead focus on the solutions.=20
Using the terminology from the ATOCA requirements document maybe it is bett=
er to talk about=20

1) Verification of the alert originator (this is the SIP stuff)=20
2) Verification of the alert author (this is the alert stuff)
3) Integrity of alerts in transit (the TLS)

OK for you? 

[BA] Yes=2C that is a better approach.

=
= --_b36c50d9-9f84-4bb0-ba43-9d801d7e14f3_-- From hannes.tschofenig@gmx.net Fri Jul 8 00:50:23 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED89921F86C7 for ; Fri, 8 Jul 2011 00:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQ9keYOpdY1Z for ; Fri, 8 Jul 2011 00:50:21 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 647CF21F86CF for ; Fri, 8 Jul 2011 00:50:21 -0700 (PDT) Received: (qmail invoked by alias); 08 Jul 2011 07:50:16 -0000 Received: from unknown (EHLO [10.255.134.118]) [192.100.123.77] by mail.gmx.net (mp049) with SMTP; 08 Jul 2011 09:50:16 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18aH4Za93caw92oZeUK6IBIkLFu/ldKxrCnZqqzFo x0TsX6apNeLVQB Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Fri, 8 Jul 2011 10:50:14 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Bernard Aboba X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 07:50:23 -0000 Hi Bernard,=20 On Jul 8, 2011, at 2:49 AM, Bernard Aboba wrote: > Hannes said: >=20 > The question is also whether we need to restrict the way a CAP payload = is sent to a recipient.=20 > One could argue that it does not really matter whether it is an = INVITE, a MESSAGE, or a PUBLISH.=20 > Which one is best depends on a specific environment.=20 >=20 > But you seem to be arguing that we should rather stick with the INVITE = instead of using MESSAGE.=20 > This would at least allow us to get the message understood by every = SIP device.=20 > [BA] I have no problem with including CAP in MESSAGE. My major = concern was how to ensure interoperability and potential > problems that could delay emergency calls.=20 Your suggestion to use INVITE seemed to be interesting but after further = thinking about it I am not sure whether the perceived level of = interoperability is worth sticking only with an INVITE. If the recipient = does not understand the CAP payload (and only the INVITE itself) then = there is still no interoperability.=20 As such, I believe I have to put text in there regarding error messages = and the core SIP spec already provides them, namely=20 * 501 Not Implemented, and=20 * 415 Unsupported Media Type I am still thinking whether we should allow the CAP payload to be used = in an INVITE, a MESSAGE, an a PUBLISH. >=20 > This is just an example. Using TCP indeed makes sense for XML-based = payloads.=20 > I don't think we want to mandate that TCP is mandatory-to-use.=20 >=20 > [BA] I agree that we don't want to mandate use. But we are talking = about emergency calls, so making a recommendation on how to avoid = problems is probably a good idea.=20 >=20 > I assume that the device that issues the alert is actually an IP-based = device.=20 > For me the story begins with the first IP device.=20 > =20 > [BA] My problem with signatures is in emergency contexts is the cost = and value of validating them. In ATOCA there may > be a model for this (e.g. government signs the CAP), but in a device = scenario, it's not easy to figure out how a PSAP would > validate the signature or what value it would have.=20 I agree with you that most deployments will in their judgements about = the security threats conclude that they do not need to additionally sign = the CAP message and instead rely on the SIP security mechanisms. That's = my assumption. Still, the security consideration section lays out the = options.=20 >=20 > With SIP Identity the identity header is either added by the end point = (unlikely) or by the outbound proxy.=20 > If it is added by the outbound proxy then there has to be TLS between = the end point and the outbound proxy.=20 > This would provide proper protection of the message exchange and would = fulfill our purpose here. Wouldn't you say so?=20 >=20 > [BA] TLS is fine with me -- but it solves a different problem than RFC = 4474. In the typical use case of SIP Identity (at least as envisioned in the = specification) the identity assertion is added by the Authentication = service (e.g. the outbound proxy) and there still has to be security = provided from the end host to that Authentication Service. This may = likely come in form of TLS since otherwise the identity assurance is of = little value if the adversary is sitting somewhere along that path.=20 =20 >=20 > True. There is the SIP identity of the sender, the field in the CAP = message (sender field), and then there is cryptographic material in case = of a signature that will have some identity information associated with = it.=20 > Currently, the draft says that we should set the sender field of the = CAP message to the value of the sender of the SIP message. Useful to set = to two equal? >=20 > [BA] That is useful if the CAP sender and SIP sender are actually the = same. If not, then the CAP sender field should reflect who composed the = CAP.=20 >=20 I put text into the draft already about the case where the two are = different.=20 > I am OK with not focusing on security threats as the document = currently does, but instead focus on the solutions.=20 > Using the terminology from the ATOCA requirements document maybe it is = better to talk about=20 >=20 > 1) Verification of the alert originator (this is the SIP stuff)=20 > 2) Verification of the alert author (this is the alert stuff) > 3) Integrity of alerts in transit (the TLS) >=20 > OK for you?=20 >=20 >=20 > [BA] Yes, that is a better approach. >=20 I proposed text already that follows this type of structure - although = not with sub-section headings.=20 Ciao Hannes > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From hannes.tschofenig@gmx.net Fri Jul 8 04:15:57 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8AD421F87C6 for ; Fri, 8 Jul 2011 04:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afDFlTzSB-EO for ; Fri, 8 Jul 2011 04:15:56 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id F36C721F8685 for ; Fri, 8 Jul 2011 04:15:55 -0700 (PDT) Received: (qmail invoked by alias); 08 Jul 2011 11:15:53 -0000 Received: from unknown (EHLO [10.255.134.118]) [192.100.123.77] by mail.gmx.net (mp071) with SMTP; 08 Jul 2011 13:15:53 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+Nah41nIaN7vhTKQCe8x0aXxdwA0a5MRLCEp+op4 GWM1v0C52fOW2c Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Fri, 8 Jul 2011 14:15:49 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <218A5B2C-7978-4FA5-83C1-46C16370B8FB@gmx.net> References: To: Bernard Aboba X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 11:15:57 -0000 I have updated the draft to reflect our discussion. Please find the most = recent version here: = http://www.tschofenig.priv.at/svn/draft-rosen-ecrit-data-only-ea/draft-iet= f-ecrit-data-only-ea-02.txt I now changed Section 4.1 that talks about the CAP transport:=20 ----- 4.1. CAP Transport Since alerts structured via CAP require a "push" medium. The following SIP requests MAY carry the CAP payload defined in this document: INVITE [RFC3261], UPDATE [RFC3311], MESSAGE [RFC3428], INFO [RFC6086], NOTIFY [RFC3265], and PUBLISH [RFC3903]. The MIME type is set to 'application/cap+xml'. If the server does not support the functionality required to fulfill the request then a 501 Not Implemented MUST be returned by RFC 3261 [RFC3261]. This is the appropriate response when a UAS does not recognize the request method and is not capable of supporting it for any user. The 415 Unsupported Media Type error MUST be returned by RFC 3261 [RFC3261] if the server is refusing to service the request because the message body of the request is in a format not supported by the server for the requested method. The server MUST return a list of acceptable formats using the Accept, Accept-Encoding, or Accept- Language header field, depending on the specific problem with the content. ----- Ciao Hannes On Jul 8, 2011, at 10:50 AM, Hannes Tschofenig wrote: > Hi Bernard,=20 >=20 > On Jul 8, 2011, at 2:49 AM, Bernard Aboba wrote: >=20 >> Hannes said: >>=20 >> The question is also whether we need to restrict the way a CAP = payload is sent to a recipient.=20 >> One could argue that it does not really matter whether it is an = INVITE, a MESSAGE, or a PUBLISH.=20 >> Which one is best depends on a specific environment.=20 >>=20 >> But you seem to be arguing that we should rather stick with the = INVITE instead of using MESSAGE.=20 >> This would at least allow us to get the message understood by every = SIP device.=20 >=20 >> [BA] I have no problem with including CAP in MESSAGE. My major = concern was how to ensure interoperability and potential >> problems that could delay emergency calls.=20 >=20 > Your suggestion to use INVITE seemed to be interesting but after = further thinking about it I am not sure whether the perceived level of = interoperability is worth sticking only with an INVITE. If the recipient = does not understand the CAP payload (and only the INVITE itself) then = there is still no interoperability.=20 >=20 > As such, I believe I have to put text in there regarding error = messages and the core SIP spec already provides them, namely=20 > * 501 Not Implemented, and=20 > * 415 Unsupported Media Type >=20 > I am still thinking whether we should allow the CAP payload to be used = in an INVITE, a MESSAGE, an a PUBLISH. >=20 >>=20 >> This is just an example. Using TCP indeed makes sense for XML-based = payloads.=20 >> I don't think we want to mandate that TCP is mandatory-to-use.=20 >>=20 >> [BA] I agree that we don't want to mandate use. But we are talking = about emergency calls, so making a recommendation on how to avoid = problems is probably a good idea.=20 >>=20 >> I assume that the device that issues the alert is actually an = IP-based device.=20 >> For me the story begins with the first IP device.=20 >=20 >>=20 >> [BA] My problem with signatures is in emergency contexts is the cost = and value of validating them. In ATOCA there may >> be a model for this (e.g. government signs the CAP), but in a device = scenario, it's not easy to figure out how a PSAP would >> validate the signature or what value it would have.=20 >=20 > I agree with you that most deployments will in their judgements about = the security threats conclude that they do not need to additionally sign = the CAP message and instead rely on the SIP security mechanisms. That's = my assumption. Still, the security consideration section lays out the = options.=20 >=20 >=20 >>=20 >> With SIP Identity the identity header is either added by the end = point (unlikely) or by the outbound proxy.=20 >> If it is added by the outbound proxy then there has to be TLS between = the end point and the outbound proxy.=20 >> This would provide proper protection of the message exchange and = would fulfill our purpose here. Wouldn't you say so?=20 >>=20 >> [BA] TLS is fine with me -- but it solves a different problem than = RFC 4474. >=20 > In the typical use case of SIP Identity (at least as envisioned in the = specification) the identity assertion is added by the Authentication = service (e.g. the outbound proxy) and there still has to be security = provided from the end host to that Authentication Service. This may = likely come in form of TLS since otherwise the identity assurance is of = little value if the adversary is sitting somewhere along that path.=20 >=20 >>=20 >> True. There is the SIP identity of the sender, the field in the CAP = message (sender field), and then there is cryptographic material in case = of a signature that will have some identity information associated with = it.=20 >> Currently, the draft says that we should set the sender field of the = CAP message to the value of the sender of the SIP message. Useful to set = to two equal? >>=20 >> [BA] That is useful if the CAP sender and SIP sender are actually the = same. If not, then the CAP sender field should reflect who composed the = CAP.=20 >>=20 >=20 > I put text into the draft already about the case where the two are = different.=20 >=20 >> I am OK with not focusing on security threats as the document = currently does, but instead focus on the solutions.=20 >> Using the terminology from the ATOCA requirements document maybe it = is better to talk about=20 >>=20 >> 1) Verification of the alert originator (this is the SIP stuff)=20 >> 2) Verification of the alert author (this is the alert stuff) >> 3) Integrity of alerts in transit (the TLS) >>=20 >> OK for you?=20 >>=20 >>=20 >> [BA] Yes, that is a better approach. >>=20 >=20 > I proposed text already that follows this type of structure - although = not with sub-section headings.=20 >=20 > Ciao > Hannes >=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 From bernard_aboba@hotmail.com Fri Jul 8 08:25:12 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1768321F8A67 for ; Fri, 8 Jul 2011 08:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AliwjRb5Iis4 for ; Fri, 8 Jul 2011 08:25:10 -0700 (PDT) Received: from blu0-omc4-s13.blu0.hotmail.com (blu0-omc4-s13.blu0.hotmail.com [65.55.111.152]) by ietfa.amsl.com (Postfix) with ESMTP id 4093921F8A8B for ; Fri, 8 Jul 2011 08:25:10 -0700 (PDT) Received: from BLU152-W21 ([65.55.111.136]) by blu0-omc4-s13.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Jul 2011 08:25:06 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_bddb7869-b43b-4055-b32c-b99e6ef01fc9_" X-Originating-IP: [98.203.198.61] From: Bernard Aboba To: Hannes Tschofenig Date: Fri, 8 Jul 2011 08:25:05 -0700 Importance: Normal In-Reply-To: <218A5B2C-7978-4FA5-83C1-46C16370B8FB@gmx.net> References: , <218A5B2C-7978-4FA5-83C1-46C16370B8FB@gmx.net> MIME-Version: 1.0 X-OriginalArrivalTime: 08 Jul 2011 15:25:06.0630 (UTC) FILETIME=[37655660:01CC3D83] Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 15:25:12 -0000 --_bddb7869-b43b-4055-b32c-b99e6ef01fc9_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks. You might mention the Allow: header=2C as well as potential advice = for avoiding errors (e.g. checking Allow: or Accept: headers=2C sending OPT= IONS=2C etc.) > Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01 > From: hannes.tschofenig@gmx.net > Date: Fri=2C 8 Jul 2011 14:15:49 +0300 > CC: ecrit@ietf.org=3B Hannes.Tschofenig@gmx.net > To: Bernard_Aboba@hotmail.com >=20 > I have updated the draft to reflect our discussion. Please find the most = recent version here: > http://www.tschofenig.priv.at/svn/draft-rosen-ecrit-data-only-ea/draft-ie= tf-ecrit-data-only-ea-02.txt >=20 > I now changed Section 4.1 that talks about the CAP transport:=20 >=20 > ----- >=20 > 4.1. CAP Transport >=20 > Since alerts structured via CAP require a "push" medium. The > following SIP requests MAY carry the CAP payload defined in this > document: INVITE [RFC3261]=2C UPDATE [RFC3311]=2C MESSAGE [RFC3428]=2C= INFO > [RFC6086]=2C NOTIFY [RFC3265]=2C and PUBLISH [RFC3903]. The MIME type= is > set to 'application/cap+xml'. >=20 > If the server does not support the functionality required to fulfill > the request then a 501 Not Implemented MUST be returned by RFC 3261 > [RFC3261]. This is the appropriate response when a UAS does not > recognize the request method and is not capable of supporting it for > any user. >=20 > The 415 Unsupported Media Type error MUST be returned by RFC 3261 > [RFC3261] if the server is refusing to service the request because > the message body of the request is in a format not supported by the > server for the requested method. The server MUST return a list of > acceptable formats using the Accept=2C Accept-Encoding=2C or Accept- > Language header field=2C depending on the specific problem with the > content. >=20 > ----- >=20 > Ciao > Hannes >=20 > On Jul 8=2C 2011=2C at 10:50 AM=2C Hannes Tschofenig wrote: >=20 > > Hi Bernard=2C=20 > >=20 > > On Jul 8=2C 2011=2C at 2:49 AM=2C Bernard Aboba wrote: > >=20 > >> Hannes said: > >>=20 > >> The question is also whether we need to restrict the way a CAP payload= is sent to a recipient.=20 > >> One could argue that it does not really matter whether it is an INVITE= =2C a MESSAGE=2C or a PUBLISH.=20 > >> Which one is best depends on a specific environment.=20 > >>=20 > >> But you seem to be arguing that we should rather stick with the INVITE= instead of using MESSAGE.=20 > >> This would at least allow us to get the message understood by every SI= P device.=20 > >=20 > >> [BA] I have no problem with including CAP in MESSAGE. My major concer= n was how to ensure interoperability and potential > >> problems that could delay emergency calls.=20 > >=20 > > Your suggestion to use INVITE seemed to be interesting but after furthe= r thinking about it I am not sure whether the perceived level of interopera= bility is worth sticking only with an INVITE. If the recipient does not und= erstand the CAP payload (and only the INVITE itself) then there is still no= interoperability.=20 > >=20 > > As such=2C I believe I have to put text in there regarding error messag= es and the core SIP spec already provides them=2C namely=20 > > * 501 Not Implemented=2C and=20 > > * 415 Unsupported Media Type > >=20 > > I am still thinking whether we should allow the CAP payload to be used = in an INVITE=2C a MESSAGE=2C an a PUBLISH. > >=20 > >>=20 > >> This is just an example. Using TCP indeed makes sense for XML-based pa= yloads.=20 > >> I don't think we want to mandate that TCP is mandatory-to-use.=20 > >>=20 > >> [BA] I agree that we don't want to mandate use. But we are talking ab= out emergency calls=2C so making a recommendation on how to avoid problems = is probably a good idea.=20 > >>=20 > >> I assume that the device that issues the alert is actually an IP-based= device.=20 > >> For me the story begins with the first IP device.=20 > >=20 > >>=20 > >> [BA] My problem with signatures is in emergency contexts is the cost a= nd value of validating them. In ATOCA there may > >> be a model for this (e.g. government signs the CAP)=2C but in a device= scenario=2C it's not easy to figure out how a PSAP would > >> validate the signature or what value it would have.=20 > >=20 > > I agree with you that most deployments will in their judgements about t= he security threats conclude that they do not need to additionally sign the= CAP message and instead rely on the SIP security mechanisms. That's my ass= umption. Still=2C the security consideration section lays out the options.= =20 > >=20 > >=20 > >>=20 > >> With SIP Identity the identity header is either added by the end point= (unlikely) or by the outbound proxy.=20 > >> If it is added by the outbound proxy then there has to be TLS between = the end point and the outbound proxy.=20 > >> This would provide proper protection of the message exchange and would= fulfill our purpose here. Wouldn't you say so?=20 > >>=20 > >> [BA] TLS is fine with me -- but it solves a different problem than RFC= 4474. > >=20 > > In the typical use case of SIP Identity (at least as envisioned in the = specification) the identity assertion is added by the Authentication servic= e (e.g. the outbound proxy) and there still has to be security provided fro= m the end host to that Authentication Service. This may likely come in form= of TLS since otherwise the identity assurance is of little value if the ad= versary is sitting somewhere along that path.=20 > >=20 > >>=20 > >> True. There is the SIP identity of the sender=2C the field in the CAP = message (sender field)=2C and then there is cryptographic material in case = of a signature that will have some identity information associated with it.= =20 > >> Currently=2C the draft says that we should set the sender field of the= CAP message to the value of the sender of the SIP message. Useful to set t= o two equal? > >>=20 > >> [BA] That is useful if the CAP sender and SIP sender are actually the = same. If not=2C then the CAP sender field should reflect who composed the = CAP.=20 > >>=20 > >=20 > > I put text into the draft already about the case where the two are diff= erent.=20 > >=20 > >> I am OK with not focusing on security threats as the document currentl= y does=2C but instead focus on the solutions.=20 > >> Using the terminology from the ATOCA requirements document maybe it is= better to talk about=20 > >>=20 > >> 1) Verification of the alert originator (this is the SIP stuff)=20 > >> 2) Verification of the alert author (this is the alert stuff) > >> 3) Integrity of alerts in transit (the TLS) > >>=20 > >> OK for you?=20 > >>=20 > >>=20 > >> [BA] Yes=2C that is a better approach. > >>=20 > >=20 > > I proposed text already that follows this type of structure - although = not with sub-section headings.=20 > >=20 > > Ciao > > Hannes > >=20 > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > >=20 >=20 = --_bddb7869-b43b-4055-b32c-b99e6ef01fc9_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thanks. You might mention the Allow: header=2C as well as potential advice = for avoiding errors (e.g. checking Allow: or Accept: headers=2C sending OPT= IONS=2C etc.)

>=3B Subject: Re: [Ecrit] WGLC - draft-ietf-ecr= it-data-only-ea-01
>=3B From: hannes.tschofenig@gmx.net
>=3B Date= : Fri=2C 8 Jul 2011 14:15:49 +0300
>=3B CC: ecrit@ietf.org=3B Hannes.T= schofenig@gmx.net
>=3B To: Bernard_Aboba@hotmail.com
>=3B
>= =3B I have updated the draft to reflect our discussion. Please find the mos= t recent version here:
>=3B http://www.tschofenig.priv.at/svn/draft-ro= sen-ecrit-data-only-ea/draft-ietf-ecrit-data-only-ea-02.txt
>=3B
&= gt=3B I now changed Section 4.1 that talks about the CAP transport:
>= =3B
>=3B -----
>=3B
>=3B 4.1. CAP Transport
>=3B >=3B Since alerts structured via CAP require a "push" medium. The>=3B following SIP requests MAY carry the CAP payload defined in this=
>=3B document: INVITE [RFC3261]=2C UPDATE [RFC3311]=2C MESSAGE [RF= C3428]=2C INFO
>=3B [RFC6086]=2C NOTIFY [RFC3265]=2C and PUBLISH [R= FC3903]. The MIME type is
>=3B set to 'application/cap+xml'.
&g= t=3B
>=3B If the server does not support the functionality require= d to fulfill
>=3B the request then a 501 Not Implemented MUST be re= turned by RFC 3261
>=3B [RFC3261]. This is the appropriate respons= e when a UAS does not
>=3B recognize the request method and is not = capable of supporting it for
>=3B any user.
>=3B
>=3B = The 415 Unsupported Media Type error MUST be returned by RFC 3261
>= =3B [RFC3261] if the server is refusing to service the request because>=3B the message body of the request is in a format not supported by= the
>=3B server for the requested method. The server MUST return = a list of
>=3B acceptable formats using the Accept=2C Accept-Encodi= ng=2C or Accept-
>=3B Language header field=2C depending on the spe= cific problem with the
>=3B content.
>=3B
>=3B -----
= >=3B
>=3B Ciao
>=3B Hannes
>=3B
>=3B On Jul 8=2C 20= 11=2C at 10:50 AM=2C Hannes Tschofenig wrote:
>=3B
>=3B >=3B H= i Bernard=2C
>=3B >=3B
>=3B >=3B On Jul 8=2C 2011=2C at 2:4= 9 AM=2C Bernard Aboba wrote:
>=3B >=3B
>=3B >=3B>=3B Hanne= s said:
>=3B >=3B>=3B
>=3B >=3B>=3B The question is also= whether we need to restrict the way a CAP payload is sent to a recipient. =
>=3B >=3B>=3B One could argue that it does not really matter whet= her it is an INVITE=2C a MESSAGE=2C or a PUBLISH.
>=3B >=3B>=3B W= hich one is best depends on a specific environment.
>=3B >=3B>=3B=
>=3B >=3B>=3B But you seem to be arguing that we should rather s= tick with the INVITE instead of using MESSAGE.
>=3B >=3B>=3B This= would at least allow us to get the message understood by every SIP device.=
>=3B >=3B
>=3B >=3B>=3B [BA] I have no problem with incl= uding CAP in MESSAGE. My major concern was how to ensure interoperability = and potential
>=3B >=3B>=3B problems that could delay emergency ca= lls.
>=3B >=3B
>=3B >=3B Your suggestion to use INVITE seem= ed to be interesting but after further thinking about it I am not sure whet= her the perceived level of interoperability is worth sticking only with an = INVITE. If the recipient does not understand the CAP payload (and only the = INVITE itself) then there is still no interoperability.
>=3B >=3B <= br>>=3B >=3B As such=2C I believe I have to put text in there regarding= error messages and the core SIP spec already provides them=2C namely
&= gt=3B >=3B * 501 Not Implemented=2C and
>=3B >=3B * 415 Unsupport= ed Media Type
>=3B >=3B
>=3B >=3B I am still thinking whethe= r we should allow the CAP payload to be used in an INVITE=2C a MESSAGE=2C = an a PUBLISH.
>=3B >=3B
>=3B >=3B>=3B
>=3B >=3B>= =3B This is just an example. Using TCP indeed makes sense for XML-based pay= loads.
>=3B >=3B>=3B I don't think we want to mandate that TCP is= mandatory-to-use.
>=3B >=3B>=3B
>=3B >=3B>=3B [BA] I a= gree that we don't want to mandate use. But we are talking about emergency= calls=2C so making a recommendation on how to avoid problems is probably a= good idea.
>=3B >=3B>=3B
>=3B >=3B>=3B I assume that t= he device that issues the alert is actually an IP-based device.
>=3B = >=3B>=3B For me the story begins with the first IP device.
>=3B &= gt=3B
>=3B >=3B>=3B
>=3B >=3B>=3B [BA] My problem with = signatures is in emergency contexts is the cost and value of validating the= m. In ATOCA there may
>=3B >=3B>=3B be a model for this (e.g. g= overnment signs the CAP)=2C but in a device scenario=2C it's not easy to fi= gure out how a PSAP would
>=3B >=3B>=3B validate the signature or = what value it would have.
>=3B >=3B
>=3B >=3B I agree with = you that most deployments will in their judgements about the security threa= ts conclude that they do not need to additionally sign the CAP message and = instead rely on the SIP security mechanisms. That's my assumption. Still=2C= the security consideration section lays out the options.
>=3B >=3B=
>=3B >=3B
>=3B >=3B>=3B
>=3B >=3B>=3B With SIP= Identity the identity header is either added by the end point (unlikely) o= r by the outbound proxy.
>=3B >=3B>=3B If it is added by the outb= ound proxy then there has to be TLS between the end point and the outbound = proxy.
>=3B >=3B>=3B This would provide proper protection of the = message exchange and would fulfill our purpose here. Wouldn't you say so? <= br>>=3B >=3B>=3B
>=3B >=3B>=3B [BA] TLS is fine with me -- = but it solves a different problem than RFC 4474.
>=3B >=3B
>= =3B >=3B In the typical use case of SIP Identity (at least as envisioned = in the specification) the identity assertion is added by the Authentication= service (e.g. the outbound proxy) and there still has to be security provi= ded from the end host to that Authentication Service. This may likely come = in form of TLS since otherwise the identity assurance is of little value if= the adversary is sitting somewhere along that path.
>=3B >=3B
= >=3B >=3B>=3B
>=3B >=3B>=3B True. There is the SIP identity= of the sender=2C the field in the CAP message (sender field)=2C and then t= here is cryptographic material in case of a signature that will have some i= dentity information associated with it.
>=3B >=3B>=3B Currently= =2C the draft says that we should set the sender field of the CAP message t= o the value of the sender of the SIP message. Useful to set to two equal?>=3B >=3B>=3B
>=3B >=3B>=3B [BA] That is useful if the CA= P sender and SIP sender are actually the same. If not=2C then the CAP send= er field should reflect who composed the CAP.
>=3B >=3B>=3B
&= gt=3B >=3B
>=3B >=3B I put text into the draft already about the = case where the two are different.
>=3B >=3B
>=3B >=3B>=3B= I am OK with not focusing on security threats as the document currently do= es=2C but instead focus on the solutions.
>=3B >=3B>=3B Using the= terminology from the ATOCA requirements document maybe it is better to tal= k about
>=3B >=3B>=3B
>=3B >=3B>=3B 1) Verification of = the alert originator (this is the SIP stuff)
>=3B >=3B>=3B 2) Ver= ification of the alert author (this is the alert stuff)
>=3B >=3B>= =3B 3) Integrity of alerts in transit (the TLS)
>=3B >=3B>=3B
= >=3B >=3B>=3B OK for you?
>=3B >=3B>=3B
>=3B >=3B&g= t=3B
>=3B >=3B>=3B [BA] Yes=2C that is a better approach.
>= =3B >=3B>=3B
>=3B >=3B
>=3B >=3B I proposed text alread= y that follows this type of structure - although not with sub-section headi= ngs.
>=3B >=3B
>=3B >=3B Ciao
>=3B >=3B Hannes
&g= t=3B >=3B
>=3B >=3B>=3B _______________________________________= ________
>=3B >=3B>=3B Ecrit mailing list
>=3B >=3B>=3B E= crit@ietf.org
>=3B >=3B>=3B https://www.ietf.org/mailman/listinfo/= ecrit
>=3B >=3B
>=3B
= --_bddb7869-b43b-4055-b32c-b99e6ef01fc9_-- From hannes.tschofenig@gmx.net Sun Jul 10 12:49:17 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7791B21F85A4 for ; Sun, 10 Jul 2011 12:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qq2rbsCOGhbE for ; Sun, 10 Jul 2011 12:49:15 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 75F3421F857E for ; Sun, 10 Jul 2011 12:49:15 -0700 (PDT) Received: (qmail invoked by alias); 10 Jul 2011 19:49:08 -0000 Received: from letku214.adsl.netsonic.fi (EHLO [10.0.0.6]) [194.29.195.214] by mail.gmx.net (mp017) with SMTP; 10 Jul 2011 21:49:08 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19pCGtfo+ZpDLBBHSL44NO+ga7zatbsxQDvUGX9Di ZXbhVd0QyKIaKI Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Sun, 10 Jul 2011 22:49:07 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: , <218A5B2C-7978-4FA5-83C1-46C16370B8FB@gmx.net> To: Bernard Aboba X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 19:49:17 -0000 I put additional text into the document regarding error handling. I got = inspired by the SIP location conveyance document.=20 Let's see whether there is still room for improvement. Here is the = updated draft: = http://www.tschofenig.priv.at/svn/draft-rosen-ecrit-data-only-ea/draft-iet= f-ecrit-data-only-ea-02.txt On Jul 8, 2011, at 6:25 PM, Bernard Aboba wrote: > Thanks. You might mention the Allow: header, as well as potential = advice for avoiding errors (e.g. checking Allow: or Accept: headers, = sending OPTIONS, etc.) >=20 > > Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01 > > From: hannes.tschofenig@gmx.net > > Date: Fri, 8 Jul 2011 14:15:49 +0300 > > CC: ecrit@ietf.org; Hannes.Tschofenig@gmx.net > > To: Bernard_Aboba@hotmail.com > >=20 > > I have updated the draft to reflect our discussion. Please find the = most recent version here: > > = http://www.tschofenig.priv.at/svn/draft-rosen-ecrit-data-only-ea/draft-iet= f-ecrit-data-only-ea-02.txt > >=20 > > I now changed Section 4.1 that talks about the CAP transport:=20 > >=20 > > ----- > >=20 > > 4.1. CAP Transport > >=20 > > Since alerts structured via CAP require a "push" medium. The > > following SIP requests MAY carry the CAP payload defined in this > > document: INVITE [RFC3261], UPDATE [RFC3311], MESSAGE [RFC3428], = INFO > > [RFC6086], NOTIFY [RFC3265], and PUBLISH [RFC3903]. The MIME type is > > set to 'application/cap+xml'. > >=20 > > If the server does not support the functionality required to fulfill > > the request then a 501 Not Implemented MUST be returned by RFC 3261 > > [RFC3261]. This is the appropriate response when a UAS does not > > recognize the request method and is not capable of supporting it for > > any user. > >=20 > > The 415 Unsupported Media Type error MUST be returned by RFC 3261 > > [RFC3261] if the server is refusing to service the request because > > the message body of the request is in a format not supported by the > > server for the requested method. The server MUST return a list of > > acceptable formats using the Accept, Accept-Encoding, or Accept- > > Language header field, depending on the specific problem with the > > content. > >=20 > > ----- > >=20 > > Ciao > > Hannes > >=20 > > On Jul 8, 2011, at 10:50 AM, Hannes Tschofenig wrote: > >=20 > > > Hi Bernard,=20 > > >=20 > > > On Jul 8, 2011, at 2:49 AM, Bernard Aboba wrote: > > >=20 > > >> Hannes said: > > >>=20 > > >> The question is also whether we need to restrict the way a CAP = payload is sent to a recipient.=20 > > >> One could argue that it does not really matter whether it is an = INVITE, a MESSAGE, or a PUBLISH.=20 > > >> Which one is best depends on a specific environment.=20 > > >>=20 > > >> But you seem to be arguing that we should rather stick with the = INVITE instead of using MESSAGE.=20 > > >> This would at least allow us to get the message understood by = every SIP device.=20 > > >=20 > > >> [BA] I have no problem with including CAP in MESSAGE. My major = concern was how to ensure interoperability and potential > > >> problems that could delay emergency calls.=20 > > >=20 > > > Your suggestion to use INVITE seemed to be interesting but after = further thinking about it I am not sure whether the perceived level of = interoperability is worth sticking only with an INVITE. If the recipient = does not understand the CAP payload (and only the INVITE itself) then = there is still no interoperability.=20 > > >=20 > > > As such, I believe I have to put text in there regarding error = messages and the core SIP spec already provides them, namely=20 > > > * 501 Not Implemented, and=20 > > > * 415 Unsupported Media Type > > >=20 > > > I am still thinking whether we should allow the CAP payload to be = used in an INVITE, a MESSAGE, an a PUBLISH. > > >=20 > > >>=20 > > >> This is just an example. Using TCP indeed makes sense for = XML-based payloads.=20 > > >> I don't think we want to mandate that TCP is mandatory-to-use.=20 > > >>=20 > > >> [BA] I agree that we don't want to mandate use. But we are = talking about emergency calls, so making a recommendation on how to = avoid problems is probably a good idea.=20 > > >>=20 > > >> I assume that the device that issues the alert is actually an = IP-based device.=20 > > >> For me the story begins with the first IP device.=20 > > >=20 > > >>=20 > > >> [BA] My problem with signatures is in emergency contexts is the = cost and value of validating them. In ATOCA there may > > >> be a model for this (e.g. government signs the CAP), but in a = device scenario, it's not easy to figure out how a PSAP would > > >> validate the signature or what value it would have.=20 > > >=20 > > > I agree with you that most deployments will in their judgements = about the security threats conclude that they do not need to = additionally sign the CAP message and instead rely on the SIP security = mechanisms. That's my assumption. Still, the security consideration = section lays out the options.=20 > > >=20 > > >=20 > > >>=20 > > >> With SIP Identity the identity header is either added by the end = point (unlikely) or by the outbound proxy.=20 > > >> If it is added by the outbound proxy then there has to be TLS = between the end point and the outbound proxy.=20 > > >> This would provide proper protection of the message exchange and = would fulfill our purpose here. Wouldn't you say so?=20 > > >>=20 > > >> [BA] TLS is fine with me -- but it solves a different problem = than RFC 4474. > > >=20 > > > In the typical use case of SIP Identity (at least as envisioned in = the specification) the identity assertion is added by the Authentication = service (e.g. the outbound proxy) and there still has to be security = provided from the end host to that Authentication Service. This may = likely come in form of TLS since otherwise the identity assurance is of = little value if the adversary is sitting somewhere along that path.=20 > > >=20 > > >>=20 > > >> True. There is the SIP identity of the sender, the field in the = CAP message (sender field), and then there is cryptographic material in = case of a signature that will have some identity information associated = with it.=20 > > >> Currently, the draft says that we should set the sender field of = the CAP message to the value of the sender of the SIP message. Useful to = set to two equal? > > >>=20 > > >> [BA] That is useful if the CAP sender and SIP sender are actually = the same. If not, then the CAP sender field should reflect who composed = the CAP.=20 > > >>=20 > > >=20 > > > I put text into the draft already about the case where the two are = different.=20 > > >=20 > > >> I am OK with not focusing on security threats as the document = currently does, but instead focus on the solutions.=20 > > >> Using the terminology from the ATOCA requirements document maybe = it is better to talk about=20 > > >>=20 > > >> 1) Verification of the alert originator (this is the SIP stuff)=20= > > >> 2) Verification of the alert author (this is the alert stuff) > > >> 3) Integrity of alerts in transit (the TLS) > > >>=20 > > >> OK for you?=20 > > >>=20 > > >>=20 > > >> [BA] Yes, that is a better approach. > > >>=20 > > >=20 > > > I proposed text already that follows this type of structure - = although not with sub-section headings.=20 > > >=20 > > > Ciao > > > Hannes > > >=20 > > >> _______________________________________________ > > >> Ecrit mailing list > > >> Ecrit@ietf.org > > >> https://www.ietf.org/mailman/listinfo/ecrit > > >=20 > >=20 From bernard_aboba@hotmail.com Sun Jul 10 16:05:10 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2658321F8650 for ; Sun, 10 Jul 2011 16:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.995 X-Spam-Level: X-Spam-Status: No, score=-101.995 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJbk7J-bBs0i for ; Sun, 10 Jul 2011 16:05:08 -0700 (PDT) Received: from blu0-omc3-s7.blu0.hotmail.com (blu0-omc3-s7.blu0.hotmail.com [65.55.116.82]) by ietfa.amsl.com (Postfix) with ESMTP id 466AD21F8649 for ; Sun, 10 Jul 2011 16:05:06 -0700 (PDT) Received: from BLU152-W4 ([65.55.116.74]) by blu0-omc3-s7.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 10 Jul 2011 16:05:06 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_bef81b3f-d0da-4286-8f06-96bd977315a6_" X-Originating-IP: [64.134.138.0] From: Bernard Aboba To: Date: Sun, 10 Jul 2011 16:05:05 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 10 Jul 2011 23:05:06.0279 (UTC) FILETIME=[CEE50F70:01CC3F55] Subject: Re: [Ecrit] Unauthenticated access review -02 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 23:05:10 -0000 --_bef81b3f-d0da-4286-8f06-96bd977315a6_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Here is my review.=20 Summary ----------- =20 This document has improved but there are still some major issues. An=20 important use case (unauthorized network access) does not appear to be=20 covered=2C and the operational implications of enabling unauthenticated or unauthorized emergency access have not been explored deeply enough. My re= commendation is that operators be recruited to review this document.=20 Specific comments:=20 1. Introduction Summoning police=2C the fire department or an ambulance in emergencies is one of the fundamental and most-valued functions of the telephone. As telephone functionality moves from circuit-switched telephony to Internet telephony=2C its users rightfully expect that this core functionality will continue to work at least as well as it has for the older technology. New devices and services are being made available that could be used to make a request for help=2C which are not traditional telephones=2C and users are increasingly expecting them to be used to place emergency calls. [BA] It would be useful to (briefly) discuss the existing functionality for emergency calling with Non-Service Initialized (NSI) devices here. We distinguish between three conditions: No Access Authentication (NAA): In the NAA case=2C the emergency caller does not posses valid credentials for the access network. This includes the case where the access network allows pay-per- use=2C as is common for wireless hotspots=2C but there is insufficien= t time to enter credit card details and other registration information required for access. It also covers all cases where either no credentials are available at all=2C or the available credentials do not work for the given IAP/ISP. As a result=2C the NAA case basically combines the below NASP and ZBP cases=2C but at the IAP/ISP level. Support for emergency call handling in the NAA case is subject to the local policy of the ISP. Such policy may vary substantially between ISPs and typically depends on external factors that are not under the ISP control. [BA] This does not appear to cover the case of lack of network access=20 authorization. For example=2C a user might have an account=2C but have=20 depleted their prepaid account=2C or perhaps they are authorized only for voice=2C but not data. Note: At the time of writing there is no regulation in place that demands the functionality described in this memo. SDOs have started their work on this subject in a proactive fashion in the anticipation that national regulation will demand it for a subset of network environments. [BA] This should also stated earlier=2C such in the abstract. There are also indications that the functionality of unauthenticated emergency calls (called SIM-less calls) in today's cellular system in certain countries leads to a fair amount of hoax or test calls. This causes overload situations at PSAPs which is considered harmful to the overall availability and reliability of emergency services. As an example=2C Federal Office of Communications (OFCOM=2C Switzerland) provided statistics about emergency (112) calls in Switzerland from Jan. 1997 to Nov. 2001. Switzerland did not offer SIM-less emergency calls except for almost a month in July 2000 where a significant increase in hoax and test calls was reported. As a consequence=2C the functionality was disabled again. More details can be found in the panel presentations of the 3rd SDO Emergency Services Workshop [esw07]. [BA] I recommend that these paragraphs be moved up earlier=2C right after a basic description of NSI functionality. Figure 1 compiles the basic logic taking place during network entry for requesting an emergency service and shows the interrelation between the three conditions described in the above section. +-----Y |Start| `...../ | | Are credentials | for network attachment | available? | NO v YES +----------------------------+ | | | | V v .............. ................ | Idle: Wait | |Execute | | for ES Call| |LLA Procedures| | Initiation | "--------------' "------------' | Is | +---------->O emergency | | | Is ASP service | NO +-----Y | | configured? network +--->| End | | +---------------+ attachment| `...../ | YES | | NO possible? | | | | v | v v +------------+ | +------------+ +------------+ | Execute | | | Execute | | Execute | | NAA |--------+ | Phone BCP | | NASP | | Procedures | | Procedures | | Procedures | +------------+ +------------+ +------------+ Authorization for| | Emergency Call? | | +--------------+ v | NO | YES +-----Y | | | Done| v v `...../ +------------+ +------------+ | Execute | | Execute | | ZBP | | Phone BCP | | Procedures | | Procedures | +------------+ +------------+ | | | | v v +-----Y +-----Y | Done| | Done| `...../ `...../ Abbreviations: LLA: Link Layer Attachment ES: Emergency Services Figure 1: Flow Diagram [BA] The reality is considerably more complicated that than this.=20 For example: * network access credentials may be available=2C but not authorization (e.g= . depleted prepaid account=2C no data authorization) * A Web portal using DNS spoofing might be in place.=20 * Firewalls may be in place blocking access to some services (e.g. no UDP/T= CP outbound=2C only HTTP).=20 As a result=2C I'm not convinced that this flowchart is useful enough in it= s current state. For example=2C the case of uanthorized access will resul= t in gong down a unexpected code path. Even if it is updated it would pro= bably be better to move it to an appendix so as not to interrupt the docume= nt flow. It might even make sense to remove it altogether. 5.1.5. SIP Emergency Call Signaling SIP signaling capabilities [RFC3261] are mandated for end hosts. The initial SIP signaling method is an INVITE. The SIP INVITE request MUST be constructed according to the requirements in Section 9.2 [I-D.ietf-ecrit-phonebcp]. Regarding callback behavior SIP UAs SHOULD place a globally routable URI in a Contact: header. [BA] SIP UA's can't obtain GRUUs on their own. Is there an ASP requirement here? Also=2C should there be a reference to a PSAP callback document? 5.2.2. Location Determination and Location Configuration The ISP is responsible for location determination and exposes this information to the end points via location configuration protocols. The considerations described in [I-D.ietf-ecrit-location-hiding-req] are applicable to this document. The ISP MUST support one of the LCPs described in Section 6.5 of [I-D.ietf-ecrit-phonebcp]. The description in Section 6.5 and 6.6 of [I-D.ietf-ecrit-phonebcp] regarding the interaction between the end device and the LIS applies to this document. The interaction between the LIS at the ISP and the IAB is often priorietary but the description in [I-D.winterbottom-geopriv-lis2lis-req] may be relevant to the reader. [BA] Don't you mean IAP and not IAB here? 6.2. Securing Network Attachment in NAA Cases 2) Null Authentication: In one case (e.g. WiMAX) an EAP method is performed. However=2C no credentials specific to either the server or the device or subscription are used as part of the authentication exchange. An example for this would be an EAP-TLS exchange with using the TLS_DH_anon (anonymous) ciphersuite. =20 [BA] EAP-TLS [RFC 5216] does not support the negotiation of the anonymous D= H ciphersuite. At a minimum=2C the server needs to provide a certificate.=20 Alternatively=2C a publicly available static key for emergency access could be used. In the latter case=2C the device would need to be provisioned with the appropriate emergency key for the IAP/ISP in advance. In another case (e.g. IEEE 802.11)=2C no EAP method is used=2C so that empty frames are transported during the over the air IEEE 802.1X exchange. In this case the authentication state machine completes with no cryptographic keys being exchanged. [BA] It is not clear what it is being described here. If WPA2 Enterprise is used=2C then EAP and an EAP method will need to be selected. RFC 3748 does not support exchange of "empty" EAP frames. 7. Security Considerations There are a couple of new vulnerabilities raised with unauthenticated emergency services in NASP/NAA cases since the PSAP operator will typically not possess any identity information about the emergency call via the signaling path itself. In countries where this functionality is used for GSM networks today this has lead to a significant amount of misuse. [BA] I think you need to discuss the NASP and NAA cases separately.=20 In the NASP case=2C the user might have valid credentials with the ASP=2C so that the PSAP could obtain identify information. In the NAA case=2C you need to separate unauthenticated from unauthorized access. In the former case=2C there may be no NAI=2C but there may be other identifyin= g info (e.g. MAC address). In the latter case there is an identity.=20 In the context of NAA=2C the IAP and the ISP will probably want to make sure that the claimed emergency caller indeed performs an emergency call rather than using the network for other purposes=2C and thereby acting fraudulent by skipping any authentication=2C authorization and accounting procedures. By restricting access of the unauthenticated emergency caller to the LoST server and the PSAP URI=2C traffic can be restricted only to emergency calls. This can be accomplished with traffic separation. The details=2C however=2C e.g. for using filtering= =2C depend on the deployed ISP architecture and are beyond the scope of this document. We only illustrate a possible model. If the ISP runs its own LoST server=2C it would maintain an access control list including all IP addresses contained in responses returned by the LoST server=2C as well as the LoST server itself. (It may need to translate the domain names returned to IP addresses and hope that the resolution captures all possible DNS responses.) Since the media destination addresses are not predictable=2C the ISP also has to provide a SIP outbound proxy so that it can determine the media addresses and add those to the filter list. [BA] There are some very challenging operational problems here that you need to discuss in more depth. I would recommend that this section=20 be reviewed by operators=2C to ensure that the advice is implementable. Some concerns: 1. DNS spoofing. Many 802.11 hotspots use web portals today along with DNS spoofing. This will block any emergency calling device=20 without a web browser=2C create delays for those with a browser=2C and may cause certificate or DNSSEC validation failures within VOIP clients.=20 2. ISP operation of a SIP outbound proxy configuration. This doesn't seem implementable to me. Getting a naive user to change their SIP outbound proxy configuration to make an emergency call is time consuming and likely to consume valuable time in an emergency. There are SIP clients that will require SIP over TLS and may not have trust anchors configured for the ISP SIP proxy. Overall=2C an ISP taking this on will be challenged to provide tech support to non-customers in potentially emergent situations. Do we really think this is a viable approach?=20 3. Firewall configurations. =20 Operators will often have concerns about opening generic holes=20 in the firewall (e.g. opening a hole for traffic to destination=20 ports 5060/5061). To ensure that traffic is actually being used=20 for emergency purposes=2C deep packet inspection may be required. =20 But what happens if the traffic is encrypted (e.g. SIP over TLS)?=20 = --_bef81b3f-d0da-4286-8f06-96bd977315a6_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Here is my review.


Summary
-----------

=20 This document has improved but there are still some major issues. An=20 important use case (unauthorized network access) does not appear to be=20 covered=2C and the operational implications of enabling unauthenticated or unauthorized emergency access have not been explored deeply enough. = =3B My recommendation is that operators be recruited to review this documen= t.



Specific comments:




1. =3B Introduction

 = =3B =3B Summoning police=2C the fire department or an ambulance in emer= gencies
 =3B =3B is one of the fundamental and most-valued funct= ions of the telephone.
 =3B =3B As telephone functionality moves= from circuit-switched telephony to
 =3B =3B Internet telephony= =2C its users rightfully expect that this core
 =3B =3B function= ality will continue to work at least as well as it has for
 =3B = =3B the older technology. =3B New devices and services are being made =3B =3B available that could be used to make a request for help= =2C which are
 =3B =3B not traditional telephones=2C and users a= re increasingly expecting them
 =3B =3B to be used to place emer= gency calls.

[BA] It would be useful to (briefly) discuss the existi= ng functionality
for emergency calling with Non-Service Initialized (NSI= ) devices here.

 =3B =3B We distinguish between three condit= ions:

 =3B =3B No Access Authentication (NAA): =3B In th= e NAA case=2C the emergency
 =3B =3B =3B =3B =3B cal= ler does not posses valid credentials for the access network.
 =3B&n= bsp=3B =3B =3B =3B This includes the case where the access netw= ork allows pay-per-
 =3B =3B =3B =3B =3B use=2C as i= s common for wireless hotspots=2C but there is insufficient
 =3B&nbs= p=3B =3B =3B =3B time to enter credit card details and other re= gistration
 =3B =3B =3B =3B =3B information required= for access. =3B It also covers all cases where
 =3B =3B&nbs= p=3B =3B =3B either no credentials are available at all=2C or the a= vailable
 =3B =3B =3B =3B =3B credentials do not wor= k for the given IAP/ISP. =3B As a result=2C the
 =3B =3B&nbs= p=3B =3B =3B NAA case basically combines the below NASP and ZBP cas= es=2C but at
 =3B =3B =3B =3B =3B the IAP/ISP level.=  =3B Support for emergency call handling in the NAA
 =3B =3B=  =3B =3B =3B case is subject to the local policy of the ISP.&nb= sp=3B Such policy may
 =3B =3B =3B =3B =3B vary subs= tantially between ISPs and typically depends on external
 =3B = =3B =3B =3B =3B factors that are not under the ISP control.
=
[BA] This does not appear to cover the case of lack of network access <= br>authorization. For example=2C a user might have an account=2C but have <= br>depleted their prepaid account=2C or perhaps they are authorized onlyfor voice=2C but not data.

 =3B =3B Note: At the time of wr= iting there is no regulation in place that
 =3B =3B demands the = functionality described in this memo. =3B SDOs have started
 =3B=  =3B their work on this subject in a proactive fashion in the anticipat= ion
 =3B =3B that national regulation will demand it for a subse= t of network
 =3B =3B environments.

[BA] This should also= stated earlier=2C such in the abstract.

 =3B =3B There are = also indications that the functionality of unauthenticated
 =3B = =3B emergency calls (called SIM-less calls) in today's cellular system in =3B =3B certain countries leads to a fair amount of hoax or test= calls. =3B This
 =3B =3B causes overload situations at PSAP= s which is considered harmful to
 =3B =3B the overall availabili= ty and reliability of emergency services.

 =3B =3B As an exa= mple=2C Federal Office of Communications (OFCOM=2C Switzerland)
 =3B=  =3B provided statistics about emergency (112) calls in Switzerland fro= m
 =3B =3B Jan. 1997 to Nov. 2001. =3B Switzerland did not o= ffer SIM-less emergency
 =3B =3B calls except for almost a month= in July 2000 where a significant
 =3B =3B increase in hoax and = test calls was reported. =3B As a consequence=2C the
 =3B = =3B functionality was disabled again. =3B More details can be found in = the
 =3B =3B panel presentations of the 3rd SDO Emergency Servic= es Workshop
 =3B =3B [esw07].

[BA] I recommend that these= paragraphs be moved up earlier=2C right after
a basic description of NS= I functionality.

 =3B =3B Figure 1 compiles the basic logic = taking place during network entry
 =3B =3B for requesting an eme= rgency service and shows the interrelation
 =3B =3B between the = three conditions described in the above section.



 =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B +-----Y
 =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B |Start|
 =3B =3B =3B =3B =3B =3B&n= bsp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B `...../=
 =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B |<= br> =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B | Are= credentials
 =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B | for network attachment
 =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B | available?
 =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B |
 =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B NO =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B v =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B YES
 =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B +----------------------------+
 = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B | =3B =3B =3B =3B =3B =3B =3B&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B |
 =3B =3B =3B =3B =3B =3B =3B&n= bsp=3B =3B =3B =3B =3B | =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B |
 =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B V =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B v
 =3B =3B=  =3B =3B =3B =3B =3B .............. =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B ................
 =3B =3B =3B =3B&nb= sp=3B =3B =3B | Idle: Wait | =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B= |Execute =3B =3B =3B =3B =3B =3B |
 =3B&nbs= p=3B =3B =3B =3B =3B =3B | for ES Call| =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B |LLA Procedures|
 =3B =3B =3B =3B&= nbsp=3B =3B =3B | Initiation | =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B= "--------------'
 =3B =3B =3B =3B =3B =3B = =3B "------------' =3B =3B =3B =3B =3B =3B =3B&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B |
 =3B =3B =3B Is =3B =3B = =3B =3B =3B =3B =3B | =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B= +---------->=3BO
 =3B =3B =3B emergency | =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B | =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B | Is ASP
 =3B =3B =3B service&n= bsp=3B =3B | NO +-----Y =3B =3B =3B | =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B | configured? =3B =3B =3B network =3B =3B +--->=3B| End | = =3B =3B =3B | =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B +---------------+
 =3B =3B =3B a= ttachment| =3B =3B =3B `...../ =3B =3B =3B | = =3B =3B =3B =3B =3B =3B YES | =3B =3B =3B&n= bsp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B | NO
 =3B =3B =3B possible? | =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B | =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B | =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B |
&n= bsp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B v =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B | = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B= v =3B =3B =3B =3B =3B =3B =3B =3B =3B&= nbsp=3B =3B =3B =3B =3B v
 =3B =3B =3B = =3B =3B =3B =3B +------------+ =3B =3B =3B =3B&= nbsp=3B =3B =3B | =3B =3B =3B =3B +------------+&nb= sp=3B =3B =3B +------------+
 =3B =3B =3B =3B&nb= sp=3B =3B =3B | Execute =3B =3B =3B | =3B =3B&n= bsp=3B =3B =3B =3B =3B | =3B =3B =3B =3B | = Execute =3B =3B =3B | =3B =3B =3B | Execute =3B=  =3B =3B |
 =3B =3B =3B =3B =3B =3B = =3B | NAA =3B =3B =3B =3B =3B =3B =3B |--------= + =3B =3B =3B =3B | Phone BCP =3B | =3B =3B&nbs= p=3B | NASP =3B =3B =3B =3B =3B =3B |
 =3B&n= bsp=3B =3B =3B =3B =3B =3B | Procedures | =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B | Procedures | =3B =3B =3B | Procedures |
&= nbsp=3B =3B =3B =3B =3B =3B =3B +------------+ = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B +------------+ =3B =3B =3B +----------= --+
 =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B Authorization for| = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B |
 =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B Emergency Call? =3B | =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B |
 =3B =3B =3B =3B =3B =3B =3B&n= bsp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B= +--------------+ =3B =3B =3B =3B =3B =3B =3B&n= bsp=3B =3B =3B =3B =3B =3B =3B =3B v
 = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B | NO =3B =3B&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B | YES = =3B =3B =3B =3B =3B =3B =3B =3B +-----Y
&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B | =3B =3B&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B | =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B | Done|
 =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B v =3B =3B =3B =3B =3B&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B v =3B&n= bsp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B `...../
 =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B +------------+ =3B +------------+
 = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B | = Execute =3B =3B =3B | =3B | Execute =3B =3B =3B= |
 =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B | ZBP =3B =3B =3B =3B =3B =3B =3B |&nb= sp=3B | Phone BCP =3B |
 =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B | Procedures | =3B | Procedures | =3B =3B =3B =3B =3B =3B =3B =3B =3B&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B +------------+ =3B +------------+
 =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B | =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B |
 =3B&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B | =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B |
 =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B v&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B v
 =3B =3B =3B =3B =3B&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B =3B +-----= Y =3B =3B =3B =3B =3B =3B =3B +-----Y
 = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B | Done| =3B =3B =3B =3B = =3B =3B =3B | Done|
 =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B `...../=  =3B =3B =3B =3B =3B =3B =3B `...../

&nb= sp=3B =3B Abbreviations:
 =3B =3B =3B =3B LLA: Link = Layer Attachment
 =3B =3B =3B =3B ES: Emergency Services=

 =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B Figure 1: Flow = Diagram

[BA] The reality is considerably more complicated that than = this.
For example:

* network access credentials may be available= =2C but not authorization (e.g. depleted prepaid account=2C no data authori= zation)

* A Web portal using DNS spoofing might be in place.
* Firewalls may be in place blocking access to some services (e.g. no UDP/= TCP outbound=2C only HTTP).

As a result=2C I'm not convinced that t= his flowchart is useful enough in its current state. =3B =3B For ex= ample=2C the case of uanthorized access will result in gong down a unexpect= ed code path. =3B =3B Even if it is updated it would probably be be= tter to move it to an appendix so as not to interrupt the document flow.&nb= sp=3B It might even make sense to remove it altogether.

5.1.5. = =3B SIP Emergency Call Signaling

 =3B =3B SIP signaling capa= bilities [RFC3261] are mandated for end hosts.

 =3B =3B The = initial SIP signaling method is an INVITE. =3B The SIP INVITE
 = =3B =3B request MUST be constructed according to the requirements in Se= ction
 =3B =3B 9.2 [I-D.ietf-ecrit-phonebcp].

 =3B&nb= sp=3B Regarding callback behavior SIP UAs SHOULD place a globally routable<= br> =3B =3B URI in a Contact: header.

[BA] SIP UA's can't ob= tain GRUUs on their own. =3B Is there an ASP requirement
here? Also= =2C should there be a reference to a PSAP callback document?

5.2.2.&= nbsp=3B Location Determination and Location Configuration

 =3B&n= bsp=3B The ISP is responsible for location determination and exposes this =3B =3B information to the end points via location configuration= protocols.
 =3B =3B The considerations described in [I-D.ietf-e= crit-location-hiding-req]
 =3B =3B are applicable to this docume= nt.

 =3B =3B The ISP MUST support one of the LCPs described = in Section 6.5 of
 =3B =3B [I-D.ietf-ecrit-phonebcp]. =3B Th= e description in Section 6.5 and 6.6 of
 =3B =3B [I-D.ietf-ecrit= -phonebcp] regarding the interaction between the end
 =3B =3B de= vice and the LIS applies to this document.

 =3B =3B The inte= raction between the LIS at the ISP and the IAB is often
 =3B =3B= priorietary but the description in
 =3B =3B [I-D.winterbottom-g= eopriv-lis2lis-req] may be relevant to the reader.

[BA] Don't you me= an IAP and not IAB here?

6.2. =3B Securing Network Attachment in= NAA Cases


 =3B =3B 2) Null Authentication:

 = =3B =3B =3B =3B =3B In one case (e.g. =3B WiMAX) an EAP= method is performed. =3B However=2C no
 =3B =3B =3B&nbs= p=3B =3B credentials specific to either the server or the device or
=  =3B =3B =3B =3B =3B subscription are used as part of t= he authentication exchange. =3B An
 =3B =3B =3B =3B&= nbsp=3B example for this would be an EAP-TLS exchange with using the
&nb= sp=3B =3B =3B =3B =3B TLS_DH_anon (anonymous) ciphersuite.&= nbsp=3B

[BA] EAP-TLS [RFC 5216] does not support the negotiation of= the anonymous DH
ciphersuite. =3B At a minimum=2C the server needs = to provide a certificate.

 =3B =3B =3B =3B =3B = Alternatively=2C a publicly
 =3B =3B =3B =3B =3B ava= ilable static key for emergency access could be used. =3B In the
&nb= sp=3B =3B =3B =3B =3B latter case=2C the device would need = to be provisioned with the
 =3B =3B =3B =3B =3B appr= opriate emergency key for the IAP/ISP in advance. =3B In another
&nb= sp=3B =3B =3B =3B =3B case (e.g. =3B IEEE 802.11)=2C no= EAP method is used=2C so that empty
 =3B =3B =3B =3B&nb= sp=3B frames are transported during the over the air IEEE 802.1X
 = =3B =3B =3B =3B =3B exchange. =3B In this case the auth= entication state machine completes
 =3B =3B =3B =3B = =3B with no cryptographic keys being exchanged.

[BA] It is not clear= what it is being described here. =3B If WPA2 Enterprise
is used=2C = then EAP and an EAP method will need to be selected. =3B RFC 3748
do= es not support exchange of "empty" EAP frames.


7. =3B Securi= ty Considerations

 =3B =3B There are a couple of new vulnera= bilities raised with unauthenticated
 =3B =3B emergency services= in NASP/NAA cases since the PSAP operator will
 =3B =3B typical= ly not possess any identity information about the emergency
 =3B&nbs= p=3B call via the signaling path itself. =3B In countries where this =3B =3B functionality is used for GSM networks today this has lea= d to a
 =3B =3B significant amount of misuse.

[BA] I thin= k you need to discuss the NASP and NAA cases separately.
In the NASP ca= se=2C the user might have valid credentials with the ASP=2C
so that the = PSAP could obtain identify information. =3B In the NAA case=2C
you n= eed to separate unauthenticated from unauthorized access. =3B In
the= former case=2C there may be no NAI=2C but there may be other identifyinginfo (e.g. MAC address). =3B In the latter case there is an identity.=

 =3B =3B In the context of NAA=2C the IAP and the ISP will= probably want to make
 =3B =3B sure that the claimed emergency = caller indeed performs an emergency
 =3B =3B call rather than us= ing the network for other purposes=2C and thereby
 =3B =3B actin= g fraudulent by skipping any authentication=2C authorization and
 = =3B =3B accounting procedures. =3B By restricting access of the una= uthenticated
 =3B =3B emergency caller to the LoST server and th= e PSAP URI=2C traffic can be
 =3B =3B restricted only to emergen= cy calls. =3B This can be accomplished with
 =3B =3B traffic= separation. =3B The details=2C however=2C e.g. for using filtering=2C<= br> =3B =3B depend on the deployed ISP architecture and are beyond = the scope of
 =3B =3B this document.

 =3B =3B We = only illustrate a possible model. =3B If the ISP runs its own LoST
&= nbsp=3B =3B server=2C it would maintain an access control list includin= g all IP
 =3B =3B addresses contained in responses returned by t= he LoST server=2C as well
 =3B =3B as the LoST server itself.&nb= sp=3B (It may need to translate the domain
 =3B =3B names return= ed to IP addresses and hope that the resolution captures
 =3B = =3B all possible DNS responses.) =3B Since the media destination addres= ses
 =3B =3B are not predictable=2C the ISP also has to provide = a SIP outbound proxy
 =3B =3B so that it can determine the media= addresses and add those to the
 =3B =3B filter list.

[BA= ] There are some very challenging operational problems here that you
nee= d to discuss in more depth. =3B I would recommend that this section be reviewed by operators=2C to ensure that the advice is implementable.Some concerns:

1. DNS spoofing. =3B Many 802.11 hotspots use we= b portals today along
with DNS spoofing. =3B This will block any eme= rgency calling device
without a web browser=2C create delays for those = with a browser=2C and
may cause certificate or DNSSEC validation failure= s within VOIP
clients.

2. ISP operation of a SIP outbound proxy = configuration. =3B This doesn't
seem implementable to me. =3B Ge= tting a naive user to change
their SIP outbound proxy configuration to m= ake an emergency call is
time consuming and likely to consume valuable t= ime in an emergency.
There are SIP clients that will require SIP over TL= S and may not
have trust anchors configured for the ISP SIP proxy. = =3B Overall=2C an
ISP taking this on will be challenged to provide tech = support to
non-customers in potentially emergent situations. =3B Do = we really
think this is a viable approach?

3. Firewall configura= tions. =3B
Operators will often have concerns about opening generic= holes
in the firewall (e.g. opening a hole for traffic to destination =
ports 5060/5061). =3B To ensure that traffic is actually being used=
for emergency purposes=2C deep packet inspection may be required. = =3B
But what happens if the traffic is encrypted (e.g. SIP over TLS)? <= br>
= --_bef81b3f-d0da-4286-8f06-96bd977315a6_-- From Martin.Thomson@commscope.com Sun Jul 10 17:56:05 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A22221F8702 for ; Sun, 10 Jul 2011 17:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFCkmTCb5rAx for ; Sun, 10 Jul 2011 17:56:04 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 4140E21F86B9 for ; Sun, 10 Jul 2011 17:56:03 -0700 (PDT) X-AuditID: 0a0404e8-b7baaae0000009ea-24-4e1a4a2ff191 Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id 8E.38.02538.F2A4A1E4; Sun, 10 Jul 2011 19:56:15 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.159.2; Sun, 10 Jul 2011 19:57:00 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Mon, 11 Jul 2011 08:56:57 +0800 From: "Thomson, Martin" To: Hannes Tschofenig , "James M. Polk" Date: Mon, 11 Jul 2011 08:57:20 +0800 Thread-Topic: [Ecrit] Device Identity in PIDF-LO (from draft-ietf-ecrit-data-only-ea-01 and SIP Location Conveyance) Thread-Index: Acw84njF/FOXOidgTyC4q6OIzBtlTgCgnYqg Message-ID: <8B0A9FCBB9832F43971E38010638454F040B419CB3@SISPE7MB1.commscope.com> References: <6D0B17CC-6F5C-4C69-9248-C9E94493E8E2@gmx.net> <201107072000.p67K05Lb014503@mtv-core-1.cisco.com> <2CB5DAFD-7732-4F69-8D4D-D54F69FF49D8@gmx.net> In-Reply-To: <2CB5DAFD-7732-4F69-8D4D-D54F69FF49D8@gmx.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: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Device Identity in PIDF-LO (from draft-ietf-ecrit-data-only-ea-01 and SIP Location Conveyance) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 00:56:05 -0000 On 2011-07-08 at 06:13:20, Hannes Tschofenig wrote: >=20 > On Jul 7, 2011, at 11:00 PM, James M. Polk wrote: >=20 > > , does that mean you can't use a mac: URI? There's gotta be one > defined already as a deviceID within the presence docs. I think I=20 > remember RFC 3856 referring to it when discussing layer 2 devices like=20 > cellphones. It wasn't 3856, it was 4474. And that has some invalid examples. But then= , there are plenty of those about. =20 > It would be great if someone has defined a URI scheme for this purpose=20 > already. I have not seen it. > If we have to define one fine as well. I did a little asking around on that point. The short answer: "woe to he w= ho tries to register a URI scheme". There are all sorts of problems to overcome if you define the new scheme. = MAC, EUI-48, vs. EUI-64; urn:mac:... or just mac:...; URI parameters y/n; .= .. Easier to avoid the problem altogether. It's only an example. Fix the exa= mple. --Martin From bernard_aboba@hotmail.com Sun Jul 10 19:43:22 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 062A421F865E for ; Sun, 10 Jul 2011 19:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GOEZ-ZB399d for ; Sun, 10 Jul 2011 19:43:19 -0700 (PDT) Received: from blu0-omc3-s38.blu0.hotmail.com (blu0-omc3-s38.blu0.hotmail.com [65.55.116.113]) by ietfa.amsl.com (Postfix) with ESMTP id 6567121F865C for ; Sun, 10 Jul 2011 19:43:19 -0700 (PDT) Received: from BLU152-W36 ([65.55.116.74]) by blu0-omc3-s38.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 10 Jul 2011 19:43:19 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_8e0699d2-8279-4dde-bb4e-79a70123ed1d_" X-Originating-IP: [98.203.198.61] From: Bernard Aboba To: Date: Sun, 10 Jul 2011 19:43:18 -0700 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 11 Jul 2011 02:43:19.0361 (UTC) FILETIME=[4AFAD310:01CC3F74] Subject: Re: [Ecrit] Unauthenticated access review -02 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 02:43:22 -0000 --_8e0699d2-8279-4dde-bb4e-79a70123ed1d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In general=2C I'd suggest that there are a number of very challenging opera= tional issues within the unauthenticated/unauthorized network access scenar= io: a. The state of Hotspot access. While it's not the job of this document to= provide "best practice network engineering" recommendations to hotspot ope= rators=2C today's realities are sobering.=20 Few hotspot networks support Open Access with no web portal=2C or even WPA/= WPA2 in any form (PSK or Enterprise (EAP)). Instead=2C they typically only = allow DNS and HTTP requests prior to feeding the Web portal monsta=2C and D= NS A RR requests are responded to with the address of the portal. If your = device doesn't have a browser=2C good luck. If it does have a browser (e.g= . a smartphone)=2C feeding the monsta to gain access to the Internet is ann= oying at best in a normal situation=3B in an emergency=2C it will feel lik= e a twisted game of "Minute to Win It" with a life on the line. The typical= Web portal/DNS spoofing installation wreaks havoc with=20 applications in a number of ways=2C so even when you obtain access to the I= nternet there may be problems. Prior to feeding the monsta=2C applications= using UDP will lose packets and back off their retransmission timers=2C ca= using delays. Applications utilizing TLS will be confused by spoofed DNS = responses and certificates that may will not match the requested FQDN=2C re= sulting in error messages. Restoring your VOIP application to a less befu= ddled state may require you to kill and then restart it. Let's say you get on the network and get your VOIP application up and runni= ng so you can call an emergency number. The typical access point will not = support DHCP-based location or LOST configuration as a server (for users wh= o request it) or as a DHCP location client (to obtain location from the ups= tream provider). The replacement cycle of hotspot networks is quite long = so many of these networks still support IEEE 802.11b (not a=2C g=2C or n) a= nd have not been upgraded since the early part of this decade. If the hot= spot operator or their upstream provider does not support HELD=2C the most = likely source of location configuration is probably a location API (like th= e W3C location API) which will query a "location-based service" (probably a= hard-wired service that isn't warranted for emergency use). So you may n= ot be able to obtain a reliable location=20 automatically and may have to enter it manually. Yet more delays while=20 you fumble some more. =20 Some recommendations that might help: 1. Support for WPA2 in some form. Most APs can do this=2C possibly as a "v= irtual AP" so that you don't have to make a (likely to be ignored) recommen= dation to disable the portal monsta=2C just to provide a way around it to m= ake emergency access more viable. =20 2. Support for DHCP/LoST configuration in the DHCP server built into the AP= . Support for acting as a DHCP location client to the upstream provider to= obtain location=2C or if that fails=2C making a query to a "location based= service". =20 b. The fraud prevention problem. Assuming that the portal monsta issues = are dealt with=2C the next hurdle is fraud prevention on non-hotspot (e.g. = carrier) networks. In a situation where network access is unauthenticated = or unauthorized=2C it will be challenging to enable access to arbitrary eme= rgency services. Operators will typically not feel comfortable punching ho= les in the firewall to allow traffic to flow to a generic source address an= d a destination port. Doing deep packet inspection will not be straightfor= ward. What if the traffic is encrypted (e.g. SIP over TLS)? Blocking prop= rietary protocols the DPI device can't decrypt or doesn't understand may no= t be an option either (for network neutrality or other legal/political reas= ons). =20 My conclusion is that the (only?) viable solution may be for the carrier to= run emergency services themselves and provide applications that work with = those services on their devices. However=2C unless the applications suppo= rt multiple carriers=2C this will not solve the problem for roaming devices= . =20 From: bernard_aboba@hotmail.com To: ecrit@ietf.org Date: Sun=2C 10 Jul 2011 16:05:05 -0700 Subject: Re: [Ecrit] Unauthenticated access review -02 Here is my review.=20 Summary ----------- =20 This document has improved but there are still some major issues. An=20 important use case (unauthorized network access) does not appear to be=20 covered=2C and the operational implications of enabling unauthenticated or unauthorized emergency access have not been explored deeply enough. My re= commendation is that operators be recruited to review this document.=20 Specific comments:=20 1. Introduction Summoning police=2C the fire department or an ambulance in emergencies is one of the fundamental and most-valued functions of the telephone. As telephone functionality moves from circuit-switched telephony to Internet telephony=2C its users rightfully expect that this core functionality will continue to work at least as well as it has for the older technology. New devices and services are being made available that could be used to make a request for help=2C which are not traditional telephones=2C and users are increasingly expecting them to be used to place emergency calls. [BA] It would be useful to (briefly) discuss the existing functionality for emergency calling with Non-Service Initialized (NSI) devices here. We distinguish between three conditions: No Access Authentication (NAA): In the NAA case=2C the emergency caller does not posses valid credentials for the access network. This includes the case where the access network allows pay-per- use=2C as is common for wireless hotspots=2C but there is insufficien= t time to enter credit card details and other registration information required for access. It also covers all cases where either no credentials are available at all=2C or the available credentials do not work for the given IAP/ISP. As a result=2C the NAA case basically combines the below NASP and ZBP cases=2C but at the IAP/ISP level. Support for emergency call handling in the NAA case is subject to the local policy of the ISP. Such policy may vary substantially between ISPs and typically depends on external factors that are not under the ISP control. [BA] This does not appear to cover the case of lack of network access=20 authorization. For example=2C a user might have an account=2C but have=20 depleted their prepaid account=2C or perhaps they are authorized only for voice=2C but not data. Note: At the time of writing there is no regulation in place that demands the functionality described in this memo. SDOs have started their work on this subject in a proactive fashion in the anticipation that national regulation will demand it for a subset of network environments. [BA] This should also stated earlier=2C such in the abstract. There are also indications that the functionality of unauthenticated emergency calls (called SIM-less calls) in today's cellular system in certain countries leads to a fair amount of hoax or test calls. This causes overload situations at PSAPs which is considered harmful to the overall availability and reliability of emergency services. As an example=2C Federal Office of Communications (OFCOM=2C Switzerland) provided statistics about emergency (112) calls in Switzerland from Jan. 1997 to Nov. 2001. Switzerland did not offer SIM-less emergency calls except for almost a month in July 2000 where a significant increase in hoax and test calls was reported. As a consequence=2C the functionality was disabled again. More details can be found in the panel presentations of the 3rd SDO Emergency Services Workshop [esw07]. [BA] I recommend that these paragraphs be moved up earlier=2C right after a basic description of NSI functionality. Figure 1 compiles the basic logic taking place during network entry for requesting an emergency service and shows the interrelation between the three conditions described in the above section. +-----Y |Start| `...../ | | Are credentials | for network attachment | available? | NO v YES +----------------------------+ | | | | V v .............. ................ | Idle: Wait | |Execute | | for ES Call| |LLA Procedures| | Initiation | "--------------' "------------' | Is | +---------->O emergency | | | Is ASP service | NO +-----Y | | configured? network +--->| End | | +---------------+ attachment| `...../ | YES | | NO possible? | | | | v | v v +------------+ | +------------+ +------------+ | Execute | | | Execute | | Execute | | NAA |--------+ | Phone BCP | | NASP | | Procedures | | Procedures | | Procedures | +------------+ +------------+ +------------+ Authorization for| | Emergency Call? | | +--------------+ v | NO | YES +-----Y | | | Done| v v `...../ +------------+ +------------+ | Execute | | Execute | | ZBP | | Phone BCP | | Procedures | | Procedures | +------------+ +------------+ | | | | v v +-----Y +-----Y | Done| | Done| `...../ `...../ Abbreviations: LLA: Link Layer Attachment ES: Emergency Services Figure 1: Flow Diagram [BA] The reality is considerably more complicated that than this.=20 For example: * network access credentials may be available=2C but not authorization (e.g= . depleted prepaid account=2C no data authorization) * A Web portal using DNS spoofing might be in place.=20 * Firewalls may be in place blocking access to some services (e.g. no UDP/T= CP outbound=2C only HTTP).=20 As a result=2C I'm not convinced that this flowchart is useful enough in it= s current state. For example=2C the case of uanthorized access will resul= t in gong down a unexpected code path. Even if it is updated it would pro= bably be better to move it to an appendix so as not to interrupt the docume= nt flow. It might even make sense to remove it altogether. 5.1.5. SIP Emergency Call Signaling SIP signaling capabilities [RFC3261] are mandated for end hosts. The initial SIP signaling method is an INVITE. The SIP INVITE request MUST be constructed according to the requirements in Section 9.2 [I-D.ietf-ecrit-phonebcp]. Regarding callback behavior SIP UAs SHOULD place a globally routable URI in a Contact: header. [BA] SIP UA's can't obtain GRUUs on their own. Is there an ASP requirement here? Also=2C should there be a reference to a PSAP callback document? 5.2.2. Location Determination and Location Configuration The ISP is responsible for location determination and exposes this information to the end points via location configuration protocols. The considerations described in [I-D.ietf-ecrit-location-hiding-req] are applicable to this document. The ISP MUST support one of the LCPs described in Section 6.5 of [I-D.ietf-ecrit-phonebcp]. The description in Section 6.5 and 6.6 of [I-D.ietf-ecrit-phonebcp] regarding the interaction between the end device and the LIS applies to this document. The interaction between the LIS at the ISP and the IAB is often priorietary but the description in [I-D.winterbottom-geopriv-lis2lis-req] may be relevant to the reader. [BA] Don't you mean IAP and not IAB here? 6.2. Securing Network Attachment in NAA Cases 2) Null Authentication: In one case (e.g. WiMAX) an EAP method is performed. However=2C no credentials specific to either the server or the device or subscription are used as part of the authentication exchange. An example for this would be an EAP-TLS exchange with using the TLS_DH_anon (anonymous) ciphersuite. =20 [BA] EAP-TLS [RFC 5216] does not support the negotiation of the anonymous D= H ciphersuite. At a minimum=2C the server needs to provide a certificate.=20 Alternatively=2C a publicly available static key for emergency access could be used. In the latter case=2C the device would need to be provisioned with the appropriate emergency key for the IAP/ISP in advance. In another case (e.g. IEEE 802.11)=2C no EAP method is used=2C so that empty frames are transported during the over the air IEEE 802.1X exchange. In this case the authentication state machine completes with no cryptographic keys being exchanged. [BA] It is not clear what it is being described here. If WPA2 Enterprise is used=2C then EAP and an EAP method will need to be selected. RFC 3748 does not support exchange of "empty" EAP frames. 7. Security Considerations There are a couple of new vulnerabilities raised with unauthenticated emergency services in NASP/NAA cases since the PSAP operator will typically not possess any identity information about the emergency call via the signaling path itself. In countries where this functionality is used for GSM networks today this has lead to a significant amount of misuse. [BA] I think you need to discuss the NASP and NAA cases separately.=20 In the NASP case=2C the user might have valid credentials with the ASP=2C so that the PSAP could obtain identify information. In the NAA case=2C you need to separate unauthenticated from unauthorized access. In the former case=2C there may be no NAI=2C but there may be other identifyin= g info (e.g. MAC address). In the latter case there is an identity.=20 In the context of NAA=2C the IAP and the ISP will probably want to make sure that the claimed emergency caller indeed performs an emergency call rather than using the network for other purposes=2C and thereby acting fraudulent by skipping any authentication=2C authorization and accounting procedures. By restricting access of the unauthenticated emergency caller to the LoST server and the PSAP URI=2C traffic can be restricted only to emergency calls. This can be accomplished with traffic separation. The details=2C however=2C e.g. for using filtering= =2C depend on the deployed ISP architecture and are beyond the scope of this document. We only illustrate a possible model. If the ISP runs its own LoST server=2C it would maintain an access control list including all IP addresses contained in responses returned by the LoST server=2C as well as the LoST server itself. (It may need to translate the domain names returned to IP addresses and hope that the resolution captures all possible DNS responses.) Since the media destination addresses are not predictable=2C the ISP also has to provide a SIP outbound proxy so that it can determine the media addresses and add those to the filter list. [BA] There are some very challenging operational problems here that you need to discuss in more depth. I would recommend that this section=20 be reviewed by operators=2C to ensure that the advice is implementable. Some concerns: 1. DNS spoofing. Many 802.11 hotspots use web portals today along with DNS spoofing. This will block any emergency calling device=20 without a web browser=2C create delays for those with a browser=2C and may cause certificate or DNSSEC validation failures within VOIP clients.=20 2. ISP operation of a SIP outbound proxy configuration. This doesn't seem implementable to me. Getting a naive user to change their SIP outbound proxy configuration to make an emergency call is time consuming and likely to consume valuable time in an emergency. There are SIP clients that will require SIP over TLS and may not have trust anchors configured for the ISP SIP proxy. Overall=2C an ISP taking this on will be challenged to provide tech support to non-customers in potentially emergent situations. Do we really think this is a viable approach?=20 3. Firewall configurations. =20 Operators will often have concerns about opening generic holes=20 in the firewall (e.g. opening a hole for traffic to destination=20 ports 5060/5061). To ensure that traffic is actually being used=20 for emergency purposes=2C deep packet inspection may be required. =20 But what happens if the traffic is encrypted (e.g. SIP over TLS)?=20 =20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit = --_8e0699d2-8279-4dde-bb4e-79a70123ed1d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
In general=2C I'd suggest that there are a number of very challenging opera= tional issues within the unauthenticated/unauthorized network access scenar= io:

a. The state of Hotspot access. =3B While it's not the job o= f this document to provide "best practice network engineering" recommendati= ons to hotspot operators=2C today's realities are sobering.

Few hot= spot networks support Open Access with no web portal=2C or even WPA/WPA2 in= any form (PSK or Enterprise (EAP)). Instead=2C they typically only allow D= NS and HTTP requests prior to feeding the Web portal monsta=2C and DNS A RR= requests are responded to with the address of the portal. =3B If your = device doesn't have a browser=2C good luck. =3B If it does have a brows= er (e.g. a smartphone)=2C feeding the monsta to gain access to the Internet= is annoying at best in a normal situation=3B =3B in an emergency=2C it= will feel like a twisted game of "Minute to Win It" with a life on the lin= e. The typical Web portal/DNS spoofing installation wreaks havoc with=20 applications in a number of ways=2C so even when you obtain access to the I= nternet there may be problems. =3B Prior to feeding the monsta=2C appli= cations using UDP will lose packets and back off their retransmission timer= s=2C causing delays. =3B Applications =3B utilizing TLS will be con= fused by spoofed DNS responses and certificates that may will not match the= requested FQDN=2C resulting in error messages. =3B =3B Restoring y= our VOIP application to a less befuddled state may require you to kill and = then restart it.

Let's say you get on the network and get your VOIP = application up and running so you can call an emergency number. =3B The= typical access point will not support DHCP-based location or LOST configur= ation as a server (for users who request it) or as a DHCP location client (= to obtain location from the upstream provider). =3B =3B The replace= ment cycle of hotspot networks is quite long so many of these networks stil= l support IEEE 802.11b (not a=2C g=2C or n) and have not been upgraded sinc= e the early part of this decade. =3B =3B If the hotspot operator or= their upstream provider does not support HELD=2C the most likely source of= location configuration is probably a location API (like the W3C location A= PI) which will query a "location-based service" (probably a hard-wired serv= ice that isn't warranted for emergency use). =3B =3B So you may not= be able to obtain a reliable location=20 automatically and may have to enter it manually. =3B Yet more delays wh= ile=20 you fumble some more. =3B

Some recommendations that might help:=

1. Support for WPA2 in some form. =3B Most APs can do this=2C p= ossibly as a "virtual AP" so that you don't have to make a (likely to be ig= nored) recommendation to disable the portal monsta=2C just to provide a way= around it to make emergency access more viable.
 =3B
2. Support = for DHCP/LoST configuration in the DHCP server built into the AP. =3B S= upport for acting as a DHCP location client to the upstream provider to obt= ain location=2C or if that fails=2C making a query to a "location based ser= vice". =3B

b. =3B The fraud prevention problem. =3B&nbs= p=3B Assuming that the portal monsta issues are dealt with=2C the next hurd= le is fraud prevention on non-hotspot (e.g. carrier) networks. =3B In a= situation where network access is unauthenticated or unauthorized=2C it wi= ll be challenging to enable access to arbitrary emergency services. =3B= Operators will typically not feel comfortable punching holes in the firewa= ll to allow traffic to flow to a generic source address and a destination p= ort. =3B Doing deep packet inspection will not be straightforward. = =3B What if the traffic is encrypted (e.g. SIP over TLS)? =3B Blocking = proprietary protocols the DPI device can't decrypt or doesn't understand ma= y not be an option either (for network neutrality or other legal/political = reasons). =3B

My conclusion is that the (only?) viable solution= may be for the carrier to run emergency services themselves and provide ap= plications that work with those services on their devices.  =3B However= =2C unless the applications support multiple carriers=2C this will not solv= e the problem for roaming devices. =3B =3B



From: bernard_aboba@hotmail.com
To: ecrit@ietf.org<= br>Date: Sun=2C 10 Jul 2011 16:05:05 -0700
Subject: Re: [Ecrit] Unauthen= ticated access review -02

Here is my review.


Summary
-----------

=20 This document has improved but there are still some major issues. An=20 important use case (unauthorized network access) does not appear to be=20 covered=2C and the operational implications of enabling unauthenticated or unauthorized emergency access have not been explored deeply enough. = =3B My recommendation is that operators be recruited to review this documen= t.



Specific comments:




1. =3B Introduction

 = =3B =3B Summoning police=2C the fire department or an ambulance in emer= gencies
 =3B =3B is one of the fundamental and most-valued funct= ions of the telephone.
 =3B =3B As telephone functionality moves= from circuit-switched telephony to
 =3B =3B Internet telephony= =2C its users rightfully expect that this core
 =3B =3B function= ality will continue to work at least as well as it has for
 =3B = =3B the older technology. =3B New devices and services are being made =3B =3B available that could be used to make a request for help= =2C which are
 =3B =3B not traditional telephones=2C and users a= re increasingly expecting them
 =3B =3B to be used to place emer= gency calls.

[BA] It would be useful to (briefly) discuss the existi= ng functionality
for emergency calling with Non-Service Initialized (NSI= ) devices here.

 =3B =3B We distinguish between three condit= ions:

 =3B =3B No Access Authentication (NAA): =3B In th= e NAA case=2C the emergency
 =3B =3B =3B =3B =3B cal= ler does not posses valid credentials for the access network.
 =3B&n= bsp=3B =3B =3B =3B This includes the case where the access netw= ork allows pay-per-
 =3B =3B =3B =3B =3B use=2C as i= s common for wireless hotspots=2C but there is insufficient
 =3B&nbs= p=3B =3B =3B =3B time to enter credit card details and other re= gistration
 =3B =3B =3B =3B =3B information required= for access. =3B It also covers all cases where
 =3B =3B&nbs= p=3B =3B =3B either no credentials are available at all=2C or the a= vailable
 =3B =3B =3B =3B =3B credentials do not wor= k for the given IAP/ISP. =3B As a result=2C the
 =3B =3B&nbs= p=3B =3B =3B NAA case basically combines the below NASP and ZBP cas= es=2C but at
 =3B =3B =3B =3B =3B the IAP/ISP level.=  =3B Support for emergency call handling in the NAA
 =3B =3B=  =3B =3B =3B case is subject to the local policy of the ISP.&nb= sp=3B Such policy may
 =3B =3B =3B =3B =3B vary subs= tantially between ISPs and typically depends on external
 =3B = =3B =3B =3B =3B factors that are not under the ISP control.
=
[BA] This does not appear to cover the case of lack of network access <= br>authorization. For example=2C a user might have an account=2C but have <= br>depleted their prepaid account=2C or perhaps they are authorized onlyfor voice=2C but not data.

 =3B =3B Note: At the time of wr= iting there is no regulation in place that
 =3B =3B demands the = functionality described in this memo. =3B SDOs have started
 =3B=  =3B their work on this subject in a proactive fashion in the anticipat= ion
 =3B =3B that national regulation will demand it for a subse= t of network
 =3B =3B environments.

[BA] This should also= stated earlier=2C such in the abstract.

 =3B =3B There are = also indications that the functionality of unauthenticated
 =3B = =3B emergency calls (called SIM-less calls) in today's cellular system in =3B =3B certain countries leads to a fair amount of hoax or test= calls. =3B This
 =3B =3B causes overload situations at PSAP= s which is considered harmful to
 =3B =3B the overall availabili= ty and reliability of emergency services.

 =3B =3B As an exa= mple=2C Federal Office of Communications (OFCOM=2C Switzerland)
 =3B=  =3B provided statistics about emergency (112) calls in Switzerland fro= m
 =3B =3B Jan. 1997 to Nov. 2001. =3B Switzerland did not o= ffer SIM-less emergency
 =3B =3B calls except for almost a month= in July 2000 where a significant
 =3B =3B increase in hoax and = test calls was reported. =3B As a consequence=2C the
 =3B = =3B functionality was disabled again. =3B More details can be found in = the
 =3B =3B panel presentations of the 3rd SDO Emergency Servic= es Workshop
 =3B =3B [esw07].

[BA] I recommend that these= paragraphs be moved up earlier=2C right after
a basic description of NS= I functionality.

 =3B =3B Figure 1 compiles the basic logic = taking place during network entry
 =3B =3B for requesting an eme= rgency service and shows the interrelation
 =3B =3B between the = three conditions described in the above section.



 =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B +-----Y
 =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B |Start|
 =3B =3B =3B =3B =3B =3B&n= bsp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B `...../=
 =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B |<= br> =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B | Are= credentials
 =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B | for network attachment
 =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B | available?
 =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B |
 =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B NO =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B v =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B YES
 =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B +----------------------------+
 = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B | =3B =3B =3B =3B =3B =3B =3B&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B |
 =3B =3B =3B =3B =3B =3B =3B&n= bsp=3B =3B =3B =3B =3B | =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B |
 =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B V =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B v
 =3B =3B=  =3B =3B =3B =3B =3B .............. =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B ................
 =3B =3B =3B =3B&nb= sp=3B =3B =3B | Idle: Wait | =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B= |Execute =3B =3B =3B =3B =3B =3B |
 =3B&nbs= p=3B =3B =3B =3B =3B =3B | for ES Call| =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B |LLA Procedures|
 =3B =3B =3B =3B&= nbsp=3B =3B =3B | Initiation | =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B= "--------------'
 =3B =3B =3B =3B =3B =3B = =3B "------------' =3B =3B =3B =3B =3B =3B =3B&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B |
 =3B =3B =3B Is =3B =3B = =3B =3B =3B =3B =3B | =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B= +---------->=3BO
 =3B =3B =3B emergency | =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B | =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B | Is ASP
 =3B =3B =3B service&n= bsp=3B =3B | NO +-----Y =3B =3B =3B | =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B | configured? =3B =3B =3B network =3B =3B +--->=3B| End | = =3B =3B =3B | =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B +---------------+
 =3B =3B =3B a= ttachment| =3B =3B =3B `...../ =3B =3B =3B | = =3B =3B =3B =3B =3B =3B YES | =3B =3B =3B&n= bsp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B | NO
 =3B =3B =3B possible? | =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B | =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B | =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B |
&n= bsp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B v =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B | = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B= v =3B =3B =3B =3B =3B =3B =3B =3B =3B&= nbsp=3B =3B =3B =3B =3B v
 =3B =3B =3B = =3B =3B =3B =3B +------------+ =3B =3B =3B =3B&= nbsp=3B =3B =3B | =3B =3B =3B =3B +------------+&nb= sp=3B =3B =3B +------------+
 =3B =3B =3B =3B&nb= sp=3B =3B =3B | Execute =3B =3B =3B | =3B =3B&n= bsp=3B =3B =3B =3B =3B | =3B =3B =3B =3B | = Execute =3B =3B =3B | =3B =3B =3B | Execute =3B=  =3B =3B |
 =3B =3B =3B =3B =3B =3B = =3B | NAA =3B =3B =3B =3B =3B =3B =3B |--------= + =3B =3B =3B =3B | Phone BCP =3B | =3B =3B&nbs= p=3B | NASP =3B =3B =3B =3B =3B =3B |
 =3B&n= bsp=3B =3B =3B =3B =3B =3B | Procedures | =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B | Procedures | =3B =3B =3B | Procedures |
&= nbsp=3B =3B =3B =3B =3B =3B =3B +------------+ = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B +------------+ =3B =3B =3B +----------= --+
 =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B Authorization for| = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B |
 =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B Emergency Call? =3B | =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B |
 =3B =3B =3B =3B =3B =3B =3B&n= bsp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B= +--------------+ =3B =3B =3B =3B =3B =3B =3B&n= bsp=3B =3B =3B =3B =3B =3B =3B =3B v
 = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B | NO =3B =3B&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B | YES = =3B =3B =3B =3B =3B =3B =3B =3B +-----Y
&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B | =3B =3B&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B | =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B | Done|
 =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B v =3B =3B =3B =3B =3B&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B v =3B&n= bsp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B `...../
 =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B +------------+ =3B +------------+
 = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B | = Execute =3B =3B =3B | =3B | Execute =3B =3B =3B= |
 =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B | ZBP =3B =3B =3B =3B =3B =3B =3B |&nb= sp=3B | Phone BCP =3B |
 =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B | Procedures | =3B | Procedures | =3B =3B =3B =3B =3B =3B =3B =3B =3B&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B +------------+ =3B +------------+
 =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B | =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B |
 =3B&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B | =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B |
 =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B v&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B v
 =3B =3B =3B =3B =3B&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B =3B +-----= Y =3B =3B =3B =3B =3B =3B =3B +-----Y
 = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B | Done| =3B =3B =3B =3B = =3B =3B =3B | Done|
 =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B `...../=  =3B =3B =3B =3B =3B =3B =3B `...../

&nb= sp=3B =3B Abbreviations:
 =3B =3B =3B =3B LLA: Link = Layer Attachment
 =3B =3B =3B =3B ES: Emergency Services=

 =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B Figure 1: Flow = Diagram

[BA] The reality is considerably more complicated that than = this.
For example:

* network access credentials may be available= =2C but not authorization (e.g. depleted prepaid account=2C no data authori= zation)

* A Web portal using DNS spoofing might be in place.
* Firewalls may be in place blocking access to some services (e.g. no UDP/= TCP outbound=2C only HTTP).

As a result=2C I'm not convinced that t= his flowchart is useful enough in its current state. =3B =3B For ex= ample=2C the case of uanthorized access will result in gong down a unexpect= ed code path. =3B =3B Even if it is updated it would probably be be= tter to move it to an appendix so as not to interrupt the document flow.&nb= sp=3B It might even make sense to remove it altogether.

5.1.5. = =3B SIP Emergency Call Signaling

 =3B =3B SIP signaling capa= bilities [RFC3261] are mandated for end hosts.

 =3B =3B The = initial SIP signaling method is an INVITE. =3B The SIP INVITE
 = =3B =3B request MUST be constructed according to the requirements in Se= ction
 =3B =3B 9.2 [I-D.ietf-ecrit-phonebcp].

 =3B&nb= sp=3B Regarding callback behavior SIP UAs SHOULD place a globally routable<= br> =3B =3B URI in a Contact: header.

[BA] SIP UA's can't ob= tain GRUUs on their own. =3B Is there an ASP requirement
here? Also= =2C should there be a reference to a PSAP callback document?

5.2.2.&= nbsp=3B Location Determination and Location Configuration

 =3B&n= bsp=3B The ISP is responsible for location determination and exposes this =3B =3B information to the end points via location configuration= protocols.
 =3B =3B The considerations described in [I-D.ietf-e= crit-location-hiding-req]
 =3B =3B are applicable to this docume= nt.

 =3B =3B The ISP MUST support one of the LCPs described = in Section 6.5 of
 =3B =3B [I-D.ietf-ecrit-phonebcp]. =3B Th= e description in Section 6.5 and 6.6 of
 =3B =3B [I-D.ietf-ecrit= -phonebcp] regarding the interaction between the end
 =3B =3B de= vice and the LIS applies to this document.

 =3B =3B The inte= raction between the LIS at the ISP and the IAB is often
 =3B =3B= priorietary but the description in
 =3B =3B [I-D.winterbottom-g= eopriv-lis2lis-req] may be relevant to the reader.

[BA] Don't you me= an IAP and not IAB here?

6.2. =3B Securing Network Attachment in= NAA Cases


 =3B =3B 2) Null Authentication:

 = =3B =3B =3B =3B =3B In one case (e.g. =3B WiMAX) an EAP= method is performed. =3B However=2C no
 =3B =3B =3B&nbs= p=3B =3B credentials specific to either the server or the device or
=  =3B =3B =3B =3B =3B subscription are used as part of t= he authentication exchange. =3B An
 =3B =3B =3B =3B&= nbsp=3B example for this would be an EAP-TLS exchange with using the
&nb= sp=3B =3B =3B =3B =3B TLS_DH_anon (anonymous) ciphersuite.&= nbsp=3B

[BA] EAP-TLS [RFC 5216] does not support the negotiation of= the anonymous DH
ciphersuite. =3B At a minimum=2C the server needs = to provide a certificate.

 =3B =3B =3B =3B =3B = Alternatively=2C a publicly
 =3B =3B =3B =3B =3B ava= ilable static key for emergency access could be used. =3B In the
&nb= sp=3B =3B =3B =3B =3B latter case=2C the device would need = to be provisioned with the
 =3B =3B =3B =3B =3B appr= opriate emergency key for the IAP/ISP in advance. =3B In another
&nb= sp=3B =3B =3B =3B =3B case (e.g. =3B IEEE 802.11)=2C no= EAP method is used=2C so that empty
 =3B =3B =3B =3B&nb= sp=3B frames are transported during the over the air IEEE 802.1X
 = =3B =3B =3B =3B =3B exchange. =3B In this case the auth= entication state machine completes
 =3B =3B =3B =3B = =3B with no cryptographic keys being exchanged.

[BA] It is not clear= what it is being described here. =3B If WPA2 Enterprise
is used=2C = then EAP and an EAP method will need to be selected. =3B RFC 3748
do= es not support exchange of "empty" EAP frames.


7. =3B Securi= ty Considerations

 =3B =3B There are a couple of new vulnera= bilities raised with unauthenticated
 =3B =3B emergency services= in NASP/NAA cases since the PSAP operator will
 =3B =3B typical= ly not possess any identity information about the emergency
 =3B&nbs= p=3B call via the signaling path itself. =3B In countries where this =3B =3B functionality is used for GSM networks today this has lea= d to a
 =3B =3B significant amount of misuse.

[BA] I thin= k you need to discuss the NASP and NAA cases separately.
In the NASP ca= se=2C the user might have valid credentials with the ASP=2C
so that the = PSAP could obtain identify information. =3B In the NAA case=2C
you n= eed to separate unauthenticated from unauthorized access. =3B In
the= former case=2C there may be no NAI=2C but there may be other identifyinginfo (e.g. MAC address). =3B In the latter case there is an identity.=

 =3B =3B In the context of NAA=2C the IAP and the ISP will= probably want to make
 =3B =3B sure that the claimed emergency = caller indeed performs an emergency
 =3B =3B call rather than us= ing the network for other purposes=2C and thereby
 =3B =3B actin= g fraudulent by skipping any authentication=2C authorization and
 = =3B =3B accounting procedures. =3B By restricting access of the una= uthenticated
 =3B =3B emergency caller to the LoST server and th= e PSAP URI=2C traffic can be
 =3B =3B restricted only to emergen= cy calls. =3B This can be accomplished with
 =3B =3B traffic= separation. =3B The details=2C however=2C e.g. for using filtering=2C<= br> =3B =3B depend on the deployed ISP architecture and are beyond = the scope of
 =3B =3B this document.

 =3B =3B We = only illustrate a possible model. =3B If the ISP runs its own LoST
&= nbsp=3B =3B server=2C it would maintain an access control list includin= g all IP
 =3B =3B addresses contained in responses returned by t= he LoST server=2C as well
 =3B =3B as the LoST server itself.&nb= sp=3B (It may need to translate the domain
 =3B =3B names return= ed to IP addresses and hope that the resolution captures
 =3B = =3B all possible DNS responses.) =3B Since the media destination addres= ses
 =3B =3B are not predictable=2C the ISP also has to provide = a SIP outbound proxy
 =3B =3B so that it can determine the media= addresses and add those to the
 =3B =3B filter list.

[BA= ] There are some very challenging operational problems here that you
nee= d to discuss in more depth. =3B I would recommend that this section be reviewed by operators=2C to ensure that the advice is implementable.Some concerns:

1. DNS spoofing. =3B Many 802.11 hotspots use we= b portals today along
with DNS spoofing. =3B This will block any eme= rgency calling device
without a web browser=2C create delays for those = with a browser=2C and
may cause certificate or DNSSEC validation failure= s within VOIP
clients.

2. ISP operation of a SIP outbound proxy = configuration. =3B This doesn't
seem implementable to me. =3B Ge= tting a naive user to change
their SIP outbound proxy configuration to m= ake an emergency call is
time consuming and likely to consume valuable t= ime in an emergency.
There are SIP clients that will require SIP over TL= S and may not
have trust anchors configured for the ISP SIP proxy. = =3B Overall=2C an
ISP taking this on will be challenged to provide tech = support to
non-customers in potentially emergent situations. =3B Do = we really
think this is a viable approach?

3. Firewall configura= tions. =3B
Operators will often have concerns about opening generic= holes
in the firewall (e.g. opening a hole for traffic to destination =
ports 5060/5061). =3B To ensure that traffic is actually being used=
for emergency purposes=2C deep packet inspection may be required. = =3B
But what happens if the traffic is encrypted (e.g. SIP over TLS)? <= br>

_______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit
= --_8e0699d2-8279-4dde-bb4e-79a70123ed1d_-- From Martin.Thomson@commscope.com Sun Jul 10 23:27:50 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D7E21F89A3 for ; Sun, 10 Jul 2011 23:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+ceKCx3rjYt for ; Sun, 10 Jul 2011 23:27:50 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id DCCD421F88D5 for ; Sun, 10 Jul 2011 23:27:49 -0700 (PDT) X-AuditID: 0a0404e8-b7baaae0000009ea-ff-4e1a97f1a708 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id 81.5C.02538.1F79A1E4; Mon, 11 Jul 2011 01:28:01 -0500 (CDT) Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 11 Jul 2011 01:28:46 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Mon, 11 Jul 2011 14:28:44 +0800 From: "Thomson, Martin" To: Hannes Tschofenig Date: Mon, 11 Jul 2011 14:28:42 +0800 Thread-Topic: [Ecrit] Unauthenticated access review Thread-Index: Acw7UVmy5M7b+3JTRyi8o8P9qGa1ygEG+EUQ Message-ID: <8B0A9FCBB9832F43971E38010638454F040B419D3D@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F040B26CBA8@SISPE7MB1.commscope.com> <5A5CA3CF-3853-472D-A0A1-1F4799EB6459@gmx.net> In-Reply-To: <5A5CA3CF-3853-472D-A0A1-1F4799EB6459@gmx.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: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: ecrit Subject: Re: [Ecrit] Unauthenticated access review X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 06:27:50 -0000 Hi Hannes, On 2011-07-06 at 06:15:51, Hannes Tschofenig wrote: > Hi Martin, >=20 > thank you for your review comments. >=20 > On Jun 29, 2011, at 9:37 AM, Thomson, Martin wrote: >=20 > > -02 is a considerable improvement over earlier iterations of this > work. > > > Glad to hear that. >=20 > > I'm a little concerned about the suggested flow for NAA,=20 > > specifically > the potential for abuse and what options are available for an operator. > The security considerations discusses this issue reasonably well, but=20 > it takes a fairly weak position, preferring to shunt the problem than=20 > deal with it outright. >=20 > The No Access Authentication (NAA) case is indeed interesting and the=20 > current definition covers the case where the emergency caller does not=20 > possess valid credential for network access when those are needed for=20 > getting access to the Internet. > In many cases today a host is able to use the Internet without having=20 > to go through a network access authentication procedure. These free=20 > hotspots are not really discussed in that section and wouldn't really=20 > present a problem as such. >=20 > Having said that the security consideration section, as you state=20 > indeed discusses the issue and proposed one possible solution approach. > The main issue I believe is that the LoST server can be provisioned to=20 > return any ESRP URI back. Quite naturally that URI may not be the URI=20 > of the PSAP but it may just get the call closer to the PSAP. Hence, if=20 > the LoST server contains a ESRP URI that points to a VSP/ASP someone=20 > then the ISP would configure the firewall setting in such a way that=20 > it would essentially allow communication with that arbitrary VSP/ASP. I actually don't think that you are saying the same thing. But I could jus= t be a little confused. When a LoST server identifies something, that thing becomes an ESRP, regard= less of who operates it. Talking about a VSP/ASP being identified by a LoS= T server is very confusing. When a LoST server identifies an ESRP, then it's not arbitrary. > > > > From the perspective of an operator, the potential for abuse is > increased when they have to permit signaling to an arbitrary ASP. > Permitting the path to anything other than NASP from NAA reduces an=20 > operator's ability to constrain network access. In NASP, the ISP need=20 > only provide access to a LIS, a LoST server and the emergency services=20 > network. Normal call procedures are great, but it is a lot harder to=20 > constrain access when you can't predict what ASP a device is going to=20 > use. > > >=20 > So, there is nothing wrong with the currently presented solution but=20 > it maybe we need to highlight a bit more that an ISP may want to make=20 > sure that the entries in the LoST server actually point to ESRPs=20 > belonging to the ESINet for that specific region if the described=20 > threat is a concern. There is something wrong with the currently presented solution. It require= s that the ISP permit access to arbitrary ASPs. For NAA, the caller gains limited access to the network, then they follow -= phone-bcp, which uses their normal ASP. The ISP cannot possibly identify c= ommunications directed at this (arbitrary) ASP as being permitted. > Since we demand LoST server discovery using DHCP I don't see a problem=20 > with the ISP ensuring that the presented information is indeed what is=20 > desired (unless there is no way to configure the end host with a DHCP=20 > server; a discussion we also had in the past ....). Requiring LoST discovery is a necessary condition. That bit is good. (and= let's pretend that the discussion was fruitfully concluded...) > > Does this work better for Section 4? > > > >>>> [...] > > <<< > > >=20 > I am not sure I understand this comment. Is this a text proposal?=20 > Would it replace the text in Section 4 or is it additional text? Text proposal for replacement. =20 I was struggling with the definition and it was the last paragraph that mad= e it possible to understand it. I tried shuffling contents, and the above = is what came out. =20 > > > > Section 5 > > > > Section 5 duplicates a lot of the recommendations from phone-bcp. =20 > > In > fact, it's difficult to identify how this draft differs from phone-bcp. > It should only be necessary to call out the points of divergence here=20 > (which are few). For instance, the ESRP section could just say=20 > "follow [phone-bcp]". Even the ISP/IAP section could say the same,=20 > with a possible reference to the NAA section regarding constrained access= . > > > > What is missing from 5.1.2 is the SIP-based discovery of the ESRP - > if the End Host is sending signaling straight to the ESRP, it will=20 > probably have to use RFC 3263. > > > > >=20 > This is indeed a matter of taste. Referencing Phone BCP and to tell=20 > what is different is one option. Another one is presented in this=20 > document - we spell out what needs to be done for the presented case.=20 > I believe that this is shorter and easier to understand. I found it more confusing. While it is easier to follow than -phone-bcp, i= t's hard to identify what is different. Can I request that you at least su= mmarize the differences. > I don't think that a reference to RFC 3263 is needed. The URI scheme=20 > of the ESRP URI will determine what discovery mechanisms is to be=20 > used. We aren't going to reference XMPP specs here either although one=20 > could image that a LoST response may contain such a URI. Good point. You don't need to reference 3263 specifically, but note that s= erver discovery is going to be involved. Such a thing can be missed in set= ting up a network. From bernard_aboba@hotmail.com Mon Jul 11 00:28:55 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8404921F8946 for ; Mon, 11 Jul 2011 00:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdMRzDel86+o for ; Mon, 11 Jul 2011 00:28:55 -0700 (PDT) Received: from blu0-omc2-s34.blu0.hotmail.com (blu0-omc2-s34.blu0.hotmail.com [65.55.111.109]) by ietfa.amsl.com (Postfix) with ESMTP id 0023621F8927 for ; Mon, 11 Jul 2011 00:28:54 -0700 (PDT) Received: from BLU152-W52 ([65.55.111.73]) by blu0-omc2-s34.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Jul 2011 00:28:54 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_c74f25b0-ce50-41bb-8551-3cf9a63e7e9f_" X-Originating-IP: [98.203.198.61] From: Bernard Aboba To: , Hannes Tschofenig Date: Mon, 11 Jul 2011 00:28:53 -0700 Importance: Normal In-Reply-To: <8B0A9FCBB9832F43971E38010638454F040B419D3D@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F040B26CBA8@SISPE7MB1.commscope.com>, <5A5CA3CF-3853-472D-A0A1-1F4799EB6459@gmx.net>, <8B0A9FCBB9832F43971E38010638454F040B419D3D@SISPE7MB1.commscope.com> MIME-Version: 1.0 X-OriginalArrivalTime: 11 Jul 2011 07:28:54.0693 (UTC) FILETIME=[306EFD50:01CC3F9C] Cc: ecrit@ietf.org Subject: Re: [Ecrit] Unauthenticated access review X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 07:28:55 -0000 --_c74f25b0-ce50-41bb-8551-3cf9a63e7e9f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Martin said: > There is something wrong with the currently presented solution. It requi= res that the ISP permit access to arbitrary ASPs. >=20 > For NAA=2C the caller gains limited access to the network=2C then they fo= llow -phone-bcp=2C which uses their normal ASP. The ISP cannot possibly id= entify communications directed at this (arbitrary) ASP as being permitted. [BA] I agree. The currently presented solution isn't deployable even when = the signaling traffic is sent in the clear.=20 When it is encrypted=2C it is totally unworkable. > Good point. You don't need to reference 3263 specifically=2C but note th= at server discovery is going to be involved. Such a thing can be missed in= setting up a network. The problem is that Web Portals aren't compatible with RFC 3263 (due to DNS= spoofing). =20 = --_c74f25b0-ce50-41bb-8551-3cf9a63e7e9f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Martin said:

>=3B There is something wrong with the currently= presented solution. It requires that the ISP permit access to arbitrary A= SPs.
>=3B
>=3B For NAA=2C the caller gains limited access to the= network=2C then they follow -phone-bcp=2C which uses their normal ASP. Th= e ISP cannot possibly identify communications directed at this (arbitrary) = ASP as being permitted.

[BA] I agree. =3B The currently presente= d solution isn't deployable even when the signaling traffic is sent in the = clear.

When it is encrypted=2C it is totally unworkable.

>=3B Good point. You don't need to reference 3263 specifically=2C but n= ote that server discovery is going to be involved. Such a thing can be mis= sed in setting up a network.

The problem is that Web Portals aren't = compatible with RFC 3263 (due to DNS spoofing). =3B
=
= --_c74f25b0-ce50-41bb-8551-3cf9a63e7e9f_-- From hannes.tschofenig@gmx.net Mon Jul 11 02:53:08 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1522021F84CF for ; Mon, 11 Jul 2011 02:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4BrEh00+uBZ for ; Mon, 11 Jul 2011 02:53:07 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 879E821F8AEE for ; Mon, 11 Jul 2011 02:52:56 -0700 (PDT) Received: (qmail invoked by alias); 11 Jul 2011 09:52:54 -0000 Received: from letku101.adsl.netsonic.fi (EHLO [10.0.0.6]) [194.29.195.101] by mail.gmx.net (mp009) with SMTP; 11 Jul 2011 11:52:54 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/qOYsJzTDqLWPsscQl7bZ8rugs3Mztx1bmX3WKUt wXoKTpxc62T9Sp From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Jul 2011 12:52:52 +0300 Message-Id: To: ecrit@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [Ecrit] Unauthenticated Emergency Services: Discussion @ upcoming IETF meeting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 09:53:08 -0000 Hi all,=20 based on review comments by Bernard & Martin I would suggest to have a = discussion at the upcoming IETF meeting to go through the following = items: 1) No Access Authentication (NAA) We should go through a message flow step by step and make sure that we = have the same understanding of what happens (and should happen).=20 The interaction with LoST, LoST discovery, and what the LoST database is = provisioned with is interesting to explore. We want to get the security = properties right and therefore have to discuss whether we want LoST to = return a URI that points to arbitrary ASPs or just to an entity in the = ESINet.=20 2) The state of Hotspot access Bernard illustrated that the current hotspot access is quite bad and = there is no easy way to get to the functionality we would need. The = currently described functionality captures the envisioned end state and = does not explain how to get to that state given the nastiness of today's = network deployments. For me the question is essentially of how do we = capture these two worlds? On one hand we want to provide a technical = writeup about the functionality that is needed to make calls in such an = environment happen but on the other hand we need to point to the = problems to get there. Those who make regulatory decisions about this = functionality as well as those who are going to deploy support for it = need to be aware of the challenges.=20 I believe that the points Bernard raised in his review are good and a = short writeup should be included in the document to illustrate some of = the deployment challenges this entire work is going to face. Bernard had = provided a few recommendations that could be discussed.=20 =20 3) Lack of network access authorization The NAA case only focuses on the lack of credentials but does not = consider the case where credentials are available but authorization = fails nevertheless. We could go through one of such a case and figure = out whether to include it either in a separate category or as part of = the NAA case.=20 Bernard also suggested that operators be recruited to review this = document (ideally those who deploy big WLAN hotspots, and enterprise = networks). That's a request to the chairs... 4) Document Writing Style=20 An editorial question was raised by Martin as well. Currently, the draft = states the steps that are necessary for performing the emergency call. = There are only a few steps. Martin suggested to instead reference the = selected parts from the phone BCP and say what is not applicable. = Another option is to provide a summary of what is different. In any = case, the working group feedback on that issue would be interesting.=20 Dirk, and I believe that a discussion about the above-listed items at = the upcoming face-to-face meeting will help us to progress the document.=20= Ciao Hannes From internet-drafts@ietf.org Mon Jul 11 05:11:00 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A83421F8B04; Mon, 11 Jul 2011 05:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqAbXqodYff8; Mon, 11 Jul 2011 05:11:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108DB21F8B45; Mon, 11 Jul 2011 05:10:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110711121059.7342.47908.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 05:10:59 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-unauthenticated-access-03.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 12:11:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Int= ernet Technologies Working Group of the IETF. Title : Extensions to the Emergency Services Architecture for de= aling with Unauthenticated and Unauthorized Devices Author(s) : Henning Schulzrinne Stephen McCann Gabor Bajko Hannes Tschofenig Dirk Kroeselberg Filename : draft-ietf-ecrit-unauthenticated-access-03.txt Pages : 27 Date : 2011-07-11 The IETF emergency services architecture assumes that the calling device has acquired rights to use the access network or that no authentication is required for the access network, such as for public wireless access points. Subsequent protocol interactions, such as obtaining location information, learning the address of the Public Safety Answering Point (PSAP) and the emergency call itself are largely decoupled from the underlying network access procedures. In some cases, however, the device does not have these credentials for network access, does not have a VoIP service provider, or the credentials have become invalid, e.g., because the user has exhausted their prepaid balance or the account has expired. This document provides a problem statement, introduces terminology and describes an extension for the base IETF emergency services architecture to address these scenarios. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-unauthenticated-access= -03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ecrit-unauthenticated-access-= 03.txt From trac+ecrit@trac.tools.ietf.org Sun Jul 10 14:15:42 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9DD521F877A for ; Sun, 10 Jul 2011 14:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wxPREY7Uvla for ; Sun, 10 Jul 2011 14:15:42 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 6B99921F8646 for ; Sun, 10 Jul 2011 14:15:42 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1Qg1Lq-0000DT-9n; Sun, 10 Jul 2011 14:15:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "ecrit issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: ecrit Date: Sun, 10 Jul 2011 21:15:42 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ecrit/trac/ticket/3#comment:1 Message-ID: <074.d3960c863dd3a4f35d750b8dd89bf99a@trac.tools.ietf.org> References: <065.33bb6c2ac204e1ea89a3d76a7ac43756@trac.tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <065.33bb6c2ac204e1ea89a3d76a7ac43756@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Mon, 11 Jul 2011 05:14:03 -0700 Cc: ecrit@ietf.org Subject: Re: [Ecrit] [ecrit] #3: Out-of-date References X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 21:15:42 -0000 #3: Out-of-date References Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: trustworthy-location | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: ecrit From trac+ecrit@trac.tools.ietf.org Sun Jul 10 15:23:30 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B6D21F8763 for ; Sun, 10 Jul 2011 15:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpakdFvf60V9 for ; Sun, 10 Jul 2011 15:23:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 45F9121F874D for ; Sun, 10 Jul 2011 15:23:29 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1Qg2PD-0002MB-Jw; Sun, 10 Jul 2011 15:23:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "ecrit issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: draft-ietf-ecrit-unauthenticated-access@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: ecrit Date: Sun, 10 Jul 2011 22:23:15 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ecrit/trac/ticket/7 Message-ID: <065.557c9028cd3d08a24e06ae9d4ced359f@trac.tools.ietf.org> X-Trac-Ticket-ID: 7 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-ecrit-unauthenticated-access@tools.ietf.org, bernard_aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20110710222329.45F9121F874D@ietfa.amsl.com> Resent-Date: Sun, 10 Jul 2011 15:23:29 -0700 (PDT) Resent-From: trac+ecrit@trac.tools.ietf.org X-Mailman-Approved-At: Mon, 11 Jul 2011 05:14:03 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] [ecrit] #7: Review of unauthenticated access document (-02) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 22:23:30 -0000 #7: Review of unauthenticated access document (-02) This document has improved but there are still some major issues. An important use case (unauthorized network access) does not appear to be covered, and the operational implications of enabling unauthenticated or unauthorized emergency access have not been explored deeply enough. My recommendation is that operators be recruited to review this document. Specific comments: 1. Introduction Summoning police, the fire department or an ambulance in emergencies is one of the fundamental and most-valued functions of the telephone. As telephone functionality moves from circuit-switched telephony to Internet telephony, its users rightfully expect that this core functionality will continue to work at least as well as it has for the older technology. New devices and services are being made available that could be used to make a request for help, which are not traditional telephones, and users are increasingly expecting them to be used to place emergency calls. [BA] It would be useful to (briefly) discuss the existing functionality for emergency calling with Non-Service Initialized (NSI) devices here. We distinguish between three conditions: No Access Authentication (NAA): In the NAA case, the emergency caller does not posses valid credentials for the access network. This includes the case where the access network allows pay-per- use, as is common for wireless hotspots, but there is insufficient time to enter credit card details and other registration information required for access. It also covers all cases where either no credentials are available at all, or the available credentials do not work for the given IAP/ISP. As a result, the NAA case basically combines the below NASP and ZBP cases, but at the IAP/ISP level. Support for emergency call handling in the NAA case is subject to the local policy of the ISP. Such policy may vary substantially between ISPs and typically depends on external factors that are not under the ISP control. [BA] This does not appear to cover the case of lack of network access authorization. For example, a user might have an account, but have depleted their prepaid account, or perhaps they are authorized only for voice, but not data. Note: At the time of writing there is no regulation in place that demands the functionality described in this memo. SDOs have started their work on this subject in a proactive fashion in the anticipation that national regulation will demand it for a subset of network environments. [BA] This should also stated earlier, such in the abstract. There are also indications that the functionality of unauthenticated emergency calls (called SIM-less calls) in today's cellular system in certain countries leads to a fair amount of hoax or test calls. This causes overload situations at PSAPs which is considered harmful to the overall availability and reliability of emergency services. As an example, Federal Office of Communications (OFCOM, Switzerland) provided statistics about emergency (112) calls in Switzerland from Jan. 1997 to Nov. 2001. Switzerland did not offer SIM-less emergency calls except for almost a month in July 2000 where a significant increase in hoax and test calls was reported. As a consequence, the functionality was disabled again. More details can be found in the panel presentations of the 3rd SDO Emergency Services Workshop [esw07]. [BA] I recommend that these paragraphs be moved up earlier, right after a basic description of NSI functionality. Figure 1 compiles the basic logic taking place during network entry for requesting an emergency service and shows the interrelation between the three conditions described in the above section. +-----Y |Start| `...../ | | Are credentials | for network attachment | available? | NO v YES +----------------------------+ | | | | V v .............. ................ | Idle: Wait | |Execute | | for ES Call| |LLA Procedures| | Initiation | "--------------' "------------' | Is | +---------->O emergency | | | Is ASP service | NO +-----Y | | configured? network +--->| End | | +---------------+ attachment| `...../ | YES | | NO possible? | | | | v | v v +------------+ | +------------+ +------------+ | Execute | | | Execute | | Execute | | NAA |--------+ | Phone BCP | | NASP | | Procedures | | Procedures | | Procedures | +------------+ +------------+ +------------+ Authorization for| | Emergency Call? | | +--------------+ v | NO | YES +-----Y | | | Done| v v `...../ +------------+ +------------+ | Execute | | Execute | | ZBP | | Phone BCP | | Procedures | | Procedures | +------------+ +------------+ | | | | v v +-----Y +-----Y | Done| | Done| `...../ `...../ Abbreviations: LLA: Link Layer Attachment ES: Emergency Services Figure 1: Flow Diagram [BA] The reality is considerably more complicated that than this. For example: * network access credentials may be available, but not authorization. * A Web portal using DNS spoofing might be in place. * Firewalls may be in place blocking access to some services (e.g. no UDP/TCP outbound, only HTTP). As a result, I'm not convinced that this flowchart is accurate or useful enough to include at the beginning of the document. Better to move it to an appendix or remove it altogether. 5.1.5. SIP Emergency Call Signaling SIP signaling capabilities [RFC3261] are mandated for end hosts. The initial SIP signaling method is an INVITE. The SIP INVITE request MUST be constructed according to the requirements in Section 9.2 [I-D.ietf-ecrit-phonebcp]. Regarding callback behavior SIP UAs SHOULD place a globally routable URI in a Contact: header. [BA] SIP UA's can't obtain GRUUs on their own. Is there an ASP requirement here? Also, should there be a reference to a PSAP callback document? 5.2.2. Location Determination and Location Configuration The ISP is responsible for location determination and exposes this information to the end points via location configuration protocols. The considerations described in [I-D.ietf-ecrit-location-hiding-req] are applicable to this document. The ISP MUST support one of the LCPs described in Section 6.5 of [I-D.ietf-ecrit-phonebcp]. The description in Section 6.5 and 6.6 of [I-D.ietf-ecrit-phonebcp] regarding the interaction between the end device and the LIS applies to this document. The interaction between the LIS at the ISP and the IAB is often priorietary but the description in [I-D.winterbottom-geopriv-lis2lis-req] may be relevant to the reader. [BA] Don't you mean IAP and not IAB here? 6.2. Securing Network Attachment in NAA Cases 2) Null Authentication: In one case (e.g. WiMAX) an EAP method is performed. However, no credentials specific to either the server or the device or subscription are used as part of the authentication exchange. An example for this would be an EAP-TLS exchange with using the TLS_DH_anon (anonymous) ciphersuite. [BA] EAP-TLS [RFC 5216] does not support the negotiation of the anonymous DH ciphersuite. At a minimum, the server needs to provide a certificate. Alternatively, a publicly available static key for emergency access could be used. In the latter case, the device would need to be provisioned with the appropriate emergency key for the IAP/ISP in advance. In another case (e.g. IEEE 802.11), no EAP method is used, so that empty frames are transported during the over the air IEEE 802.1X exchange. In this case the authentication state machine completes with no cryptographic keys being exchanged. [BA] It is not clear what it is being described here. If WPA2 Enterprise is used, then EAP and an EAP method will need to be selected. RFC 3748 does not support exchange of "empty" EAP frames. 7. Security Considerations There are a couple of new vulnerabilities raised with unauthenticated emergency services in NASP/NAA cases since the PSAP operator will typically not possess any identity information about the emergency call via the signaling path itself. In countries where this functionality is used for GSM networks today this has lead to a significant amount of misuse. [BA] I think you need to discuss the NASP and NAA cases separately. In the NASP case, the user might have valid credentials with the ASP, so that the PSAP could obtain identify information. In the NAA case, you need to separate unauthenticated from unauthorized access. In the former case, there may be no NAI, but there may be other identifying info (e.g. MAC address). In the latter case there is an identity. In the context of NAA, the IAP and the ISP will probably want to make sure that the claimed emergency caller indeed performs an emergency call rather than using the network for other purposes, and thereby acting fraudulent by skipping any authentication, authorization and accounting procedures. By restricting access of the unauthenticated emergency caller to the LoST server and the PSAP URI, traffic can be restricted only to emergency calls. This can be accomplished with traffic separation. The details, however, e.g. for using filtering, depend on the deployed ISP architecture and are beyond the scope of this document. We only illustrate a possible model. If the ISP runs its own LoST server, it would maintain an access control list including all IP addresses contained in responses returned by the LoST server, as well as the LoST server itself. (It may need to translate the domain names returned to IP addresses and hope that the resolution captures all possible DNS responses.) Since the media destination addresses are not predictable, the ISP also has to provide a SIP outbound proxy so that it can determine the media addresses and add those to the filter list. [BA] There are some very challenging operational problems here that you need to discuss in more depth. I would recommend that this section be reviewed by operators, to ensure that the advice is implementable. Some concerns: 1. DNS spoofing. Many 802.11 hotspots use web portals today along with DNS spoofing. This will block any emergency calling device without a web browser, create delays for those with a browser, and may cause certificate or DNSSEC validation failures within VOIP clients. 2. ISP operaton of a SIP outbound proxy configuration. This doesn't seem implementable to me. Getting a naive user to change their SIP outbound proxy configuration to make an emergency call is time consuming and likely to consume valuable time in an emergency. There are SIP clients that will require SIP over TLS and may not have trust anchors configured for the ISP SIP proxy. Overall, an ISP taking this on will be challenged to provide tech support to non-customers in potentially emergent situations. Do we really think this is a viable approach? 3. Firewall configurations. Operators will often have concerns about opening generic holes in the firewall (e.g. opening a hole for traffic to destination ports 5060/5061). To ensure that traffic is actually being used for emergency purposes, deep packet inspection may be required. But what happens if the traffic is encrypted (e.g. SIP over TLS)? -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: draft-ietf-ecrit-unauthenticated-access@… Type: defect | Status: new Priority: critical | Milestone: milestone1 Component: unauthenticated-access | Version: 1.0 Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: ecrit From hannes.tschofenig@gmx.net Mon Jul 11 05:14:26 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 239A821F8B1E for ; Mon, 11 Jul 2011 05:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.309 X-Spam-Level: X-Spam-Status: No, score=-101.309 tagged_above=-999 required=5 tests=[AWL=-1.265, BAYES_00=-2.599, FRT_BIGGERMEM1=2.555, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3WNMCo60yQU for ; Mon, 11 Jul 2011 05:14:25 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id D46B621F8AF4 for ; Mon, 11 Jul 2011 05:14:17 -0700 (PDT) Received: (qmail invoked by alias); 11 Jul 2011 12:14:16 -0000 Received: from letku214.adsl.netsonic.fi (EHLO [10.0.0.6]) [194.29.195.214] by mail.gmx.net (mp028) with SMTP; 11 Jul 2011 14:14:16 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/wO6lQ15Xwcy3A2DrZRviFEBDgTrt2y9EZPoJ80p nR7BKxYvdYzwXA From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Jul 2011 15:14:15 +0300 Message-Id: To: ecrit@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [Ecrit] draft-ietf-ecrit-unauthenticated-access-03.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 12:14:26 -0000 Hi all,=20 with the submission of draft-ietf-ecrit-unauthenticated-access-03.txt I = only wanted to address a few of the recent review comments awaiting a = conclusion of the larger open issues.=20 Ciao Hannes From internet-drafts@ietf.org Mon Jul 11 05:15:55 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F0821F8B24; Mon, 11 Jul 2011 05:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpNp1qfm7bf2; Mon, 11 Jul 2011 05:15:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D71721F8B07; Mon, 11 Jul 2011 05:15:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110711121554.10360.19473.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 05:15:54 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-data-only-ea-02.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 12:15:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Int= ernet Technologies Working Group of the IETF. Title : Common Alerting Protocol (CAP) based Emergency Alerts us= ing the Session Initiation Protocol (SIP) Author(s) : Brian Rosen Henning Schulzrinne Hannes Tschofenig Filename : draft-ietf-ecrit-data-only-ea-02.txt Pages : 22 Date : 2011-07-11 The Common Alerting Protocol (CAP) is a document format for exchanging emergency alerts and public warnings. CAP is mainly used for conveying alerts and warnings between authorities and from authorities to citizen/individuals. This document describes how devices use CAP to issue emergency alerts. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-data-only-ea-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ecrit-data-only-ea-02.txt From hannes.tschofenig@gmx.net Mon Jul 11 05:25:58 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20FF021F8B3C for ; Mon, 11 Jul 2011 05:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id et5AksuI8Ofv for ; Mon, 11 Jul 2011 05:25:57 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 3983621F8B2A for ; Mon, 11 Jul 2011 05:25:57 -0700 (PDT) Received: (qmail invoked by alias); 11 Jul 2011 12:25:55 -0000 Received: from letku101.adsl.netsonic.fi (EHLO [10.0.0.6]) [194.29.195.101] by mail.gmx.net (mp033) with SMTP; 11 Jul 2011 14:25:55 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19CJyFYDthCS3fh+918RfkgWP/L5upI2kwRbfBK+z IVBjYr5WXDQ2RX From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Jul 2011 15:25:54 +0300 Message-Id: <034802F6-45A3-476A-B201-087A63BC1A18@gmx.net> To: ecrit@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [Ecrit] draft-ietf-ecrit-data-only-ea-02.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 12:25:58 -0000 Hi all,=20 the submission of draft-ietf-ecrit-data-only-ea-02.txt aims to address = the review comments from Martin, Bernard, Marc, and Shida. The currently provided text is a proposal to resolve their feedback.=20 I will reach out to them to determine whether the -02 version = sufficiently addressed their remarks. Ciao Hannes From br@brianrosen.net Mon Jul 11 15:36:03 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B66B11E834C for ; Mon, 11 Jul 2011 15:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.691 X-Spam-Level: X-Spam-Status: No, score=-102.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnwiIfE6yVYJ for ; Mon, 11 Jul 2011 15:36:02 -0700 (PDT) Received: from barracuda.canadianwebhosting.com (barmail2.idig.net [64.34.111.252]) by ietfa.amsl.com (Postfix) with ESMTP id 77CA911E834B for ; Mon, 11 Jul 2011 15:36:02 -0700 (PDT) X-ASG-Debug-ID: 1310423760-04412114c7141580001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barracuda.canadianwebhosting.com with ESMTP id O9BP2kZvXxVoVjGy; Mon, 11 Jul 2011 15:36:00 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from [24.154.127.233] (helo=[192.168.1.110]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QgP56-0005Tf-72; Mon, 11 Jul 2011 15:36:00 -0700 Mime-Version: 1.0 (Apple Message framework v1084) X-ASG-Orig-Subj: Re: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01 Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: <218A5B2C-7978-4FA5-83C1-46C16370B8FB@gmx.net> Date: Mon, 11 Jul 2011 12:40:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <218A5B2C-7978-4FA5-83C1-46C16370B8FB@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1084) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1310423760 X-Barracuda-URL: http://64.34.111.252:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at canadianwebhosting.com X-Barracuda-Spam-Score: 1.09 X-Barracuda-Spam-Status: No, SCORE=1.09 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=DATE_IN_PAST_03_06, DATE_IN_PAST_03_06_2 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.68650 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date 1.08 DATE_IN_PAST_03_06_2 DATE_IN_PAST_03_06_2 Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 22:36:03 -0000 I am sorry I was not able to participate in this discussion. I think it = is heading in the wrong direction. CAP is a wrapper for data related to an alert. It's a very common = wrapper, but it's just a wrapper. With respect to a citizen to = authority alert, it doesn't provide enough information by itself, and it = doesn't provide the kind of location based routing mechanisms we need = for these kinds of alerts. The payload of the alert, that provides the information we need, should = be the "Additional Call Data" structure we are working on in ecrit. We need a SIP mechanism to allow the -phonebcp routing we need for a = DATA ONLY alert. An alert of this kind has an important characteristic = uncommon with media sessions - there is no media session. MESSAGE has = the appropriate semantics when used in the "pager" mode. It's a one = time, no session, SIP transaction with the interesting part in the body = of the message. If you have a media session, and what you want to do is send sensor data = in the INVITE, the Additional Call Data mechanism does that. This = mechanism is used only when you have no media, all you have is data. What this really means is that we could, if we wanted to, just put a = Call Info header on a MESSAGE transaction and treat it like a call, but = most of the sources we have talked to believed that CAP really should be = used for a one way alert. So, we put the CAP message in a SIP MESSAGE = transaction. Brian On Jul 8, 2011, at 7:15 AM, Hannes Tschofenig wrote: > I have updated the draft to reflect our discussion. Please find the = most recent version here: > = http://www.tschofenig.priv.at/svn/draft-rosen-ecrit-data-only-ea/draft-iet= f-ecrit-data-only-ea-02.txt >=20 > I now changed Section 4.1 that talks about the CAP transport:=20 >=20 > ----- >=20 > 4.1. CAP Transport >=20 > Since alerts structured via CAP require a "push" medium. The > following SIP requests MAY carry the CAP payload defined in this > document: INVITE [RFC3261], UPDATE [RFC3311], MESSAGE [RFC3428], = INFO > [RFC6086], NOTIFY [RFC3265], and PUBLISH [RFC3903]. The MIME type = is > set to 'application/cap+xml'. >=20 > If the server does not support the functionality required to fulfill > the request then a 501 Not Implemented MUST be returned by RFC 3261 > [RFC3261]. This is the appropriate response when a UAS does not > recognize the request method and is not capable of supporting it for > any user. >=20 > The 415 Unsupported Media Type error MUST be returned by RFC 3261 > [RFC3261] if the server is refusing to service the request because > the message body of the request is in a format not supported by the > server for the requested method. The server MUST return a list of > acceptable formats using the Accept, Accept-Encoding, or Accept- > Language header field, depending on the specific problem with the > content. >=20 > ----- >=20 > Ciao > Hannes >=20 > On Jul 8, 2011, at 10:50 AM, Hannes Tschofenig wrote: >=20 >> Hi Bernard,=20 >>=20 >> On Jul 8, 2011, at 2:49 AM, Bernard Aboba wrote: >>=20 >>> Hannes said: >>>=20 >>> The question is also whether we need to restrict the way a CAP = payload is sent to a recipient.=20 >>> One could argue that it does not really matter whether it is an = INVITE, a MESSAGE, or a PUBLISH.=20 >>> Which one is best depends on a specific environment.=20 >>>=20 >>> But you seem to be arguing that we should rather stick with the = INVITE instead of using MESSAGE.=20 >>> This would at least allow us to get the message understood by every = SIP device.=20 >>=20 >>> [BA] I have no problem with including CAP in MESSAGE. My major = concern was how to ensure interoperability and potential >>> problems that could delay emergency calls.=20 >>=20 >> Your suggestion to use INVITE seemed to be interesting but after = further thinking about it I am not sure whether the perceived level of = interoperability is worth sticking only with an INVITE. If the recipient = does not understand the CAP payload (and only the INVITE itself) then = there is still no interoperability.=20 >>=20 >> As such, I believe I have to put text in there regarding error = messages and the core SIP spec already provides them, namely=20 >> * 501 Not Implemented, and=20 >> * 415 Unsupported Media Type >>=20 >> I am still thinking whether we should allow the CAP payload to be = used in an INVITE, a MESSAGE, an a PUBLISH. >>=20 >>>=20 >>> This is just an example. Using TCP indeed makes sense for XML-based = payloads.=20 >>> I don't think we want to mandate that TCP is mandatory-to-use.=20 >>>=20 >>> [BA] I agree that we don't want to mandate use. But we are talking = about emergency calls, so making a recommendation on how to avoid = problems is probably a good idea.=20 >>>=20 >>> I assume that the device that issues the alert is actually an = IP-based device.=20 >>> For me the story begins with the first IP device.=20 >>=20 >>>=20 >>> [BA] My problem with signatures is in emergency contexts is the cost = and value of validating them. In ATOCA there may >>> be a model for this (e.g. government signs the CAP), but in a device = scenario, it's not easy to figure out how a PSAP would >>> validate the signature or what value it would have.=20 >>=20 >> I agree with you that most deployments will in their judgements about = the security threats conclude that they do not need to additionally sign = the CAP message and instead rely on the SIP security mechanisms. That's = my assumption. Still, the security consideration section lays out the = options.=20 >>=20 >>=20 >>>=20 >>> With SIP Identity the identity header is either added by the end = point (unlikely) or by the outbound proxy.=20 >>> If it is added by the outbound proxy then there has to be TLS = between the end point and the outbound proxy.=20 >>> This would provide proper protection of the message exchange and = would fulfill our purpose here. Wouldn't you say so?=20 >>>=20 >>> [BA] TLS is fine with me -- but it solves a different problem than = RFC 4474. >>=20 >> In the typical use case of SIP Identity (at least as envisioned in = the specification) the identity assertion is added by the Authentication = service (e.g. the outbound proxy) and there still has to be security = provided from the end host to that Authentication Service. This may = likely come in form of TLS since otherwise the identity assurance is of = little value if the adversary is sitting somewhere along that path.=20 >>=20 >>>=20 >>> True. There is the SIP identity of the sender, the field in the CAP = message (sender field), and then there is cryptographic material in case = of a signature that will have some identity information associated with = it.=20 >>> Currently, the draft says that we should set the sender field of the = CAP message to the value of the sender of the SIP message. Useful to set = to two equal? >>>=20 >>> [BA] That is useful if the CAP sender and SIP sender are actually = the same. If not, then the CAP sender field should reflect who composed = the CAP.=20 >>>=20 >>=20 >> I put text into the draft already about the case where the two are = different.=20 >>=20 >>> I am OK with not focusing on security threats as the document = currently does, but instead focus on the solutions.=20 >>> Using the terminology from the ATOCA requirements document maybe it = is better to talk about=20 >>>=20 >>> 1) Verification of the alert originator (this is the SIP stuff)=20 >>> 2) Verification of the alert author (this is the alert stuff) >>> 3) Integrity of alerts in transit (the TLS) >>>=20 >>> OK for you?=20 >>>=20 >>>=20 >>> [BA] Yes, that is a better approach. >>>=20 >>=20 >> I proposed text already that follows this type of structure - = although not with sub-section headings.=20 >>=20 >> Ciao >> Hannes >>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From Internet-Drafts@ietf.org Mon Jul 11 17:15:02 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC48A21F90A1; Mon, 11 Jul 2011 17:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgkpToEgfSeV; Mon, 11 Jul 2011 17:15:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF3621F90A4; Mon, 11 Jul 2011 17:15:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110712001502.5260.47130.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 17:15:02 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-additional-data-01.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 00:15:03 -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 : Additional Data related to an Emergency Call Author(s) : B. Rosen, et al Filename : draft-ietf-ecrit-additional-data-01.txt Pages : 25 Date : 2011-07-11 When an emergency call is sent to a PSAP, the device that sends it, as well as any service provider in the path of the call, or access network may have information about the call which the PSAP may be able to use. This document describes an XML data structure that contains this kind of information in a standardized form. A URI that points to the structure can be included in the SIP signaling with the call, or the data may be included in the body of a SIP message. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-additional-data-01.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-additional-data-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-07-11170552.I-D@ietf.org> --NextPart-- From Martin.Thomson@commscope.com Mon Jul 11 17:30:32 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 234B311E818B for ; Mon, 11 Jul 2011 17:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzYRHBeMiDOq for ; Mon, 11 Jul 2011 17:30:31 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 812FE11E80BA for ; Mon, 11 Jul 2011 17:30:31 -0700 (PDT) X-AuditID: 0a0404e8-b7c15ae00000540f-d1-4e1b95b28170 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id 41.21.21519.2B59B1E4; Mon, 11 Jul 2011 19:30:43 -0500 (CDT) Received: from CDCE10HC1.commscope.com (10.86.20.21) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 11 Jul 2011 19:31:30 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by CDCE10HC1.commscope.com (10.86.20.21) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 11 Jul 2011 17:31:29 -0700 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Tue, 12 Jul 2011 08:31:27 +0800 From: "Thomson, Martin" To: Bernard Aboba , Hannes Tschofenig Date: Tue, 12 Jul 2011 08:31:26 +0800 Thread-Topic: [Ecrit] Unauthenticated access review Thread-Index: Acw/nGMYMS0ayDPyTBqFT8LQZwliQAAjZIWw Message-ID: <8B0A9FCBB9832F43971E38010638454F040B419DEF@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F040B26CBA8@SISPE7MB1.commscope.com>, <5A5CA3CF-3853-472D-A0A1-1F4799EB6459@gmx.net>, <8B0A9FCBB9832F43971E38010638454F040B419D3D@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: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Unauthenticated access review X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 00:30:32 -0000 On 2011-07-11 at 17:28:53, Bernard Aboba wrote: > ...DNS spoofing... DNS spoofing is a real pain, but maybe it's not a problem we need to concer= n ourselves with. There's plenty of other big problems with unauthenticate= d access. I propose that we add text that describes the potential problems. Then, we= say that those who employ DNS spoofing are not capable of providing unauth= enticated access for emergency purposes for those reasons. If they aren't required to provide unauthenticated access, then hotspot ope= rators can continue to spoof DNS. --Martin From hgs@cs.columbia.edu Mon Jul 11 17:46:17 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFCEA11E83F7 for ; Mon, 11 Jul 2011 17:46:17 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehrtEUGHYBVN for ; Mon, 11 Jul 2011 17:46:17 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by ietfa.amsl.com (Postfix) with ESMTP id 420BE11E8158 for ; Mon, 11 Jul 2011 17:46:17 -0700 (PDT) Received: from new-host-3.home (pool-173-54-225-113.nwrknj.fios.verizon.net [173.54.225.113]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id p6C0kCUX016768 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 11 Jul 2011 20:46:13 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <8B0A9FCBB9832F43971E38010638454F040B419DEF@SISPE7MB1.commscope.com> Date: Mon, 11 Jul 2011 20:46:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <68285B43-E28B-4E6A-B814-F7DFA994A944@cs.columbia.edu> References: <8B0A9FCBB9832F43971E38010638454F040B26CBA8@SISPE7MB1.commscope.com>, <5A5CA3CF-3853-472D-A0A1-1F4799EB6459@gmx.net>, <8B0A9FCBB9832F43971E38010638454F040B419D3D@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F040B419DEF@SISPE7MB1.commscope.com> To: "Thomson, Martin" X-Mailer: Apple Mail (2.1084) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Unauthenticated access review X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 00:46:18 -0000 In that spirit: I don't think we're trying to backport unauthenticated = access onto unchanged networks. At best, we're trying to tell operators = who want to (or whose local regulator makes them) provide such a service = what they would have to do to make it work. There's a set of problems that makes VoIP access in networks difficult, = emergency or not, but Skype has shown that this is surmountable. (They = seem to have worked out an arrangement with many WiFi operators in = public hot spots that you can pay through them by the minute, and make = phone calls, without a browser interaction.) That's not quite = unauthenticated access, but it's another model that could work where the = caller does not have a direct customer relationship with the WiFi = provider. While they are not as ubiquitous as Boingo, there are a number of = wireless networks that may not care as much about revenue issues. For = example, many hotels and public park hot spots provide a splash page = mainly to get visitors to agree to various appropriate usage policies. = They may well be willing to run the risk that somebody "fakes" an = emergency call to bypass the splash page - from their perspective, it = would be really hard to argue that they didn't see the warning against = file sharing because they faked an emergency call. Not something you are = going to tell a judge. Allowing a connection to an outbound SIP proxy = would do the trick in that case. Henning On Jul 11, 2011, at 8:31 PM, Thomson, Martin wrote: > On 2011-07-11 at 17:28:53, Bernard Aboba wrote: >> ...DNS spoofing... >=20 > DNS spoofing is a real pain, but maybe it's not a problem we need to = concern ourselves with. There's plenty of other big problems with = unauthenticated access. >=20 > I propose that we add text that describes the potential problems. = Then, we say that those who employ DNS spoofing are not capable of = providing unauthenticated access for emergency purposes for those = reasons. >=20 > If they aren't required to provide unauthenticated access, then = hotspot operators can continue to spoof DNS. >=20 > --Martin >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 From bernard_aboba@hotmail.com Mon Jul 11 18:46:29 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D035C11E83FD for ; Mon, 11 Jul 2011 18:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqKRdf3Vpd6H for ; Mon, 11 Jul 2011 18:46:29 -0700 (PDT) Received: from blu0-omc2-s25.blu0.hotmail.com (blu0-omc2-s25.blu0.hotmail.com [65.55.111.100]) by ietfa.amsl.com (Postfix) with ESMTP id F2D2911E80D2 for ; Mon, 11 Jul 2011 18:46:24 -0700 (PDT) Received: from BLU152-W47 ([65.55.111.71]) by blu0-omc2-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Jul 2011 18:46:24 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_a62bde81-80d8-41d0-be7d-8310964ae50f_" X-Originating-IP: [98.203.198.61] From: Bernard Aboba To: , Hannes Tschofenig Date: Mon, 11 Jul 2011 18:46:23 -0700 Importance: Normal In-Reply-To: <8B0A9FCBB9832F43971E38010638454F040B419DEF@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F040B26CBA8@SISPE7MB1.commscope.com>, <5A5CA3CF-3853-472D-A0A1-1F4799EB6459@gmx.net>, <8B0A9FCBB9832F43971E38010638454F040B419D3D@SISPE7MB1.commscope.com>, , <8B0A9FCBB9832F43971E38010638454F040B419DEF@SISPE7MB1.commscope.com> MIME-Version: 1.0 X-OriginalArrivalTime: 12 Jul 2011 01:46:24.0945 (UTC) FILETIME=[823E0A10:01CC4035] Cc: ecrit@ietf.org Subject: Re: [Ecrit] Unauthenticated access review X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 01:46:29 -0000 --_a62bde81-80d8-41d0-be7d-8310964ae50f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Agree on describing the issues and recommending non-spoofing (e.g open=2C W= PA2) approaches to unauthn/unauthz access. =20 > From: Martin.Thomson@commscope.com > To: bernard_aboba@hotmail.com=3B hannes.tschofenig@gmx.net > CC: ecrit@ietf.org > Date: Tue=2C 12 Jul 2011 08:31:26 +0800 > Subject: RE: [Ecrit] Unauthenticated access review >=20 > On 2011-07-11 at 17:28:53=2C Bernard Aboba wrote: > > ...DNS spoofing... >=20 > DNS spoofing is a real pain=2C but maybe it's not a problem we need to co= ncern ourselves with. There's plenty of other big problems with unauthenti= cated access. >=20 > I propose that we add text that describes the potential problems. Then= =2C we say that those who employ DNS spoofing are not capable of providing = unauthenticated access for emergency purposes for those reasons. >=20 > If they aren't required to provide unauthenticated access=2C then hotspot= operators can continue to spoof DNS. >=20 > --Martin >=20 >=20 >=20 = --_a62bde81-80d8-41d0-be7d-8310964ae50f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Agree on describing the issues and recommending non-spoofing (e.g open=2C W= PA2) approaches to unauthn/unauthz access. =3B

>=3B From= : Martin.Thomson@commscope.com
>=3B To: bernard_aboba@hotmail.com=3B h= annes.tschofenig@gmx.net
>=3B CC: ecrit@ietf.org
>=3B Date: Tue= =2C 12 Jul 2011 08:31:26 +0800
>=3B Subject: RE: [Ecrit] Unauthenticat= ed access review
>=3B
>=3B On 2011-07-11 at 17:28:53=2C Bernard = Aboba wrote:
>=3B >=3B ...DNS spoofing...
>=3B
>=3B DNS s= poofing is a real pain=2C but maybe it's not a problem we need to concern o= urselves with. There's plenty of other big problems with unauthenticated a= ccess.
>=3B
>=3B I propose that we add text that describes the p= otential problems. Then=2C we say that those who employ DNS spoofing are n= ot capable of providing unauthenticated access for emergency purposes for t= hose reasons.
>=3B
>=3B If they aren't required to provide unaut= henticated access=2C then hotspot operators can continue to spoof DNS.
&= gt=3B
>=3B --Martin
>=3B
>=3B
>=3B
=
= --_a62bde81-80d8-41d0-be7d-8310964ae50f_-- From hannes.tschofenig@gmx.net Tue Jul 12 02:52:17 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACF421F8EA8 for ; Tue, 12 Jul 2011 02:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcYtd1bpMoI3 for ; Tue, 12 Jul 2011 02:52:15 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 44C6F21F8EA6 for ; Tue, 12 Jul 2011 02:52:15 -0700 (PDT) Received: (qmail invoked by alias); 12 Jul 2011 09:52:14 -0000 Received: from unknown (EHLO [10.255.135.4]) [192.100.123.77] by mail.gmx.net (mp019) with SMTP; 12 Jul 2011 11:52:14 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+N3g8gBVSN3rJXsSK2TNH0nDV4WWcpDjZp93nDLi 2HYAttAgj47hxc Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Tue, 12 Jul 2011 12:52:07 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <218A5B2C-7978-4FA5-83C1-46C16370B8FB@gmx.net> To: Brian Rosen X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 09:52:17 -0000 Hi Brian,=20 On Jul 11, 2011, at 7:40 PM, Brian Rosen wrote: > I am sorry I was not able to participate in this discussion. I think = it is heading in the wrong direction. >=20 > CAP is a wrapper for data related to an alert. It's a very common = wrapper, but it's just a wrapper. With respect to a citizen to = authority alert, it doesn't provide enough information by itself, and it = doesn't provide the kind of location based routing mechanisms we need = for these kinds of alerts. Correct. For this reason the document assumes that location in the form = of a PIDF-LO is attached. I put text in there versions ago.=20 >=20 > The payload of the alert, that provides the information we need, = should be the "Additional Call Data" structure we are working on in = ecrit. True. There may be additional data there as well. I could make this = explicit in the draft.=20 >=20 > We need a SIP mechanism to allow the -phonebcp routing we need for a = DATA ONLY alert. An alert of this kind has an important characteristic = uncommon with media sessions - there is no media session. MESSAGE has = the appropriate semantics when used in the "pager" mode. It's a one = time, no session, SIP transaction with the interesting part in the body = of the message. In essence you are arguing that we should only stick with the MESSAGE = rather than allowing the CAP payload to be carried also in the INVITE = [RFC3261], UPDATE [RFC3311], INFO [RFC6086], NOTIFY [RFC3265], and = PUBLISH [RFC3903] messages. >=20 > If you have a media session, and what you want to do is send sensor = data in the INVITE, the Additional Call Data mechanism does that. This = mechanism is used only when you have no media, all you have is data. Well. The additional call data as it is written now does not provide the = same amount of information as the CAP message. For example, if you look = at the example from = http://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-02#section-6 S-1 sip:sensor1@domain.com 2008-11-19T14:57:00-07:00 Actual Alert Private abc1234 Security BURGLARY Expected Likely Moderate SENSOR 1 SENSOR-DATA-NAMESPACE1 123 SENSOR-DATA-NAMESPACE2 TRUE The block is not standardized so there is no difference to = the additional data either. Then, there are a few elements like = , , , , , , = etc. that do not have an equivalent in the additional data = structure at the moment. Of course one could question the usefulness of = these fields (which I sometimes do).=20 Additionally, I wonder why we actually have to stick with an XML = encoding of the additional data (and with the CAP payload as well). It = is just verbose for no good reason. Why don't we use JSON? Just thinking = loud... The JSON encoding would also allow us to have an implementable = end-to-end security solution (as a side remark).=20 >=20 > What this really means is that we could, if we wanted to, just put a = Call Info header on a MESSAGE transaction and treat it like a call, but = most of the sources we have talked to believed that CAP really should be = used for a one way alert. So, we put the CAP message in a SIP MESSAGE = transaction. Ok. Fine with me. Ciao Hannes >=20 > Brian >=20 > On Jul 8, 2011, at 7:15 AM, Hannes Tschofenig wrote: >=20 >> I have updated the draft to reflect our discussion. Please find the = most recent version here: >> = http://www.tschofenig.priv.at/svn/draft-rosen-ecrit-data-only-ea/draft-iet= f-ecrit-data-only-ea-02.txt >>=20 >> I now changed Section 4.1 that talks about the CAP transport:=20 >>=20 >> ----- >>=20 >> 4.1. CAP Transport >>=20 >> Since alerts structured via CAP require a "push" medium. The >> following SIP requests MAY carry the CAP payload defined in this >> document: INVITE [RFC3261], UPDATE [RFC3311], MESSAGE [RFC3428], = INFO >> [RFC6086], NOTIFY [RFC3265], and PUBLISH [RFC3903]. The MIME type = is >> set to 'application/cap+xml'. >>=20 >> If the server does not support the functionality required to fulfill >> the request then a 501 Not Implemented MUST be returned by RFC 3261 >> [RFC3261]. This is the appropriate response when a UAS does not >> recognize the request method and is not capable of supporting it for >> any user. >>=20 >> The 415 Unsupported Media Type error MUST be returned by RFC 3261 >> [RFC3261] if the server is refusing to service the request because >> the message body of the request is in a format not supported by the >> server for the requested method. The server MUST return a list of >> acceptable formats using the Accept, Accept-Encoding, or Accept- >> Language header field, depending on the specific problem with the >> content. >>=20 >> ----- >>=20 >> Ciao >> Hannes >>=20 >> On Jul 8, 2011, at 10:50 AM, Hannes Tschofenig wrote: >>=20 >>> Hi Bernard,=20 >>>=20 >>> On Jul 8, 2011, at 2:49 AM, Bernard Aboba wrote: >>>=20 >>>> Hannes said: >>>>=20 >>>> The question is also whether we need to restrict the way a CAP = payload is sent to a recipient.=20 >>>> One could argue that it does not really matter whether it is an = INVITE, a MESSAGE, or a PUBLISH.=20 >>>> Which one is best depends on a specific environment.=20 >>>>=20 >>>> But you seem to be arguing that we should rather stick with the = INVITE instead of using MESSAGE.=20 >>>> This would at least allow us to get the message understood by every = SIP device.=20 >>>=20 >>>> [BA] I have no problem with including CAP in MESSAGE. My major = concern was how to ensure interoperability and potential >>>> problems that could delay emergency calls.=20 >>>=20 >>> Your suggestion to use INVITE seemed to be interesting but after = further thinking about it I am not sure whether the perceived level of = interoperability is worth sticking only with an INVITE. If the recipient = does not understand the CAP payload (and only the INVITE itself) then = there is still no interoperability.=20 >>>=20 >>> As such, I believe I have to put text in there regarding error = messages and the core SIP spec already provides them, namely=20 >>> * 501 Not Implemented, and=20 >>> * 415 Unsupported Media Type >>>=20 >>> I am still thinking whether we should allow the CAP payload to be = used in an INVITE, a MESSAGE, an a PUBLISH. >>>=20 >>>>=20 >>>> This is just an example. Using TCP indeed makes sense for XML-based = payloads.=20 >>>> I don't think we want to mandate that TCP is mandatory-to-use.=20 >>>>=20 >>>> [BA] I agree that we don't want to mandate use. But we are talking = about emergency calls, so making a recommendation on how to avoid = problems is probably a good idea.=20 >>>>=20 >>>> I assume that the device that issues the alert is actually an = IP-based device.=20 >>>> For me the story begins with the first IP device.=20 >>>=20 >>>>=20 >>>> [BA] My problem with signatures is in emergency contexts is the = cost and value of validating them. In ATOCA there may >>>> be a model for this (e.g. government signs the CAP), but in a = device scenario, it's not easy to figure out how a PSAP would >>>> validate the signature or what value it would have.=20 >>>=20 >>> I agree with you that most deployments will in their judgements = about the security threats conclude that they do not need to = additionally sign the CAP message and instead rely on the SIP security = mechanisms. That's my assumption. Still, the security consideration = section lays out the options.=20 >>>=20 >>>=20 >>>>=20 >>>> With SIP Identity the identity header is either added by the end = point (unlikely) or by the outbound proxy.=20 >>>> If it is added by the outbound proxy then there has to be TLS = between the end point and the outbound proxy.=20 >>>> This would provide proper protection of the message exchange and = would fulfill our purpose here. Wouldn't you say so?=20 >>>>=20 >>>> [BA] TLS is fine with me -- but it solves a different problem than = RFC 4474. >>>=20 >>> In the typical use case of SIP Identity (at least as envisioned in = the specification) the identity assertion is added by the Authentication = service (e.g. the outbound proxy) and there still has to be security = provided from the end host to that Authentication Service. This may = likely come in form of TLS since otherwise the identity assurance is of = little value if the adversary is sitting somewhere along that path.=20 >>>=20 >>>>=20 >>>> True. There is the SIP identity of the sender, the field in the CAP = message (sender field), and then there is cryptographic material in case = of a signature that will have some identity information associated with = it.=20 >>>> Currently, the draft says that we should set the sender field of = the CAP message to the value of the sender of the SIP message. Useful to = set to two equal? >>>>=20 >>>> [BA] That is useful if the CAP sender and SIP sender are actually = the same. If not, then the CAP sender field should reflect who composed = the CAP.=20 >>>>=20 >>>=20 >>> I put text into the draft already about the case where the two are = different.=20 >>>=20 >>>> I am OK with not focusing on security threats as the document = currently does, but instead focus on the solutions.=20 >>>> Using the terminology from the ATOCA requirements document maybe it = is better to talk about=20 >>>>=20 >>>> 1) Verification of the alert originator (this is the SIP stuff)=20 >>>> 2) Verification of the alert author (this is the alert stuff) >>>> 3) Integrity of alerts in transit (the TLS) >>>>=20 >>>> OK for you?=20 >>>>=20 >>>>=20 >>>> [BA] Yes, that is a better approach. >>>>=20 >>>=20 >>> I proposed text already that follows this type of structure - = although not with sub-section headings.=20 >>>=20 >>> Ciao >>> Hannes >>>=20 >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 From br@brianrosen.net Tue Jul 12 06:44:12 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D57B21F90D8 for ; Tue, 12 Jul 2011 06:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.735 X-Spam-Level: X-Spam-Status: No, score=-102.735 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSllGyLNZUf1 for ; Tue, 12 Jul 2011 06:44:11 -0700 (PDT) Received: from barracuda.canadianwebhosting.com (barmail2.idig.net [64.34.111.252]) by ietfa.amsl.com (Postfix) with ESMTP id 0F73C21F90D7 for ; Tue, 12 Jul 2011 06:44:11 -0700 (PDT) X-ASG-Debug-ID: 1310478249-04412114c6148100001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barracuda.canadianwebhosting.com with ESMTP id LuMRlGvTyznw4sQJ; Tue, 12 Jul 2011 06:44:09 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.255]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QgdFr-0000Xk-2z; Tue, 12 Jul 2011 06:44:08 -0700 Mime-Version: 1.0 (Apple Message framework v1084) X-ASG-Orig-Subj: Re: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01 Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: Date: Tue, 12 Jul 2011 09:43:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <218A5B2C-7978-4FA5-83C1-46C16370B8FB@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1084) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1310478249 X-Barracuda-URL: http://64.34.111.252:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at canadianwebhosting.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.68709 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 13:44:12 -0000 The problem with CAP is that none of the field content is standardized. = It's useful to a human, less so to an automaton without agreement = between senders and recipients on how to interpret the fields. The "parameter" thing is particularly difficult that way. About the only thing that CAP has that we would may want to see in the = sensor data section of Additional data about a Call is the = urgency/certainty/severity stuff. However, it is not so clear that when = you have a real call (an INVITE) that such information is actually so = useful. I could imagine allowing a CAP block in AdditionalData, but then we = would really have a lot of tails and dogs and ... Hmmmmm Maybe not. What if we DID allow a CAP block in Additional Data, and then made Data = Only a MESSAGE with a Call Info/Additional Data? =20 Brian On Jul 12, 2011, at 5:52 AM, Hannes Tschofenig wrote: > Hi Brian,=20 >=20 > On Jul 11, 2011, at 7:40 PM, Brian Rosen wrote: >=20 >> I am sorry I was not able to participate in this discussion. I think = it is heading in the wrong direction. >>=20 >> CAP is a wrapper for data related to an alert. It's a very common = wrapper, but it's just a wrapper. With respect to a citizen to = authority alert, it doesn't provide enough information by itself, and it = doesn't provide the kind of location based routing mechanisms we need = for these kinds of alerts. > Correct. For this reason the document assumes that location in the = form of a PIDF-LO is attached. I put text in there versions ago.=20 >=20 >>=20 >> The payload of the alert, that provides the information we need, = should be the "Additional Call Data" structure we are working on in = ecrit. >=20 > True. There may be additional data there as well. I could make this = explicit in the draft.=20 >=20 >>=20 >> We need a SIP mechanism to allow the -phonebcp routing we need for a = DATA ONLY alert. An alert of this kind has an important characteristic = uncommon with media sessions - there is no media session. MESSAGE has = the appropriate semantics when used in the "pager" mode. It's a one = time, no session, SIP transaction with the interesting part in the body = of the message. >=20 > In essence you are arguing that we should only stick with the MESSAGE = rather than allowing the CAP payload to be carried also in the INVITE = [RFC3261], UPDATE [RFC3311], INFO [RFC6086], NOTIFY [RFC3265], and = PUBLISH [RFC3903] messages. >=20 >=20 >>=20 >> If you have a media session, and what you want to do is send sensor = data in the INVITE, the Additional Call Data mechanism does that. This = mechanism is used only when you have no media, all you have is data. >=20 > Well. The additional call data as it is written now does not provide = the same amount of information as the CAP message. For example, if you = look at the example from = http://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-02#section-6 >=20 > > S-1 > sip:sensor1@domain.com > 2008-11-19T14:57:00-07:00 > Actual > Alert > Private > abc1234 > > Security > BURGLARY > Expected > Likely > Moderate > SENSOR 1 > > SENSOR-DATA-NAMESPACE1 > 123 > > > SENSOR-DATA-NAMESPACE2 > TRUE > > > >=20 > The block is not standardized so there is no difference to = the additional data either. Then, there are a few elements like = , , , , , , = etc. that do not have an equivalent in the additional data = structure at the moment. Of course one could question the usefulness of = these fields (which I sometimes do).=20 >=20 > Additionally, I wonder why we actually have to stick with an XML = encoding of the additional data (and with the CAP payload as well). It = is just verbose for no good reason. Why don't we use JSON? Just thinking = loud... > The JSON encoding would also allow us to have an implementable = end-to-end security solution (as a side remark).=20 >=20 >>=20 >> What this really means is that we could, if we wanted to, just put a = Call Info header on a MESSAGE transaction and treat it like a call, but = most of the sources we have talked to believed that CAP really should be = used for a one way alert. So, we put the CAP message in a SIP MESSAGE = transaction. >=20 > Ok. Fine with me. >=20 > Ciao > Hannes >=20 >>=20 >> Brian >>=20 >> On Jul 8, 2011, at 7:15 AM, Hannes Tschofenig wrote: >>=20 >>> I have updated the draft to reflect our discussion. Please find the = most recent version here: >>> = http://www.tschofenig.priv.at/svn/draft-rosen-ecrit-data-only-ea/draft-iet= f-ecrit-data-only-ea-02.txt >>>=20 >>> I now changed Section 4.1 that talks about the CAP transport:=20 >>>=20 >>> ----- >>>=20 >>> 4.1. CAP Transport >>>=20 >>> Since alerts structured via CAP require a "push" medium. The >>> following SIP requests MAY carry the CAP payload defined in this >>> document: INVITE [RFC3261], UPDATE [RFC3311], MESSAGE [RFC3428], = INFO >>> [RFC6086], NOTIFY [RFC3265], and PUBLISH [RFC3903]. The MIME type = is >>> set to 'application/cap+xml'. >>>=20 >>> If the server does not support the functionality required to fulfill >>> the request then a 501 Not Implemented MUST be returned by RFC 3261 >>> [RFC3261]. This is the appropriate response when a UAS does not >>> recognize the request method and is not capable of supporting it for >>> any user. >>>=20 >>> The 415 Unsupported Media Type error MUST be returned by RFC 3261 >>> [RFC3261] if the server is refusing to service the request because >>> the message body of the request is in a format not supported by the >>> server for the requested method. The server MUST return a list of >>> acceptable formats using the Accept, Accept-Encoding, or Accept- >>> Language header field, depending on the specific problem with the >>> content. >>>=20 >>> ----- >>>=20 >>> Ciao >>> Hannes >>>=20 >>> On Jul 8, 2011, at 10:50 AM, Hannes Tschofenig wrote: >>>=20 >>>> Hi Bernard,=20 >>>>=20 >>>> On Jul 8, 2011, at 2:49 AM, Bernard Aboba wrote: >>>>=20 >>>>> Hannes said: >>>>>=20 >>>>> The question is also whether we need to restrict the way a CAP = payload is sent to a recipient.=20 >>>>> One could argue that it does not really matter whether it is an = INVITE, a MESSAGE, or a PUBLISH.=20 >>>>> Which one is best depends on a specific environment.=20 >>>>>=20 >>>>> But you seem to be arguing that we should rather stick with the = INVITE instead of using MESSAGE.=20 >>>>> This would at least allow us to get the message understood by = every SIP device.=20 >>>>=20 >>>>> [BA] I have no problem with including CAP in MESSAGE. My major = concern was how to ensure interoperability and potential >>>>> problems that could delay emergency calls.=20 >>>>=20 >>>> Your suggestion to use INVITE seemed to be interesting but after = further thinking about it I am not sure whether the perceived level of = interoperability is worth sticking only with an INVITE. If the recipient = does not understand the CAP payload (and only the INVITE itself) then = there is still no interoperability.=20 >>>>=20 >>>> As such, I believe I have to put text in there regarding error = messages and the core SIP spec already provides them, namely=20 >>>> * 501 Not Implemented, and=20 >>>> * 415 Unsupported Media Type >>>>=20 >>>> I am still thinking whether we should allow the CAP payload to be = used in an INVITE, a MESSAGE, an a PUBLISH. >>>>=20 >>>>>=20 >>>>> This is just an example. Using TCP indeed makes sense for = XML-based payloads.=20 >>>>> I don't think we want to mandate that TCP is mandatory-to-use.=20 >>>>>=20 >>>>> [BA] I agree that we don't want to mandate use. But we are = talking about emergency calls, so making a recommendation on how to = avoid problems is probably a good idea.=20 >>>>>=20 >>>>> I assume that the device that issues the alert is actually an = IP-based device.=20 >>>>> For me the story begins with the first IP device.=20 >>>>=20 >>>>>=20 >>>>> [BA] My problem with signatures is in emergency contexts is the = cost and value of validating them. In ATOCA there may >>>>> be a model for this (e.g. government signs the CAP), but in a = device scenario, it's not easy to figure out how a PSAP would >>>>> validate the signature or what value it would have.=20 >>>>=20 >>>> I agree with you that most deployments will in their judgements = about the security threats conclude that they do not need to = additionally sign the CAP message and instead rely on the SIP security = mechanisms. That's my assumption. Still, the security consideration = section lays out the options.=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> With SIP Identity the identity header is either added by the end = point (unlikely) or by the outbound proxy.=20 >>>>> If it is added by the outbound proxy then there has to be TLS = between the end point and the outbound proxy.=20 >>>>> This would provide proper protection of the message exchange and = would fulfill our purpose here. Wouldn't you say so?=20 >>>>>=20 >>>>> [BA] TLS is fine with me -- but it solves a different problem than = RFC 4474. >>>>=20 >>>> In the typical use case of SIP Identity (at least as envisioned in = the specification) the identity assertion is added by the Authentication = service (e.g. the outbound proxy) and there still has to be security = provided from the end host to that Authentication Service. This may = likely come in form of TLS since otherwise the identity assurance is of = little value if the adversary is sitting somewhere along that path.=20 >>>>=20 >>>>>=20 >>>>> True. There is the SIP identity of the sender, the field in the = CAP message (sender field), and then there is cryptographic material in = case of a signature that will have some identity information associated = with it.=20 >>>>> Currently, the draft says that we should set the sender field of = the CAP message to the value of the sender of the SIP message. Useful to = set to two equal? >>>>>=20 >>>>> [BA] That is useful if the CAP sender and SIP sender are actually = the same. If not, then the CAP sender field should reflect who composed = the CAP.=20 >>>>>=20 >>>>=20 >>>> I put text into the draft already about the case where the two are = different.=20 >>>>=20 >>>>> I am OK with not focusing on security threats as the document = currently does, but instead focus on the solutions.=20 >>>>> Using the terminology from the ATOCA requirements document maybe = it is better to talk about=20 >>>>>=20 >>>>> 1) Verification of the alert originator (this is the SIP stuff)=20 >>>>> 2) Verification of the alert author (this is the alert stuff) >>>>> 3) Integrity of alerts in transit (the TLS) >>>>>=20 >>>>> OK for you?=20 >>>>>=20 >>>>>=20 >>>>> [BA] Yes, that is a better approach. >>>>>=20 >>>>=20 >>>> I proposed text already that follows this type of structure - = although not with sub-section headings.=20 >>>>=20 >>>> Ciao >>>> Hannes >>>>=20 >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>=20 >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >=20 From br@brianrosen.net Tue Jul 12 07:19:17 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1644321F9132 for ; Tue, 12 Jul 2011 07:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.734 X-Spam-Level: X-Spam-Status: No, score=-102.734 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGudJb5ddHrN for ; Tue, 12 Jul 2011 07:19:16 -0700 (PDT) Received: from barracuda.canadianwebhosting.com (barmail2.idig.net [64.34.111.252]) by ietfa.amsl.com (Postfix) with ESMTP id 2407821F8E3A for ; Tue, 12 Jul 2011 07:19:16 -0700 (PDT) X-ASG-Debug-ID: 1310480334-04412114c7148610001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barracuda.canadianwebhosting.com with ESMTP id X2ASmHXH1aJBGEJ6 for ; Tue, 12 Jul 2011 07:18:57 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.255]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QgdnN-00083T-V2 for ecrit@ietf.org; Tue, 12 Jul 2011 07:18:48 -0700 From: Brian Rosen Content-Type: multipart/alternative; boundary=Apple-Mail-15--686847948 Date: Tue, 12 Jul 2011 10:18:37 -0400 X-ASG-Orig-Subj: Re: [Ecrit] I-D ACTION:draft-ietf-ecrit-additional-data-01.txt References: <20110712001502.5260.47130.idtracker@ietfa.amsl.com> To: "ecrit@ietf.org Org" Message-Id: <1445A4D4-8DC8-4D3F-A74B-D8B51AE10AA1@brianrosen.net> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1310480335 X-Barracuda-URL: http://64.34.111.252:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at canadianwebhosting.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE, MIME_HTML_MOSTLY X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.68711 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 MIME_HTML_MOSTLY BODY: Multipart message mostly text/html MIME 0.00 HTML_MESSAGE BODY: HTML included in message Subject: Re: [Ecrit] I-D ACTION:draft-ietf-ecrit-additional-data-01.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 14:19:17 -0000 --Apple-Mail-15--686847948 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This version contains a start at restructuring the data into "blocks", = each of which has a MIME type. The data provider can send any set of = these blocks (Multipart) that it has available. There are 3 mechanisms = described to pass these blocks: a) a URI in a Call Info header leading to an HTTP GET of the set of = blocks b) a CID in a Call Info header leading to the blocks in the body of an = INVITE or MESSAGE c) a provided-by in a PIDF The latter is the mechanism used by the access network to send data = (mostly identification and subscriber data). I did not have time to finish this effort. I'd appreciate some prompt = feedback, which I will attempt to roll into an update that I will try to = get out when the I-D window opens up again. Brian Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: July 11, 2011 8:15:02 PM EDT > To: i-d-announce@ietf.org > Cc: ecrit@ietf.org > Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-additional-data-01.txt >=20 > 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. >=20 > Title : Additional Data related to an Emergency Call > Author(s) : B. Rosen, et al > Filename : draft-ietf-ecrit-additional-data-01.txt > Pages : 25 > Date : 2011-07-11 >=20 > When an emergency call is sent to a PSAP, the device that sends it, > as well as any service provider in the path of the call, or access > network may have information about the call which the PSAP may be > able to use. This document describes an XML data structure that > contains this kind of information in a standardized form. A URI = that > points to the structure can be included in the SIP signaling with = the > call, or the data may be included in the body of a SIP message. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-ecrit-additional-data-01.tx= t >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --Apple-Mail-15--686847948 Content-Type: multipart/mixed; boundary=Apple-Mail-16--686847947 --Apple-Mail-16--686847947 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This = version contains a start at restructuring the data into "blocks", each = of which has a MIME type.  The data provider can send any set of = these blocks (Multipart) that it has available.  There are 3 = mechanisms described to pass these blocks:
a) a URI in a Call Info = header leading to an HTTP GET of the set of blocks
b) a CID in = a Call Info header leading to the blocks in the body of an INVITE or = MESSAGE
c) a provided-by in a = PIDF

The latter is the mechanism used by the = access network to send data (mostly identification and subscriber = data).

I did not have time to finish this = effort.  I'd appreciate some prompt feedback, which I will attempt = to roll into an update that I will try to get out when the I-D window = opens up again.

Brian

Begin = forwarded message:

Date: July 11, 2011 8:15:02 PM EDT
Subject: [Ecrit] I-D = ACTION:draft-ietf-ecrit-additional-data-01.txt

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 =         : Additional Data = related to an Emergency Call
   Author(s) =     : B. Rosen, et al
   Filename =      : = draft-ietf-ecrit-additional-data-01.txt
   Pages =         : 25
=    Date =          : = 2011-07-11

When an emergency call is sent to a PSAP, the device = that sends it,
  as well as any service provider in the = path of the call, or access
  network may have information = about the call which the PSAP may be
  able to use. =  This document describes an XML data structure that
=   contains this kind of information in a standardized form. =  A URI that
  points to the structure can be included = in the SIP signaling with the
  call, or the data may be = included in the body of a SIP message.


A URL for this = Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-additional= -data-01.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.
= --Apple-Mail-16--686847947 Content-Disposition: attachment; filename="Mail Attachment" Content-Type: message/external-body; name="Mail Attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain
Content-ID: <2011-07-11170552.I-D@ietf.org>

--Apple-Mail-16--686847947 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

--Apple-Mail-16--686847947-- --Apple-Mail-15--686847948-- From Hannes.Tschofenig@gmx.net Tue Jul 12 12:51:36 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C66FC9E800A for ; Tue, 12 Jul 2011 12:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZFzy+bZ1awZ for ; Tue, 12 Jul 2011 12:51:35 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 191AE9E801C for ; Tue, 12 Jul 2011 12:51:29 -0700 (PDT) Received: (qmail invoked by alias); 12 Jul 2011 19:51:26 -0000 Received: from letku101.adsl.netsonic.fi (EHLO [10.0.0.6]) [194.29.195.101] by mail.gmx.net (mp025) with SMTP; 12 Jul 2011 21:51:26 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/CMG46Nd/C2CeSG+CMYNTuIHiukfp2c+cRQdZS1o GXLMp754RxAS+D Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Hannes Tschofenig In-Reply-To: Date: Tue, 12 Jul 2011 22:51:24 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <316330C5-7AAA-4020-9B3C-3BA64335348D@gmx.net> References: <218A5B2C-7978-4FA5-83C1-46C16370B8FB@gmx.net> To: Brian Rosen X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 19:51:36 -0000 Hi Brian,=20 On Jul 12, 2011, at 4:43 PM, Brian Rosen wrote: > What if we DID allow a CAP block in Additional Data, and then made = Data Only a MESSAGE with a Call Info/Additional Data? =20 Let's look at the fields and see what we actually need. Below is the = list of elements from the CAP specification.=20 As you said in your earlier mail we cover the case where no session is = established.=20 "alert" Element and Sub-elements ---------------------------------------------- * : The identifier of the alert message [hannes] Having an identifier for the message would be useful but don't = we have it already within SIP? * : The identifier of the sender of the alert message [hannes] This is also available via SIP unless we want to differentiate = the entity that sends the SIP message vs. the entity that created the = additional data.=20 * : The time and date of the origination of the alert message [hannes] This is also information available in SIP.=20 * : The code denoting the appropriate handling of the alert = message Code Values: =93Actual=94 - Actionable by all targeted recipients =93Exercise=94- Actionable only by designated exercise participants; = exercise identifier should appear in =93System=94 - For messages that support alert network internal = functions. =93Test=94 - Technical testing only, all recipients disregard =93Draft=94 =96 A preliminary template or draft, not actionable in its = current form. [hannes] We have a mechanism for testing emergency calls and alerts = already. The others do not make sense in our context.=20 * : The code denoting the nature of the alert message Code Values: =93Alert=94 - Initial information requiring attention by targeted = recipients =93Update=94 - Updates and supercedes the earlier message(s) identified = in =93Cancel=94 - Cancels the earlier message(s) identified in =93Ack=94 - Acknowledges receipt and acceptance of the message(s)) = identified in =93Error=94 indicates rejection of the message(s) identified in = ; explanation SHOULD appear in [hannes] I am not sure whether we need a protocol mechanism since the = alert msg itself. If a device sends data about an emergency then they = can always send further alert messages with more info.=20 But maybe this is useful where a human is somewhere in the loop.=20 * : The text identifying the source of the alert message The particular source of this alert; e.g., an operator or a specific = device. [hannes] We have much more data as part of our additional data spec.=20 * : The code denoting the intended distribution of the alert = message Code Values: =93Public=94 - For general dissemination to unrestricted audiences =93Restricted=94 - For dissemination only to users with a known = operational requirement (see , below) =93Private=94 - For dissemination only to specified addresses (see =
, below) [hannes] We have better ways in PIDF-LO to restrict the information via = the rules.=20 * : The text describing the rule for limiting distribution = of the restricted alert message [hannes] We have better ways in PIDF-LO to restrict the information via = the rules.=20 * : The group listing of intended recipients of the private = alert message [hannes] The SIP message already indicates the recipient.=20 * : The code denoting the special handling of the alert message [hannes] not further defined and hence underspecified.=20 * : The text describing the purpose or significance of the alert = message [hannes] Any clear text field will be less useful for our purpose; who = should type the text?=20 * : The group listing identifying earlier message(s) = referenced by the alert message [hannes] This is useful in context of the * : The group listing naming the referent incident(s) of the = alert message [hannes] An incident identifier is useful although quite difficult to = set for the end device. "info" Element and Sub-elements --------------------------------------------- * : The code denoting the language of the info sub- element of = the alert message [hannes] This information refers to the text in the alert. Since we = would not use clear text it would be less useful.=20 A language tag for the user itself is useful but already in SIP.=20 * : The code denoting the category of the subject event of the = alert message (1) Code Values: =93Geo=94 - Geophysical (inc. landslide) =93Met=94 - Meteorological (inc. flood) =93Safety=94 - General emergency and public safety =93Security=94 - Law enforcement, military, homeland and local/private = security =93Rescue=94 - Rescue and recovery =93Fire=94 - Fire suppression and rescue =93Health=94 - Medical and public health =93Env=94 - Pollution and other environmental =93Transport=94 - Public and private transportation =93Infra=94 - Utility, telecommunication, other non-transport = infrastructure =93CBRNE=94 =96 Chemical, Biological, Radiological, Nuclear or = High-Yield Explosive threat or attack =93Other=94 - Other events [hannes] This may be useful to provide additional information about the = alert message, for example in a sensor context. =20 * : The text denoting the type of the subject event of the alert = message [hannes] Clear text field again.=20 * : The code denoting the type of action recommended for = the target audience. (1) Code Values: =93Shelter=94 =96 Take shelter in place or per =93Evacuate=94 =96 Relocate as instructed in the =93Prepare=94 =96 Make preparations per the =93Execute=94 =96 Execute a pre-planned activity identified in = =93Monitor=94 =96 Attend to information sources as described in = =93Assess=94 =96 Evaluate the information in this message. (This value = SHOULD NOT be used in public warning applications.) =93None=94 =96 No action recommended [hannes] We don't need this field since the end device should not tell = the PSAP what to do. * : The code denoting the urgency of the subject event of the = alert message (1) The =93urgency=94, =93severity=94, and =93certainty=94 elements = collectively distinguish less emphatic from more emphatic messages. (2) Code Values: =93Immediate=94 - Responsive action SHOULD be taken immediately =93Expected=94 - Responsive action SHOULD be taken soon (within next = hour) =93Future=94 - Responsive action SHOULD be taken in the near future =93Past=94 - Responsive action is no longer required =93Unknown=94 - Urgency not known [hannes] I cannot come up with useful cases for our deployment context.=20= * : The code denoting the severity of the subject event of the = alert message 1) The =93urgency=94, =93severity=94, and =93certainty=94 elements = collectively distinguish less emphatic from more emphatic messages. (2) Code Values: =93Extreme=94 - Extraordinary threat to life or property =93Severe=94 - Significant threat to life or property =93Moderate=94 - Possible threat to life or property =93Minor=94 - Minimal threat to life or property =93Unknown=94 - = Severity unknown [hannes] Sounds nice but how are these values set automatically.=20 * : The code denoting the certainty of the subject event of = the alert message (1) The =93urgency=94, =93severity=94, and =93certainty=94 elements = collectively distinguish less emphatic from more emphatic messages. (2) Code Values: =93Observed=94 =96 Determined to have occurred or to be ongoing. =93Likely=94 - Likely (p > ~50%) =93Possible=94 - Possible but not likely (p <=3D ~50%) =93Unlikely=94 - Not expected to occur (p ~ 0) =93Unknown=94 - Certainty unknown [hannes] Same as above.=20 * : The text describing the intended audience of the alert = message [hannes] Clear text.=20 * : A system- specific code identifying the event type of the = alert message [hannes] underspecified.=20 * : The effective time of the information of the alert = message * : The expected time of the beginning of the subject event of = the alert message * : The expiry time of the information of the alert message [hannes] While these fields may be useful for early warning scenarios = they are less obvious for=20 * : The text naming the originator of the alert message [hannes] Clear text; we have information about the originator already in = other places.=20 * : The text headline of the alert message [hannes] Not useful=20 * : The text describing the subject event of the alert = message [hannes] clear text again. * : The text describing the recommended action to be taken = by recipients of the alert message [hannes] Not useful for the UA-to-PSAP communication.=20 * : The identifier of the hyperlink associating additional = information with the alert message [hannes] also in the additional data=20 * : The text describing the contact for follow-up and = confirmation of the alert message [hannes] information in the additional data.=20 * : A system- specific additional parameter associated with = the alert message [hannes] underspecified. A small note: Those who want to provide some sensor specific information = are better advised to make use of a document like "Media Type for Sensor = Markup Language (SENML)" . The abstract of = the document says:=20 This specification defines media types for representing simple sensor measurements in JSON. A simple sensor, such as a temperature sensor, could use this media type in protocols such as HTTP to transport the values of a sensor. =20 =20 "resource" Element and Sub-elements ---------------------------------------------------- [hannes] These fields are useful since we want to attach additional data = to the data-only call but we do not need to stuff this into the CAP = message. We could instead, as the additional data draft suggests, = concatenate MIME types in a SIP msg.=20 * : The text describing the type and content of the = resource file. The human-readable text describing the content and kind, = such as =93map=94 or =93photo,=94 of the resource file. * : The identifier of the MIME content type and sub-type = describing the resource file * : The integer indicating the size of the resource file * : The identifier of the hyperlink for the resource file * : The base-64 encoded data content of the resource file * : The code representing the digital digest (=93hash=94) = computed from the resource file "area" Element and Sub-elements ----------------------------------------------- [hannes] We have already noticed earlier that the area elements do not = meet our needs. We have a better mechanism with the PIDF-LO.=20 * : The text describing the affected area of the alert message + various location shapes: geocode, circle, polygon, altitude, ceiling=20= Ciao Hannes From hgs@cs.columbia.edu Tue Jul 12 14:39:48 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E78521F899C; Tue, 12 Jul 2011 14:39:48 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+h9todwP9wg; Tue, 12 Jul 2011 14:39:44 -0700 (PDT) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by ietfa.amsl.com (Postfix) with ESMTP id 07CD021F87D3; Tue, 12 Jul 2011 14:39:43 -0700 (PDT) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id p6CLdfAT021116 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 12 Jul 2011 17:39:42 -0400 (EDT) From: Henning Schulzrinne Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Jul 2011 17:39:41 -0400 Message-Id: <50E1B44C-2A56-49FF-8DEA-A9927630FE32@cs.columbia.edu> To: GEOPRIV WG , ECRIT Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Subject: [Ecrit] FCC action on location accuracy and related issues X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 21:39:48 -0000 http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-308377A1.pdf There will be opportunities for further comment on items very relevant = to both working groups, so you might want to check the FCC web site for = details as the items are released and consider submitting comments. Henning= From hannes.tschofenig@gmx.net Wed Jul 13 02:21:13 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D74E11E8076 for ; Wed, 13 Jul 2011 02:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZXOZ-PmICvc for ; Wed, 13 Jul 2011 02:21:12 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 6A1A221F8B88 for ; Wed, 13 Jul 2011 02:21:11 -0700 (PDT) Received: (qmail invoked by alias); 13 Jul 2011 09:21:09 -0000 Received: from letku214.adsl.netsonic.fi (EHLO [10.0.0.6]) [194.29.195.214] by mail.gmx.net (mp022) with SMTP; 13 Jul 2011 11:21:09 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/Sxk9L6DDSjoanm6RVX2j1PxXjT3oF0wV/bDn8Ht fniiqA4W+oCPnW Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <20110615212629.9737.88852.idtracker@ietfa.amsl.com> Date: Wed, 13 Jul 2011 12:21:08 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <64D47317-0D25-40FA-8D08-B256096660F1@gmx.net> References: <20110615212629.9737.88852.idtracker@ietfa.amsl.com> To: "ietf@ietf.org IETF" , ecrit@ietf.org X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: Re: [Ecrit] Last Call: (IANA Registering a SIP Resource Priority Header Field Namespace for Local Emergency Communications) to Proposed Standard X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 09:21:13 -0000 Reading through the document I fail to see the clearly stated = restriction that this is not to be used between the emergency caller's = UA and the VSP/ASP's network (for VSP/ASP routed calls) or between the = UA and the PSAP (for directly routed calls).=20 I was in the believe that the scope is restricted only to PSAP-to-first = Responder, and PSAP-to-PSAP communication.=20 It might also be useful to add that this document did not make it = through the ECRIT working group. The document type is Standards Track = and might give the impression that there is wide consensus behind the = document -- but there isn't. IETF last calls may add a lot of value but = I do not see that anyone had pointed to the various discussions in the = ECRIT mailing list on that topic.=20 I was always of the impression that the mechanism does not lead to any = useful outcome. See previous discussions:=20 Hannes: http://www.ietf.org/mail-archive/web/ecrit/current/msg05940.html Henning: = http://www.ietf.org/mail-archive/web/ecrit/current/msg05941.html JamesW: http://www.ietf.org/mail-archive/web/ecrit/current/msg05945.html For those who have not followed the work I would like to point out that = we have an "marking" (or call it indication) of an emergency call = already, it is called a Service URN - RFC 5031. How many times do we = need to again identify that a call (or a message) is an emergency call?=20= The document interestingly talks about closed networks or controlled = environments where this is supposed to be used. I don't believe it is = useful to do so because this leaves the door open to use the mechanism = anywhere. Often, these networks are not as closed as we think.=20 This new namespace can be included in SIP requests to provide an explicit priority indication within controlled environments, such as an IMS infrastructure or Emergency Services network (ESInet) where misuse can be reduced to a minimum because these types of networks have great controls in place. Btw, what are these >>great<< controls?=20 My comments are addressed if the document (in the introduction) makes it = clear that UAs' MUST NOT include this RP namespace in an outgoing = emergency call because there is already the Service URN marking that = classifies the call as an emergency call.=20 We had already agreed on this a long time ago, see = http://www.ietf.org/mail-archive/web/ecrit/current/msg05960.html. Still, = the text in the introduction and in the security consideration is very = fuzzy and in my view intentionally does not make the case clear to leave = it up to interpretation.=20 It is ironic that this document manages to get finished before the major = work of the ECRIT group, namely PhoneBCP, and ECRIT framework, get = completed. (Or the SIPCORE SIP location conveyance for that matter as = well.)=20 Why would someone want to go with their work through a working group = when they can get a Standards Track document faster and easier?=20 Ciao Hannes On Jun 16, 2011, at 12:26 AM, The IESG wrote: >=20 > The IESG has received a request from an individual submitter to = consider > the following document: > - 'IANA Registering a SIP Resource Priority Header Field Namespace for > Local Emergency Communications' > as a Proposed > Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2011-07-13. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > This document creates the new Session Initiation Protocol (SIP) > Resource Priority header field namespace "esnet" for local emergency > usage to a public safety answering point (PSAP), between PSAPs, and > between a PSAP and first responders and their organizations, and > places this namespace in the IANA registry. >=20 >=20 >=20 >=20 > The file can be obtained via > = http://datatracker.ietf.org/doc/draft-polk-local-emergency-rph-namespace/ >=20 > IESG discussion can be tracked via > = http://datatracker.ietf.org/doc/draft-polk-local-emergency-rph-namespace/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From keith.drage@alcatel-lucent.com Wed Jul 13 04:59:31 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 345FC11E8099; Wed, 13 Jul 2011 04:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.189 X-Spam-Level: X-Spam-Status: No, score=-106.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahHYJHQBd39X; Wed, 13 Jul 2011 04:59:30 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 27FC911E8086; Wed, 13 Jul 2011 04:59:30 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p6DBxH9n007055 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 13 Jul 2011 13:59:25 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 13 Jul 2011 13:59:20 +0200 From: "DRAGE, Keith (Keith)" To: Hannes Tschofenig , "ietf@ietf.org IETF" , "ecrit@ietf.org" Date: Wed, 13 Jul 2011 13:59:18 +0200 Thread-Topic: [Ecrit] Last Call: (IANA Registering a SIP Resource Priority Header Field Namespace for Local Emergency Communications) to Proposed Standard Thread-Index: AcxBPn6uuS0dG300QguqVSnnsBhD8gAFQbTQ Message-ID: References: <20110615212629.9737.88852.idtracker@ietfa.amsl.com> <64D47317-0D25-40FA-8D08-B256096660F1@gmx.net> In-Reply-To: <64D47317-0D25-40FA-8D08-B256096660F1@gmx.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: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Subject: Re: [Ecrit] Last Call: (IANA Registering a SIP Resource Priority Header Field Namespace for Local Emergency Communications) to Proposed Standard X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 11:59:31 -0000 If you insist on that scope > I was in the believe that the scope is restricted only to PSAP-to-first > Responder, and PSAP-to-PSAP communication. Then you can throw it away. I certainly don't see it being used by an emergency calling UA, but in a 3G= PP like solution to emergency calling, there is no reason why it cannot be = used by the first network operator provided entity that identifies an emerg= ency call. I agree it is not applicable to the IETF solution, but then you = have no network operator to provide you with priority in the first place. If a network operator want to provide priority in their equipment after poi= nt of entry to the network, to an emergency call, then RPH is the sensible = way of doing it, and not forcing them to recognize multiple different param= eters to identify that priority is needed. You seem to be back in cloud cuckoo land where you believe all emergency ca= lls are handled by the IETF ECRIT solution. Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Hannes Tschofenig > Sent: 13 July 2011 10:21 > To: ietf@ietf.org IETF; ecrit@ietf.org > Subject: Re: [Ecrit] Last Call: 01.txt> (IANA Registering a SIP Resource Priority Header Field Namespace > for Local Emergency Communications) to Proposed Standard >=20 > Reading through the document I fail to see the clearly stated restriction > that this is not to be used between the emergency caller's UA and the > VSP/ASP's network (for VSP/ASP routed calls) or between the UA and the > PSAP (for directly routed calls). > I was in the believe that the scope is restricted only to PSAP-to-first > Responder, and PSAP-to-PSAP communication. >=20 > It might also be useful to add that this document did not make it through > the ECRIT working group. The document type is Standards Track and might > give the impression that there is wide consensus behind the document -- > but there isn't. IETF last calls may add a lot of value but I do not see > that anyone had pointed to the various discussions in the ECRIT mailing > list on that topic. >=20 > I was always of the impression that the mechanism does not lead to any > useful outcome. See previous discussions: > Hannes: http://www.ietf.org/mail-archive/web/ecrit/current/msg05940.html > Henning: http://www.ietf.org/mail-archive/web/ecrit/current/msg05941.html > JamesW: http://www.ietf.org/mail-archive/web/ecrit/current/msg05945.html >=20 > For those who have not followed the work I would like to point out that w= e > have an "marking" (or call it indication) of an emergency call already, i= t > is called a Service URN - RFC 5031. How many times do we need to again > identify that a call (or a message) is an emergency call? >=20 > The document interestingly talks about closed networks or controlled > environments where this is supposed to be used. I don't believe it is > useful to do so because this leaves the door open to use the mechanism > anywhere. Often, these networks are not as closed as we think. >=20 > This new namespace can be included in SIP requests to provide an > explicit priority indication within controlled environments, such as > an IMS infrastructure or Emergency Services network (ESInet) where > misuse can be reduced to a minimum because these types of networks > have great controls in place. >=20 > Btw, what are these >>great<< controls? >=20 > My comments are addressed if the document (in the introduction) makes it > clear that UAs' MUST NOT include this RP namespace in an outgoing > emergency call because there is already the Service URN marking that > classifies the call as an emergency call. > We had already agreed on this a long time ago, see > http://www.ietf.org/mail-archive/web/ecrit/current/msg05960.html. Still, > the text in the introduction and in the security consideration is very > fuzzy and in my view intentionally does not make the case clear to leave > it up to interpretation. >=20 > It is ironic that this document manages to get finished before the major > work of the ECRIT group, namely PhoneBCP, and ECRIT framework, get > completed. (Or the SIPCORE SIP location conveyance for that matter as > well.) > Why would someone want to go with their work through a working group when > they can get a Standards Track document faster and easier? >=20 > Ciao > Hannes >=20 > On Jun 16, 2011, at 12:26 AM, The IESG wrote: >=20 > > > > The IESG has received a request from an individual submitter to conside= r > > the following document: > > - 'IANA Registering a SIP Resource Priority Header Field Namespace for > > Local Emergency Communications' > > as a Proposed > > Standard > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to the > > ietf@ietf.org mailing lists by 2011-07-13. Exceptionally, comments may > be > > sent to iesg@ietf.org instead. In either case, please retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > > > This document creates the new Session Initiation Protocol (SIP) > > Resource Priority header field namespace "esnet" for local emergency > > usage to a public safety answering point (PSAP), between PSAPs, and > > between a PSAP and first responders and their organizations, and > > places this namespace in the IANA registry. > > > > > > > > > > The file can be obtained via > > http://datatracker.ietf.org/doc/draft-polk-local-emergency-rph- > namespace/ > > > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-polk-local-emergency-rph- > namespace/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > _______________________________________________ > > IETF-Announce mailing list > > IETF-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf-announce >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From hgs@cs.columbia.edu Fri Jul 15 09:53:05 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2A521F8B71; Fri, 15 Jul 2011 09:53:05 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RT2u9CdWCNa7; Fri, 15 Jul 2011 09:53:01 -0700 (PDT) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by ietfa.amsl.com (Postfix) with ESMTP id CA52021F8B75; Fri, 15 Jul 2011 09:52:49 -0700 (PDT) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id p6FGqa17026570 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 15 Jul 2011 12:52:47 -0400 (EDT) From: Henning Schulzrinne Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Jul 2011 12:52:36 -0400 Message-Id: To: GEOPRIV WG , ECRIT Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Subject: [Ecrit] Text of FCC location accuracy report & order and FNPRM X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 16:53:05 -0000 You can now find the complete official text at = http://transition.fcc.gov/Daily_Releases/Daily_Business/2011/db0713/FCC-11= -107A1.pdf Comments are appreciated in the dockets named (07-114 etc.); if you need = help with the logistics of submitting comments, please let me know. = Anybody can submit comments - you do not have to be a lawyer, US citizen = or corporation. Speaking personally, comments that provide factual, = verifiable and technical information rather than just statements of = opinion are particularly helpful. (Comments will be read by both lawyers = and engineers, so there is no need to dumb them down for either group.) = With very limited exceptions, all comments are public, so you can see = what others write. Henning (not speaking for the FCC, but working there)= From hgs@cs.columbia.edu Fri Jul 22 10:03:40 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A112721F8B32 for ; Fri, 22 Jul 2011 10:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UovU5SZ6-dJ3 for ; Fri, 22 Jul 2011 10:03:39 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6E021F8B27 for ; Fri, 22 Jul 2011 10:03:39 -0700 (PDT) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id p6MH3cvF011915 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 22 Jul 2011 13:03:38 -0400 (EDT) From: Henning Schulzrinne Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Jul 2011 13:03:38 -0400 Message-Id: <329BE331-C04B-4D30-BFE1-BD917C20EB94@cs.columbia.edu> To: ECRIT Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8 Subject: [Ecrit] Survey on emergency communication needs for people with disabilities X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 17:03:40 -0000 The FCC Emergency Access Advisory Committee (EAAC) has published the = results of a survey that detail the needs of people with disabilities: http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-308532A1.pdf The EAAC will use these results to make recommendations to the = Commission in the coming months. See = http://transition.fcc.gov/cgb/dro/EAAC/ for background on the committee. Henning= From christer.holmberg@ericsson.com Sat Jul 23 08:55:27 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4627621F89C1 for ; Sat, 23 Jul 2011 08:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuP7GaWP8Bkv for ; Sat, 23 Jul 2011 08:55:26 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id CD47321F898F for ; Sat, 23 Jul 2011 08:55:20 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-a3-4e2aeee71d6d Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 01.71.20773.7EEEA2E4; Sat, 23 Jul 2011 17:55:19 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.123]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Sat, 23 Jul 2011 17:55:18 +0200 From: Christer Holmberg To: "Thomson, Martin" Date: Sat, 23 Jul 2011 17:55:17 +0200 Thread-Topic: PSAP callback Thread-Index: Acw1Xjl8KWX6PyjFSeORSy+kDda55QTMjspA Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB647051B@ESESSCMS0356.eemea.ericsson.se> References: <8B0A9FCBB9832F43971E38010638454F040B26C9D9@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F040B26C9D9@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP callback X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 15:55:27 -0000 Hi Martin, Thanks for your comments! Unfortunately, due to summer vacations etc, it to= ok a while for me to reply. Sorry for that.=20 Comments inline. >The idea that I recall being floated is very similar to the=20 >one I see proposed here. That used a GRUU but no explicit=20 >tag. This is subtly different and I can't see a reason why=20 >it is better. >=20 >This could be a very simple thing to specify. Adding the tag=20 >could actually make it harder. =09 I am not religious regarding the protocol mechanism. The important thing is= having *A* mechanism that: 1. Ensures that the PSAP callback call reaches the same device that made th= e associated emergency call; and 2. Identities that the call is a PSAP callback call. Also, in order to prevent fraud, the callback indicator would need to be as= serted by the network. Regarding the suggestion to use GRUU, I assume a UA, before making the emer= gency call (eCALL), would perform an "emergency registration" (eREG), in or= der to retieve the "emergency gruu" (eGRUU). One question is: if the UA deregisters the eREG after the eCALL, would the = callback call still reach the UA? Regards, Christer From Martin.Thomson@commscope.com Sat Jul 23 10:04:40 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73AE121F8AFB for ; Sat, 23 Jul 2011 10:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdnlbn+RJczk for ; Sat, 23 Jul 2011 10:04:40 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id E4CCF21F8AE6 for ; Sat, 23 Jul 2011 10:04:39 -0700 (PDT) X-AuditID: 0a0404e9-b7cc4ae00000074e-bd-4e2aff302d9a Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id FB.19.01870.03FFA2E4; Sat, 23 Jul 2011 12:04:48 -0500 (CDT) Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.159.2; Sat, 23 Jul 2011 12:04:39 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Sun, 24 Jul 2011 01:04:36 +0800 From: "Thomson, Martin" To: Christer Holmberg Date: Sun, 24 Jul 2011 01:04:35 +0800 Thread-Topic: PSAP callback Thread-Index: Acw1Xjl8KWX6PyjFSeORSy+kDda55QTMjspAADIO62A= Message-ID: <8B0A9FCBB9832F43971E38010638454F040D2C32F8@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F040B26C9D9@SISPE7MB1.commscope.com> <7F2072F1E0DE894DA4B517B93C6A05851DB647051B@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851DB647051B@ESESSCMS0356.eemea.ericsson.se> 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-Brightmail-Tracker: AAAAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP callback X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 17:04:40 -0000 On 2011-07-23 at 11:55:17, Christer Holmberg wrote: > I am not religious regarding the protocol mechanism. The important=20 > thing is having *A* mechanism that: I'm not religious. > 1. Ensures that the PSAP callback call reaches the same device that=20 > made the associated emergency call; and Right. > 2. Identities that the call is a PSAP callback call. You need to be clearer here: identifies to whom? It would be relatively ea= sy to identify to the UA, but less easy for a proxy that has no prior inter= action with the call. > Also, in order to prevent fraud, the callback indicator would need to=20 > be asserted by the network. Specifically what sort of fraud? Callbacks are usually charged as normal, = so the only potential problem here is circumvention of normal call screenin= g (redirection to voice mail, and so on), and then only when those sorts of= policies are suppressed. It's entirely possible that callbacks will be treated like normal calls. T= hen I see very little reason to spend additional effort in special markings= . > Regarding the suggestion to use GRUU, I assume a UA, before making the=20 > emergency call (eCALL), would perform an "emergency registration" > (eREG), in order to retieve the "emergency gruu" (eGRUU). That's possible. It's also possible to simply register a pseudo-instance s= o that you get an extra GRUU (eGRUU) that you only use for emergency calls.= If that extra GRUU is only used for emergency calls, then all calls direc= ted to it are probably callbacks. You can then associate special policy (suppress some call screening) for ca= lls directed to that particular GRUU, but I'm not aware of any burning need= to do so. > One question is: if the UA deregisters the eREG after the eCALL, would=20 > the callback call still reach the UA? Does it matter? Cheers, Martin From christer.holmberg@ericsson.com Sat Jul 23 10:42:32 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F0721F8AFB for ; Sat, 23 Jul 2011 10:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.543 X-Spam-Level: X-Spam-Status: No, score=-6.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxvDKLMllPtn for ; Sat, 23 Jul 2011 10:42:32 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCA821F8AE6 for ; Sat, 23 Jul 2011 10:42:31 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-ab-4e2b080611e0 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id B8.33.20773.6080B2E4; Sat, 23 Jul 2011 19:42:31 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.123]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Sat, 23 Jul 2011 19:42:30 +0200 From: Christer Holmberg To: "Thomson, Martin" Date: Sat, 23 Jul 2011 19:42:22 +0200 Thread-Topic: PSAP callback Thread-Index: Acw1Xjl8KWX6PyjFSeORSy+kDda55QTMjspAADIO62AAAWUbIA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB647051F@ESESSCMS0356.eemea.ericsson.se> References: <8B0A9FCBB9832F43971E38010638454F040B26C9D9@SISPE7MB1.commscope.com> <7F2072F1E0DE894DA4B517B93C6A05851DB647051B@ESESSCMS0356.eemea.ericsson.se> <8B0A9FCBB9832F43971E38010638454F040D2C32F8@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F040D2C32F8@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP callback X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 17:42:32 -0000 Hi,=20 >> 2. Identities that the call is a PSAP callback call. >=20 >You need to be clearer here: identifies to whom? It would be=20 >relatively easy to identify to the UA, but less easy for a=20 >proxy that has no prior interaction with the call. The home network. >>Also, in order to prevent fraud, the callback indicator=20 >>would need to be asserted by the network. >=20 >Specifically what sort of fraud? Callbacks are usually=20 >charged as normal, so the only potential problem here is=20 >circumvention of normal call screening (redirection to voice=20 >mail, and so on), and then only when those sorts of policies=20 >are suppressed. >=20 >It's entirely possible that callbacks will be treated like=20 >normal calls. Then I see very little reason to spend=20 >additional effort in special markings. Sure, they CAN be treated as normal calls. But, it should also be possible = for the home network to give special treatment the them. At least from an I= MS perspective that typically would mean bypassing of services, but I assum= e that would apply also to other environments. =20 >>Regarding the suggestion to use GRUU, I assume a UA, before=20 >>making the emergency call (eCALL), would perform an "emergency registrati= on" >>(eREG), in order to retieve the "emergency gruu" (eGRUU). >=20 >That's possible. It's also possible to simply register a=20 >pseudo-instance so that you get an extra GRUU (eGRUU) that=20 >you only use for emergency calls. If that extra GRUU is only=20 >used for emergency calls, then all calls directed to it are=20 >probably callbacks. >=20 >You can then associate special policy (suppress some call=20 >screening) for calls directed to that particular GRUU, but=20 >I'm not aware of any burning need to do so. We can look at the usage of GRUU. What I want to get a decission on now is whether ECRIT it willing to work o= n a solution that takes the "home network callback identification" into con= sideration. >>One question is: if the UA deregisters the eREG after the=20 >>eCALL, would the callback call still reach the UA? >=20 >Does it matter? What do you mean? The callback call should reach the UA, shouldn't it? :) Regards, Christer From Martin.Thomson@commscope.com Sun Jul 24 03:34:08 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3142721F8B30 for ; Sun, 24 Jul 2011 03:34:08 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGiH0g3VydVZ for ; Sun, 24 Jul 2011 03:34:07 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 9357E21F8B14 for ; Sun, 24 Jul 2011 03:34:07 -0700 (PDT) X-AuditID: 0a0404e8-b7c24ae000002adb-82-4e2bf52bad64 Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id 41.16.10971.B25FB2E4; Sun, 24 Jul 2011 05:34:19 -0500 (CDT) Received: from CDCE10HC2.commscope.com (10.86.20.22) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.159.2; Sun, 24 Jul 2011 05:34:06 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by CDCE10HC2.commscope.com (10.86.20.22) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sun, 24 Jul 2011 05:34:06 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Sun, 24 Jul 2011 18:34:03 +0800 From: "Thomson, Martin" To: Christer Holmberg Date: Sun, 24 Jul 2011 18:34:02 +0800 Thread-Topic: PSAP callback Thread-Index: Acw1Xjl8KWX6PyjFSeORSy+kDda55QTMjspAADIO62AAAWUbIAAiJmEg Message-ID: <8B0A9FCBB9832F43971E38010638454F040D2C3315@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F040B26C9D9@SISPE7MB1.commscope.com> <7F2072F1E0DE894DA4B517B93C6A05851DB647051B@ESESSCMS0356.eemea.ericsson.se> <8B0A9FCBB9832F43971E38010638454F040D2C32F8@SISPE7MB1.commscope.com> <7F2072F1E0DE894DA4B517B93C6A05851DB647051F@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851DB647051F@ESESSCMS0356.eemea.ericsson.se> 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-Brightmail-Tracker: AAAAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP callback X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 10:34:08 -0000 On 2011-07-23 at 13:42:22, Christer Holmberg wrote: > >> 2. Identities that the call is a PSAP callback call. > > > >You need to be clearer here: identifies to whom? ... >=20 > The home network. Right, assuming that a home network proxy saw the original call is not goin= g to work. As far as a call marking, the question for me becomes whether the call mark= ing is explicit or negotiated. An explicit indicator might be easier, but = I'd like to find a solution that required as few implementation warts as po= ssible. > Sure, they CAN be treated as normal calls. But, it should also be=20 > possible for the home network to give special treatment the them. At=20 > least from an IMS perspective that typically would mean bypassing of=20 > services, but I assume that would apply also to other environments. And this is the dangerous part, I see. Allowing arbitrary calls to be mark= ed would open up the possibility of abuse. Unless you ensured that only PS= APs (and their agents) could mark such calls. > We can look at the usage of GRUU. >=20 > What I want to get a decission on now is whether ECRIT it willing to=20 > work on a solution that takes the "home network callback=20 > identification" into consideration. It's a reasonable goal. But consider the option where no specific marking = is made, and the UE is instead required to inform the home network that a p= articular GRUU is in fact an "eGRUU". Or, the UE doesn't say so directly, = and instead requests specific call handling policy for a particular GRUU. The answer is all tied up in whether it is desirable for the home network t= o be able to unilaterally apply policy. > >>One question is: if the UA deregisters the eREG after the eCALL, > would > >>the callback call still reach the UA? > > > >Does it matter? >=20 > What do you mean? The callback call should reach the UA, shouldn't it? > :) Of course, but there are so many reasons why a callback could fail already.= It certainly isn't an inviolable axiom. Is there any reason why you woul= dn't say "Deregistration: don't do that." ? I'd say that it would be more likely that a user turns off their phone than= an implementer would allow deregistration, particularly if a specification= expressly prohibited it. --Martin From christer.holmberg@ericsson.com Sun Jul 24 13:09:00 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0778221F856A for ; Sun, 24 Jul 2011 13:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.548 X-Spam-Level: X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Dj+Pn9wYHez for ; Sun, 24 Jul 2011 13:08:59 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 320A721F856B for ; Sun, 24 Jul 2011 13:08:59 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-2c-4e2c7bd994b2 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 4C.AE.09774.9DB7C2E4; Sun, 24 Jul 2011 22:08:58 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.123]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Sun, 24 Jul 2011 22:08:57 +0200 From: Christer Holmberg To: "Thomson, Martin" Date: Sun, 24 Jul 2011 22:08:55 +0200 Thread-Topic: PSAP callback Thread-Index: Acw1Xjl8KWX6PyjFSeORSy+kDda55QTMjspAADIO62AAAWUbIAAiJmEgAAXXrUA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB647056F@ESESSCMS0356.eemea.ericsson.se> References: <8B0A9FCBB9832F43971E38010638454F040B26C9D9@SISPE7MB1.commscope.com> <7F2072F1E0DE894DA4B517B93C6A05851DB647051B@ESESSCMS0356.eemea.ericsson.se> <8B0A9FCBB9832F43971E38010638454F040D2C32F8@SISPE7MB1.commscope.com> <7F2072F1E0DE894DA4B517B93C6A05851DB647051F@ESESSCMS0356.eemea.ericsson.se> <8B0A9FCBB9832F43971E38010638454F040D2C3315@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F040D2C3315@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP callback X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 20:09:00 -0000 Hi Martin,=20 >>>You need to be clearer here: identifies to whom? ... >>=20 >> The home network. >=20 >Right, assuming that a home network proxy saw the original=20 >call is not going to work. Correct. The original call might not have traversed the home network. >As far as a call marking, the question for me becomes whether=20 >the call marking is explicit or negotiated. An explicit=20 >indicator might be easier, but I'd like to find a solution=20 >that required as few implementation warts as possible. I agree. >>Sure, they CAN be treated as normal calls. But, it should also be=20 >>possible for the home network to give special treatment the=20 >>them. At least from an IMS perspective that typically would mean=20 >>bypassing of services, but I assume that would apply also to other enviro= nments. >=20 >And this is the dangerous part, I see. Allowing arbitrary=20 >calls to be marked would open up the possibility of abuse. =20 >Unless you ensured that only PSAPs (and their agents) could=20 >mark such calls. Yes. That's why such marking would have to be asserted. >>We can look at the usage of GRUU. >>=20 >>What I want to get a decission on now is whether ECRIT it=20 >>willing to work on a solution that takes the "home network callback=20 >>identification" into consideration. >=20 >It's a reasonable goal. But consider the option where no=20 >specific marking is made, and the UE is instead required to=20 >inform the home network that a particular GRUU is in fact an=20 >"eGRUU". Or, the UE doesn't say so directly, and instead=20 >requests specific call handling policy for a particular GRUU. >=20 >The answer is all tied up in whether it is desirable for the=20 >home network to be able to unilaterally apply policy. >=20 >>>>One question is: if the UA deregisters the eREG after the eCALL, >>>>would >>>>the callback call still reach the UA? >>> >>>Does it matter? >>=20 >>What do you mean? The callback call should reach the UA,=20 >>shouldn't it? :) >=20 >Of course, but there are so many reasons why a callback could=20 >fail already. It certainly isn't an inviolable axiom. Is=20 >there any reason why you wouldn't say "Deregistration: don't=20 >do that." ? >=20 >I'd say that it would be more likely that a user turns off=20 >their phone than an implementer would allow deregistration,=20 >particularly if a specification expressly prohibited it. =20 I guess it depends on whether you have a dedicated emergency registration o= r not. In such cases I think it's quite normal that you would un-register a= fter you've finished the call Of course, you could wait for some time before you unregister. Regards, Christer= From RMarshall@telecomsys.com Sun Jul 24 21:05:23 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F48711E8080 for ; Sun, 24 Jul 2011 21:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eelmulMKMVBH for ; Sun, 24 Jul 2011 21:05:19 -0700 (PDT) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [199.165.246.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4D011E8081 for ; Sun, 24 Jul 2011 21:05:19 -0700 (PDT) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Sun, 24 Jul 2011 21:05:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4A80.105A7B62" Date: Sun, 24 Jul 2011 21:05:17 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A65751AAECC29@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ecrf-lvfwg] RE: LVF impact - IETF draft for LVF return of complete & similar civic addresses Thread-Index: Acw7FO7VeNzAhw62SAC9VqIc1L2SNAKdffRwACXqLhAACFZIIAEOwiXg From: "Roger Marshall" To: Cc: "Rosen, Brian" Subject: [Ecrit] FW: [ecrf-lvfwg] RE: LVF impact - IETF draft for LVF return of complete & similar civic addresses X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 04:05:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC4A80.105A7B62 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Posting some comments regarding the draft: http://tools.ietf.org/html/draft-marshall-ecrit-similar-location-01 which were received from Jason Horning, as a NENA posting. =20 See thread. =20 -roger marshall. =20 From: Roger Marshall=20 Sent: Tuesday, July 19, 2011 12:27 PM To: Jason Horning; ECRF/LVF WG Cc: nena-ltd@lists.cs.columbia.edu; Winterbottom, James Subject: RE: [ecrf-lvfwg] RE: LVF impact - IETF draft for LVF return of complete & similar civic addresses =20 Jason: Thanks for taking the time to look at this draft. You've made some excellent points. Please see my comments below, denoted with [RM]. =20 I will post these comments to the IETF ECRIT list, which I encourage all those interested to sign up for at: =20 Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit =20 =20 -roger. =20 From: Jason Horning [mailto:jason.horning@bullberrysystems.com]=20 Sent: Tuesday, July 19, 2011 7:48 AM To: ECRF/LVF WG Cc: nena-ltd@lists.cs.columbia.edu; Winterbottom, James Subject: [ecrf-lvfwg] RE: LVF impact - IETF draft for LVF return of complete & similar civic addresses =20 Roger, =20 Thank you for the opportunity to comment and for your attention to this matter.=20 =20 Here are some of the concerns that I have with the draft in its present form.. =20 1. This extension of LoST suggests (as evidenced by at least one of the examples) that the client has been assigned to (or somehow has determined) the authoritative mapping server (AMS) that can provide the answer. It therefore bypasses the recursive or iterative nature of LoST to seek out the AMS. A couple of the examples describe civic addresses without country and A1 elements. Without those, I'd like to know how the client was able to reach the proper AMS to begin with. =20 [RM - You're right, there is an assumption that's not currently stated with regard to LoST server discovery. Additionally, the set of data elements in the examples should be made more realistic, to match these stated assumptions.] =20 If this is the author's intent, LoST servers will endeavor to return results for which they may not have any authority to be providing "hints". It is important to first determine, by coverage, which AMS to use. Only then can the LoST server be asked to make decisions such as those proposed. LoST provides the facility to determine the AMS, it just needs enough extremely coarse information to do so. =20 [RM - See above.] =20 2. In the example in section 6 "Similar Location returned for Invalid Response"; to which civic address is the returned urn:service:sos service associated? What happens if the two "similar" addresses exist within two different urn:service:sos service areas? Even if one were to associate the proper service with each civic address I'm unclear as to whether LoST permits that. This case should be addressed specifically. =20 [RM - Good point. What's missing here is some qualifying lead-in text describing the example, as well as a few other examples that may have different results. This will be fixed in a subsequent update to the draft.] =20 3. Another nit that I have includes intentionally using A6 to represent a street name and then permitting the LoST server to analyze it as RD and provide "similar" or "complete" location results. RFC5139 (which updated RFC4119) was quite clear on this practice. Here is an excerpt from RFC5139; "Where "A6" was previously used for street names in [RFC4119], it MUST NOT be used; the "RD" element MUST be used for thoroughfare data." I am aware of i3's position on this topic. However, the A6 element and the RD element represent different concepts. =20 [RM - Yes. RD should & will replace A6 for these examples.] =20 It may be possible that the draft can be added to and the concerns that I have expressed can be mitigated. However, it is not the approach that I would have preferred. I still submit that we must first define the US location validation process and then offer an alternate query interface to resolve "invalid" elements. At that point you can let the validation vendors determine the best way to tackle the LoST response, and query (with a non-LoST interface) for the information necessary to obtain a completely valid address. We can try to extend LoST without creating new problems but it seems to be a risky option. =20 [RM - Keep in mind that, as an IETF draft, (and despite the current examples), this document is not constrained for application within the US only.] =20 Finally, the stance taken in the Security Considerations section is a bit troubling. The source supplying address information to the LoST server should control what is valid and what is not valid, not the LoST server and not the client. They do this through the refinement of their data. If they go through the trouble of building in significant detail they are, in essence, defining the level of detail that they seek and which they may need to target specific services. If they provide very coarse information then they are allowing the client to validate to a more coarse level. I don't believe it should be left up to LoST vendors and service providers to determine what is acceptable. =20 [RM - I don't disagree - the "source" of the LoST server data does indeed set the policy for how stuff works, and so will be taken into account as we progress this draft.] =20 Regards, =20 Jason Horning =20 =20 From: Roger Marshall [mailto:RMarshall@telecomsys.com]=20 Sent: Monday, July 18, 2011 4:02 PM To: ECRF/LVF WG Cc: ECRF/LVF WG; nena-ltd@lists.cs.columbia.edu Subject: [ecrf-lvfwg] LVF impact - IETF draft for LVF return of complete & similar civic addresses =20 I'm forwarding an announcement (see attached) and link (below) to an individual draft that has been sent to the IETF, and so I would like to get some folks to weigh in with their thoughts, comments, etc. =20 You can do so here - on the ECRF/LVF or LTD-WG NENA lists, or on the IETF ECRIT mailing list. If people find it useful, then the proposal will be to make it an ECRIT working group draft. Therefore, your comments will be valuable. =20 http://tools.ietf.org/html/draft-marshall-ecrit-similar-location-01 =20 This draft represents a merging of the following two previously submitted drafts: =20 http://tools.ietf.org/html/draft-rosen-ecrit-lost-return-li-00 http://tools.ietf.org/html/draft-marshall-ecrit-similar-location-00 =20 Thanks. =20 -roger. CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. ------_=_NextPart_001_01CC4A80.105A7B62 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Posting some comments regarding the draft:  = http://tools.ietf.org/html/draft-marshall-ecrit-similar-location-01 whi= ch were received from Jason Horning, as a NEN= A posting.

 

See thread.

 

-roger marshall.

 

From: Roger Marshall
Sent: Tuesday, Jul= y 19, 2011 12:27 PM
To: Jason Horning; ECRF/LVF WG
Cc: = nena-ltd@lists.cs.columbia.edu; Winterbottom, James
Subject: RE: = [ecrf-lvfwg] RE: LVF impact - IETF draft for LVF return of complete & s= imilar civic addresses

 

J= ason:

Thanks for taking the time to look at this draft.  You’ve mad= e some excellent points.  Please see my comments below, denoted with [= RM].

 

I will post these comments to the IETF ECRIT list, which I encourage = all those interested to sign up for at:

 

Ecrit mailing list

Ecrit@ietf.org

htt= ps://www.ietf.org/mailman/listinfo/ecrit

 

 

-roger.

 

From: Jason Horning [mailto:jason.horning= @bullberrysystems.com]
Sent: Tuesday, July 19, 2011 7:48 AM
<= b>To: ECRF/LVF WG
Cc: nena-ltd@lists.cs.columbia.edu; Winterb= ottom, James
Subject: [ecrf-lvfwg] RE: LVF impact - IETF draft fo= r LVF return of complete & similar civic addresses

 

Roger,

 

Thank you for the opportunity to comment and for your attention to t= his matter.

 

Here are som= e of the concerns that I have with the draft in its present form..

 

= 1. This extension of LoST suggests (as evidenced by at least one of the exa= mples) that the client has been assigned to (or somehow has determined) the= authoritative mapping server (AMS) that can provide the answer.  It t= herefore bypasses the recursive or iterative nature of LoST to seek out the= AMS.  A couple of the examples describe civic addresses without count= ry and A1 elements.  Without those, I'd  like to know how the cli= ent was able to reach the proper AMS to begin with.

 

<= p class=3DMsoPlainText>[RM – You’re right, there is an a= ssumption that’s not currently stated with regard to LoST server disc= overy.  Additionally, the set of data elements in the examples should = be made more realistic, to match these stated assumptions.]

 

If this is the author's intent, LoST servers will endeavor = to return results for which they may not have any authority to be providing= "hints".  It is important to first determine, by coverage, = which AMS to use.  Only then can the LoST server be asked to make deci= sions such as those proposed.  LoST provides the facility to determine= the AMS, it just needs enough extremely coarse information to do so.<= /o:p>

 

[RM – See above.]

 

2. In the ex= ample in section 6 "Similar Location returned for Invalid Response&quo= t;; to which civic address is the returned urn:service:sos service associat= ed?  What happens if the two "similar" addresses exist withi= n two different urn:service:sos service areas?  Even if one were to as= sociate the proper service with each civic address I'm unclear as to whethe= r LoST permits that. This case should be addressed specifically.=

 

[RM – Good point.  What’s missing here = is some qualifying lead-in text describing the example, as well as a few ot= her examples that may have different results.  This will be fixed in a= subsequent update to the draft.]

 

3. Another nit that I have= includes intentionally using A6 to represent a street name and then permit= ting the LoST server to analyze it as RD and provide "similar" or= "complete" location results.  RFC5139 (which updated RFC411= 9) was quite clear on this practice.  Here is an excerpt from RFC5139;= "Where "A6" was previously used for street names in [RFC411= 9], it MUST NOT be used; the "RD" element MUST be used for thorou= ghfare data."  I am aware of i3's position on this topic. However= , the A6 element and the RD element represent different concepts.

 

[RM – Yes.  RD should & will replace A6 = for these examples.]

&nbs= p;

It may be possible that the draft can b= e added to and the concerns that I have expressed can be mitigated.  H= owever, it is not the approach that I would have preferred.  I still s= ubmit that we must first define the US location validation process and then= offer an alternate query interface to resolve "invalid" elements= .  At that point you can let the validation vendors determine the best= way to tackle the LoST response, and query (with a non-LoST interface) for= the information necessary to obtain a completely valid address. We can try= to extend LoST without creating new problems but it seems to be a risky op= tion.

 =

[RM – Keep in mind that, as an IET= F draft, (and despite the current examples), this document is not constrain= ed for application within the US only.]

 

Finally, the stance = taken in the Security Considerations section is a bit troubling.  The = source supplying address information to the LoST server should control what= is valid and what is not valid, not the LoST server and not the client.&nb= sp; They do this through the refinement of their data.  If they go thr= ough the trouble of building in significant detail they are, in essence, de= fining the level of detail that they seek and which they may need to target= specific services.  If they provide very coarse information then they= are allowing the client to validate to a more coarse level.  I don't = believe it should be left up to LoST vendors and service providers to deter= mine what is acceptable.

 

[RM – I don’t disagree - the “source” of the LoS= T server data does indeed set the policy for how stuff works, and so will b= e taken into account as we progress this draft.]

 

Regards,

 

Jason Horning

 

 

From: Roger Marshall [mailto:RMarshall@telecomsys.com]
Se= nt: Monday, July 18, 2011 4:02 PM
To: ECRF/LVF WG
Cc: ECRF/LVF WG; nena-ltd@lists.cs.columbia.edu
Subject: [ecrf-lvf= wg] LVF impact - IETF draft for LVF return of complete & similar civic = addresses

 =

I’m forw= arding an announcement (see attached) and link (below) to an individual dra= ft that has been sent to the IETF, and so I would like to get some folks to= weigh in with their thoughts, comments, etc.

 

You can do so here – o= n the ECRF/LVF or LTD-WG NENA lists, or on the IETF ECRIT mailing list.&nbs= p; If people find it useful, then the proposal will be to make it an ECRIT = working group draft.  Therefore, your comments will be valuable.<= /o:p>

&nb= sp;

http://tools.ietf.org/html/dr= aft-marshall-ecrit-similar-location-01

 

This draft represents a merging of the= following two previously submitted drafts:

 

http://tools.ietf.org/html/draft-rosen-ecrit-lost-return-l= i-00

http://tools.ietf.org/html= /draft-marshall-ecrit-similar-location-00

 

Thanks.

 

-roger.<= /p>

CONFIDENTIALITY NOTIC= E: The information contained in this message may be privileged and/or confi= dential. If you are not the intended recipient, or responsible for deliveri= ng this message to the intended recipient, any review, forwarding, dissemin= ation, distribution or copying of this communication or any attachment(s) i= s strictly prohibited. If you have received this message in error, please n= otify the sender immediately, and delete it and all attachments from your c= omputer and network.

------_=_NextPart_001_01CC4A80.105A7B62-- From john.elwell@siemens-enterprise.com Mon Jul 25 12:02:32 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18EA221F8B69 for ; Mon, 25 Jul 2011 12:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.884 X-Spam-Level: X-Spam-Status: No, score=-103.884 tagged_above=-999 required=5 tests=[AWL=-1.285, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U19+Zxer8e0d for ; Mon, 25 Jul 2011 12:02:31 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id CFA6521F8B7C for ; Mon, 25 Jul 2011 12:02:27 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 6696D23F03FD for ; Mon, 25 Jul 2011 21:02:25 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 25 Jul 2011 21:02:25 +0200 From: "Elwell, John" To: "ecrit@ietf.org" Date: Mon, 25 Jul 2011 21:02:22 +0200 Thread-Topic: Rough notes Thread-Index: AcxK/WKX+1l/I3pWTESq6t2wOMAyxg== Message-ID: 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 Subject: [Ecrit] Rough notes X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 19:02:32 -0000 10 min * Agenda Bashing, Draft Status Update (Chairs) Concerning issues holding up approval of phone bcp and framework, Brian is = still awaiting response to his questions. Update can happen this week if no= objections to his proposals. Concerning status of lost-sync - 11 reflects discussions Hannes had in Prag= on WGLC issues, and he feels document is now about ready to go. Mentioned = two open source implementations. Rough loc is about ready to go. Brief report of ESW8 in Budapest, April, from Richard and Hannes. Richard mentioned that NENA i3 spec is released. Extra item: Demise of 802.23, Geoff Thompson Final report - not enough people participating or contributing, so document= s will be archived and the group will be killed off in September. Draft may= have value as pointer to work needing to be done in 802.1 to fill gaps. Randall asked for clarification. Response from Geoff was that you would get= a network topology and which node in that topology has location. Correlati= ng network topology with physical topology. Richard asked question ???? Missed this and response. 10 min. * Similar Location (Roger Marshall) Brian liked the example slide but had a slight unease about the particular = example ????: If one of the elements is wrong, but pointed out that this example is= only for the valid case. ????: so need to have very clear definition of what is valid or invalid. He= was asked to provide some input. Roger wanted to make this a WG item. Brian supported it, saying that open i= tems were not technical issues. Marc had some concerns about backward compa= tibility. Brian said there are no such issues. Will be a call for adoption on list in a couple of weeks. 10 min * Data Only (Brian Rosen/Hannes Tschofenig) Brian presented. Hannes: Not sure on CAP question. Brian says he should come up with a count= er example where it doesn't work. Hannes: CAP is using XML in a very verbose way. Brian says we are using CAP= because it is the generally accepted mechanism for this type of thing. If = you want to change, don't make a new type of CAP. ????: Distinction between non-human-associated and non-human-initiated. CAP= is OK if no human interaction, but a heart-rate monitor might later on hav= e voice as well, so might want to establish a session. Authors asked to summarise the issues and put to the list. 10 min * Additional Data (Brian Rosen)=20 Looking for feedback on whether his breaking up into blocks and other recei= ved comments have been handled correctly. ????: Should avoid losing data on call forwarding. Brian said original PSAP= would pass it along. Brian wants to know if there is any data missing from= his list. James Winterbottom: Concerned about privacy issues, things in INVITE messag= e body being seen by entities en route. Brian - security section should war= n against sending private information. Martin: Draft says all the right things but a little confusing in language.= Need to spend more time on language before final review. Martin will send = specific comments. 20 min. * Trustworthy Location Information (Bernard Aboba/Hannes Tschofenig= )=20 Bernard's presentation: Discussion on whether Geolocation API requirements lead it not to reveal so= urce of location. Fact remains it doesn't give the source. Roger: If you include uncertainty, also need to include confidence. Brian: Should send what you know. Don't send what you don't know for certai= n. Bernard will propose resolution based on feedback received. Hannes's presentation: Martin Thompson: Different identities might not be meaningful to all entiti= es. Bernard: Is a link between accountability and trustworthy location, but onl= y partial. Need signed location. Geoff: Location isn't the problem, people are the problem, and location spo= ofing is the problem. So have method of fixing it in terms of people. Brian: Strongly object to fact that document has no conclusion. NENA didn't= understand what it was asking for. Location signing is helpful but insuffi= cient. Saying that you can't solve enough problems by location signing does= not mean it is not helpful. Hannes says it is fair to say in what cases th= ings work and in what cases they don't work. Richards: Trade-off is between access and security. Can't say can't do loca= tion signing just because there are entities that don't sign location. Martin: Some of the solutions we are looking at are very abstract - need so= mething more concrete. Hannes: this is because there is so much outside the= traditional things we deal with. Martin: Would help to work through specific cases. Gave example of not know= ing it is emergency call when asking for location. Brian: No silver bullet, no perfect solution, so have to deploy multiple im= perfect solutions. 20 min. * Unauthenticated and Unauthorized Devices (Hannes Tschofenig) On issue 1: Richard: As host, I can make the necessary holes for LIS and LOST access, b= ut have to open up SIP, perhaps to limited service providers. Document shou= ld say what you need to open up. Geoff: We considered this problem in 802.23, and concluded it was a bad ide= a to provide access to an arbitrary SIP service provider, so should have a = single one or a limited number. Martin: SIP has the means to override default ports, and so on. How about I= SP obtaining from LOST server the legitimate places an INVITE request can g= o to, so can ensure INVITE only goes to PSAP. Richard not sure this would help. Richard: Another aspect is that there are other ways an ISP can make things= more predictable ???? James: ???? On the document in general: Brian: This is way ahead of where we need specification - no regulation yet= . Just document what the issues are, but don't provide solutions. Bernard: Thought issues 2 and 3 were already resolved. 20 min. * PSAP Callback (Christer Holmberg/Hannes Tschofenig) Christer pres= ented. Brian: Isn't requirement 2 already met if you meet requirement 1. Martin Dolly: Need an emergency indicator such that for a duration in time = you can let calls through if they have that indicator, and that can also be= used for turning off features such as call forwarding. Brian: Have not answered my question. But may be a requirement for device t= o recognise emergency callbacks. Martin: Callback indicator could also be used to block other calls for a pe= riod of time. ????: Agrees with Martin. Randall: Requirement 1 is really two requirements: the same device, and sec= ond that call reaches that device. Andrew Allen: 1 deals with issue of multiple devices, and 2 is to do with n= ot being transferred elsewhere or going through additional features before = getting there. Geoff: 2 is just a detail of 1, and there are a lot more details to be adde= d. Brian: Separating addressing from permission might be useful. Brian: What actually happens today is that you attempt a callback and it ma= y or may not work. PSAPs have not asked for anything better. Christer: ???? Martin Dolly: doesn't exist in circuit switched world because can't be done= , but want to do better in the IP world. Brian: But we have not been asked to do this. Christer: 3GPP is asking for it. ???? from Canada: Do have a requirement for holding a 911 call and preventi= ng hang-up, so no need for callback, just ringback (connection is held up). Randall: The Canadian idea can only work in a legacy wireline environment. Brian: There are those who disagree with that point of view. Brian: More text is needed to fulfil something in PhoneBCP? Hannes: Need to look at scenarios. No conclusion. 20 min. * Questions? = From Martin.Thomson@commscope.com Mon Jul 25 12:10:59 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6900A21F8BC6 for ; Mon, 25 Jul 2011 12:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7z36rp-DYNg4 for ; Mon, 25 Jul 2011 12:10:58 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF5B21F8B81 for ; Mon, 25 Jul 2011 12:10:58 -0700 (PDT) X-AuditID: 0a0404e9-b7cc4ae00000074e-ac-4e2dbfca8ab0 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id 45.90.01870.ACFBD2E4; Mon, 25 Jul 2011 14:11:06 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 25 Jul 2011 14:10:56 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 26 Jul 2011 03:10:53 +0800 From: "Thomson, Martin" To: "ecrit@ietf.org" Date: Tue, 26 Jul 2011 03:10:53 +0800 Thread-Topic: Additional data concerns Thread-Index: AcxK9vPJLnRMb+mjSwKCHunGlT4pCQ== Message-ID: <8B0A9FCBB9832F43971E38010638454F040D2C347A@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [Ecrit] Additional data concerns X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 19:10:59 -0000 I raised a few concerns about the language in this document in the meeting. There are a lot of little things, but they make it more difficult to follow= than it really needs to be. The use of MIME and related terminology is systematically confused. For instance, this statement cannot be correct: The MIME type is "addDataProviderInfo". A MIME media type is identified in a particular form, that must include '/'= . Equally, the statement: Each block is a MIME type, [...] Doesn't make sense. Each block is a document, identified with the emergencyCallData purpose.= The type of each block is identified using a MIME media type. I'd also like to see the XML schema completed. As noted, extensibility is = important, but we need to be able to choose where to extend. I think that = extension by adding a new media type is appropriate in some cases and exten= ding existing XML is appropriate in others. >From an editorial perspective, I find the formatting of the elements distra= cting. The list structure seems unnecessary. I think that this could be c= ut back to the following form: 3.1.2 Data Provider ID =20 The element includes a jurisction-specific identifier for th= e data provider. This might he used to locate information about the data p= rovider. There might be more. I'll have more exhaustive look later. Hopefully, a n= ew version of the draft will have this easier. --Martin From hannes.tschofenig@gmx.net Mon Jul 25 13:38:18 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E10B211E809A for ; Mon, 25 Jul 2011 13:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqyFVLFbKMoN for ; Mon, 25 Jul 2011 13:38:18 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 16AFD11E8093 for ; Mon, 25 Jul 2011 13:38:17 -0700 (PDT) Received: (qmail invoked by alias); 25 Jul 2011 20:38:16 -0000 Received: from dhcp-172b.meeting.ietf.org (EHLO dhcp-172b.meeting.ietf.org) [130.129.23.43] by mail.gmx.net (mp004) with SMTP; 25 Jul 2011 22:38:16 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+cBMc3d1OcNCQfZhnvm7smOgUnB7Z1ZQzxZY01OO og8lrAE3zDxMpu From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jul 2011 16:38:14 -0400 Message-Id: <9C045A2C-2B23-415C-A5D7-BFF5A779611B@gmx.net> To: ecrit@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [Ecrit] PSAP Callback Informal Meeting, Tuesday, 17:10 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 20:38:19 -0000 Following today's discussion we will meet for an informal meeting on = Tuesday, 17:10 in front of the breakfast room.=20 The purpose of our meeting is to gather ideas about how to move forward = with the PSAP callback document.=20 Ciao Hannes= From keith.drage@alcatel-lucent.com Mon Jul 25 13:42:02 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A8B21F8AD8 for ; Mon, 25 Jul 2011 13:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.119 X-Spam-Level: X-Spam-Status: No, score=-104.119 tagged_above=-999 required=5 tests=[AWL=-1.870, BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rjzr4nRR6to2 for ; Mon, 25 Jul 2011 13:42:01 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 9DAB221F8B17 for ; Mon, 25 Jul 2011 13:42:01 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p6PKfugX020893 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 25 Jul 2011 22:41:58 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Mon, 25 Jul 2011 22:41:58 +0200 From: "DRAGE, Keith (Keith)" To: Hannes Tschofenig , "ecrit@ietf.org" Date: Mon, 25 Jul 2011 22:41:56 +0200 Thread-Topic: [Ecrit] PSAP Callback Informal Meeting, Tuesday, 17:10 Thread-Index: AcxLCs4KcB5BrW3aSqmUnb4cJcd8rgAAGLgg Message-ID: References: <9C045A2C-2B23-415C-A5D7-BFF5A779611B@gmx.net> In-Reply-To: <9C045A2C-2B23-415C-A5D7-BFF5A779611B@gmx.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: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Subject: Re: [Ecrit] PSAP Callback Informal Meeting, Tuesday, 17:10 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 20:42:02 -0000 That sound like it is in parallel with the RAI area meeting, which I would = like to be at. Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Hannes Tschofenig > Sent: 25 July 2011 21:38 > To: ecrit@ietf.org > Subject: [Ecrit] PSAP Callback Informal Meeting, Tuesday, 17:10 >=20 > Following today's discussion we will meet for an informal meeting on > Tuesday, 17:10 in front of the breakfast room. > The purpose of our meeting is to gather ideas about how to move forward > with the PSAP callback document. >=20 > Ciao > Hannes > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From hannes.tschofenig@gmx.net Mon Jul 25 13:49:36 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F17111E80C1 for ; Mon, 25 Jul 2011 13:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIXOdPbRES2d for ; Mon, 25 Jul 2011 13:49:35 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 9E57F11E80C0 for ; Mon, 25 Jul 2011 13:49:34 -0700 (PDT) Received: (qmail invoked by alias); 25 Jul 2011 20:49:32 -0000 Received: from dhcp-172b.meeting.ietf.org (EHLO dhcp-172b.meeting.ietf.org) [130.129.23.43] by mail.gmx.net (mp058) with SMTP; 25 Jul 2011 22:49:32 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+ihDwya6GigDjIj+/TT958sKY6AlDniCMsL5SGj+ /SPQ3gvHTscgwq Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Mon, 25 Jul 2011 16:49:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9C045A2C-2B23-415C-A5D7-BFF5A779611B@gmx.net> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback Informal Meeting, Tuesday, 17:10 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 20:49:36 -0000 It will be difficult to find a slot that fits everyone. We will, of course, distribute some short meeting notes and will see = whether we need further discussion time during the rest of the week.=20 On Jul 25, 2011, at 4:41 PM, DRAGE, Keith (Keith) wrote: > That sound like it is in parallel with the RAI area meeting, which I = would like to be at. >=20 > Keith >=20 >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf Of >> Hannes Tschofenig >> Sent: 25 July 2011 21:38 >> To: ecrit@ietf.org >> Subject: [Ecrit] PSAP Callback Informal Meeting, Tuesday, 17:10 >>=20 >> Following today's discussion we will meet for an informal meeting on >> Tuesday, 17:10 in front of the breakfast room. >> The purpose of our meeting is to gather ideas about how to move = forward >> with the PSAP callback document. >>=20 >> Ciao >> Hannes >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit From dromasca@avaya.com Tue Jul 26 08:08:01 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42DFB21F8C0E; Tue, 26 Jul 2011 08:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.397 X-Spam-Level: X-Spam-Status: No, score=-103.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BhBUOwhdryE; Tue, 26 Jul 2011 08:08:00 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2491F0C43; Tue, 26 Jul 2011 08:07:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4AAETXLk6HCzI1/2dsb2JhbAA2AQEBAQIBFCIKRQUHBQIBCQ0BAwEDAQEBCgYYCwEGARM7AwsIAQEFFwwUB5dcj1p3iHylVgKcC4VhXwSYF4s9 X-IronPort-AV: E=Sophos;i="4.67,269,1309752000"; d="scan'208";a="258767319" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 26 Jul 2011 11:07:54 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 26 Jul 2011 11:00:21 -0400 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: Tue, 26 Jul 2011 17:07:47 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Dan Romascanu's Discuss on draft-ietf-ecrit-phonebcp-17: (with DISCUSS and COMMENT) Thread-Index: AcxLpEUfIWDJ6SOKSMmRkvrlCCp6SgAAIcKQ References: <20110427124143.8317.20417.idtracker@ietfa.amsl.com> <8BEBE8CA-9CAC-404F-8E04-1A9732E25242@brianrosen.net> <7556C2A9-86AB-4C74-9E86-51729FA511F2@brianrosen.net> From: "Romascanu, Dan (Dan)" To: "Brian Rosen" Cc: ecrit-chairs@tools.ietf.org, draft-ietf-ecrit-phonebcp@tools.ietf.org, The IESG , ecrit@ietf.org Subject: Re: [Ecrit] Dan Romascanu's Discuss on draft-ietf-ecrit-phonebcp-17: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 15:08:01 -0000 Hi,=20 Thanks for the clarifications. I am looking for the updated version to be able to clear.=20 Regards, Dan=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, July 26, 2011 5:57 PM > To: Romascanu, Dan (Dan) > Cc: The IESG; ecrit-chairs@tools.ietf.org; draft-ietf-ecrit- > phonebcp@tools.ietf.org; ecrit@ietf.org > Subject: Re: Dan Romascanu's Discuss on draft-ietf-ecrit-phonebcp-17: > (with DISCUSS and COMMENT) >=20 > I thought I had replied to this, but I don't see it it. >=20 > ED-10 is SHOULD NOT because of the discussion in -framework about user > interfaces. Can't make any hard and fast rules, but our experience is > bad. >=20 > ED-73 is self explaining. The endpoint must support G.711 or > transcoding must be available. If the PSAP supports the narrowband > codec the endpoint supports, than transcoding isn't necessary, which is > desirable. >=20 > I will add a reference NENA using this document: > Other organizations, such as the North American Emergency Number > Association (NENA), define the PSAP interface. NENA's documents > reference this document. >=20 >=20 >=20 > Brian >=20 >=20 > On Jun 22, 2011, at 4:15 AM, Romascanu, Dan (Dan) wrote: >=20 > > > > > > Hi Brian, > > > > I will add one level of quoting, but take out all that is agreed. > Very > > little is left. > > > > Thanks and Regards, > > > > Dan > > > >> -----Original Message----- > >> From: Brian Rosen [mailto:br@brianrosen.net] > > > > > >>>>> > >>>>> In a number of cases normative language appears to be used in > ways > >>>>> different from those described in RFC 2119. In some cases, > >>>> the term > >>>>> "SHOULD" is used in situations where statutes or > >>>> regulations may mandate behavior. > >>>> We believe this to be the best choice. It's MUST except in > >>>> specified circumstances. The circumstances are when > >>>> regulations say otherwise. > >>> > >>> It would be good to clarify this in the document. > >> I went through the document SHOULDs and looked for cases where we > >> should say that. I didn't spot any. Could you point some out for > me? > >> > > > > What about ED-10 and ED-73? What are the reasons for these SHOULD not > to > > be MUST? > > > > > >>>>> > >>>>> I also find odd the fact that the document does not refer > >>>> at least informationaly to the NENA i2 and i3 architectures. > >>>> The behavior of the system and requirements may be different > >>>> in i2 and i3 environments. There are places where behavior > >>>> should be configurable or negotiated to allow for better > >>>> behavior in a transitional environment. There are also places > >>>> where behavior will be prescribed by local statues or > >>>> regulations, so that configuration and/or negotiation is a > >>>> practical requirement. > >>>> It would be inappropriate to refer to i2 and i3 in -phonebcp. > >>> > >>> Why? It's not about the specific North-American regulatory aspects, > >> it's > >>> about the fact that the document targets an all-IP architecture > > which > >> is > >>> associated to i3 for everybody who deals with emergency. > >> I covered "all-IP". Therefore i2 is not relevant. > >> > >> i3 might be relevant only in that it defines PSAP requirements, the > >> mirror of this document. I still don't understand the value of a > >> reference here. I'll put one in -framework. > >> > >> The only thing we could say is kind of weird - "This document is > used > >> by other organizations who define PSAP interfaces, such as NENA i3". > >> > >> We don't say anything in i3 that this document is dependent upon - > > it's > >> the other way around. > >> > > > > Understood and agreed. Yet, any user, implementer, lawmaker, etc. > > looking into the requirements and architecture of an IP-based > solution > > in North America will need to look at these two documents (at least) > in > > tandem to have an understanding. This is why even the 'kind of weird' > > phrase would be useful IMO. > > > >> > >>> > >>>> I do think we could refer to it in -framework however, and > >>>> we will draft a paragraph that does that. > >>>> > > From rbarnes@bbn.com Tue Jul 26 09:22:00 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6413811E80DF for ; Tue, 26 Jul 2011 09:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.592 X-Spam-Level: X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEsjxCCPO1Jl for ; Tue, 26 Jul 2011 09:21:59 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id AB04511E807B for ; Tue, 26 Jul 2011 09:21:59 -0700 (PDT) Received: from [128.89.253.157] (port=61902 helo=[130.129.16.219]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QlkOM-000FMa-O4 for ecrit@ietf.org; Tue, 26 Jul 2011 12:21:58 -0400 From: "Richard L. Barnes" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jul 2011 12:21:57 -0400 Message-Id: <3014B5C7-C9C1-4A3D-9695-2EBAD142AEDC@bbn.com> To: "ecrit@ietf.org Org" Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [Ecrit] SWATting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 16:22:00 -0000 I heard from some people that they had not heard the verb "to SWAT" = before the ECRIT meeting tomorrow. Today's news has a new example: = This is a vulnerability of the current system, but the trustworthy = location document is intended to quantify the risk of similar attacks in = the ECRIT environment. --Richard= From jmpolk@cisco.com Tue Jul 26 10:10:42 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654D321F898F for ; Tue, 26 Jul 2011 10:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.099 X-Spam-Level: X-Spam-Status: No, score=-104.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KA20ibyTsxxr for ; Tue, 26 Jul 2011 10:10:37 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id EB4FB21F899D for ; Tue, 26 Jul 2011 10:10:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=770; q=dns/txt; s=iport; t=1311700237; x=1312909837; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=eQuTTs95cVwGegPrg1nrhWtQMZhXgBXykkJtzIEmetU=; b=hUAbR9Nyyw4HDUfUO0X7UaiFjLb2V30amIKHheBlutv7KiNfe7qqR9ik CdnIzqlf8vtv+MJtUgZmCPq0v14r7khnFLW9Az0OLDO1brNBv2wx5iSc/ hLeXpa4bzHWQMMA9B6wSrpNFbw1AyUc/CZwsiRxfzkknyab7PhF1Vnsm4 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIT0Lk6rRDoH/2dsb2JhbAArCwEBAQEDAQEBEQEpAjocCAQYKhAUBhI5BwEWHwinLneJAKJ2nmSFYV8Eh1ecGQ X-IronPort-AV: E=Sophos;i="4.67,270,1309737600"; d="scan'208";a="6560764" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-1.cisco.com with ESMTP; 26 Jul 2011 17:10:30 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-vpn-client-10-89-0-201.cisco.com [10.89.0.201]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6QHASE8030365; Tue, 26 Jul 2011 17:10:29 GMT Message-Id: <201107261710.p6QHASE8030365@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 26 Jul 2011 12:10:27 -0500 To: "Richard L. Barnes" , "ecrit@ietf.org Org" From: "James M. Polk" In-Reply-To: <3014B5C7-C9C1-4A3D-9695-2EBAD142AEDC@bbn.com> References: <3014B5C7-C9C1-4A3D-9695-2EBAD142AEDC@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [Ecrit] SWATting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 17:10:42 -0000 At 11:21 AM 7/26/2011, Richard L. Barnes wrote: >I heard from some people that they had not heard the verb "to SWAT" >before the ECRIT meeting tomorrow. err, "the ECRIT meeting tomorrow"? The meeting was yesterday. I know this can get all confusing during the IETF... ;-) James >Today's news has a new example: > > >This is a vulnerability of the current system, but the trustworthy >location document is intended to quantify the risk of similar >attacks in the ECRIT environment. > >--Richard >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From mlinsner@cisco.com Tue Jul 26 10:12:21 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8308D21F8B0B for ; Tue, 26 Jul 2011 10:12:21 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iFwge6uyoTe for ; Tue, 26 Jul 2011 10:12:20 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id F025B21F84CB for ; Tue, 26 Jul 2011 10:12:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mlinsner@cisco.com; l=876; q=dns/txt; s=iport; t=1311700340; x=1312909940; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=TAs8JVmxs4sS08/q7o7YVLDs5zaUa7kUPQZ3JRuZGlc=; b=Np7nyLNc3eht6HwU/0t4hIVvndE4KN0IGB49aTfEhQYd8gSThCmcDaUR JGNd1qJlrLXruwXoVnwL3C+YLtWonkho61ciUyxEsPqw5dHdLvrCGbfUo QeVW0FQF9bEM3JlQ0Yi1jFGnU6Ke9eQ5i9IXuMzWC+4IlkQ5pVLsjyzbN U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMz0Lk6rRDoG/2dsb2JhbAArCwEBAQEDAQEBEQErAwE2FwgJEQMBAk8YMQgHARYfCKcud4kAonaGPZgohkAEknKFB4t1 X-IronPort-AV: E=Sophos;i="4.67,270,1309737600"; d="scan'208";a="6566330" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-7.cisco.com with ESMTP; 26 Jul 2011 17:12:19 +0000 Received: from [10.86.251.25] (bxb-vpn3-793.cisco.com [10.86.251.25]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6QHCFew017372; Tue, 26 Jul 2011 17:12:17 GMT User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Tue, 26 Jul 2011 13:12:10 -0400 From: Marc Linsner To: "Richard L. Barnes" , "ecrit@ietf.org Org" Message-ID: Thread-Topic: [Ecrit] SWATting In-Reply-To: <3014B5C7-C9C1-4A3D-9695-2EBAD142AEDC@bbn.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [Ecrit] SWATting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 17:12:21 -0000 Or the reference Hannes uses: http://www.fbi.gov/news/stories/2008/february/swatting020408 -Marc- -----Original Message----- From: "Richard L. Barnes" Date: Tue, 26 Jul 2011 12:21:57 -0400 To: "ecrit@ietf.org Org" Subject: [Ecrit] SWATting >I heard from some people that they had not heard the verb "to SWAT" >before the ECRIT meeting tomorrow. Today's news has a new example: >d-swat-to-womans-house-20110726-1hxqm.html> > >This is a vulnerability of the current system, but the trustworthy >location document is intended to quantify the risk of similar attacks in >the ECRIT environment. > >--Richard >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From hannes.tschofenig@gmx.net Tue Jul 26 10:44:22 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0329D11E8075 for ; Tue, 26 Jul 2011 10:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sn0RFK4e-C00 for ; Tue, 26 Jul 2011 10:44:21 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 9D8F511E8073 for ; Tue, 26 Jul 2011 10:44:20 -0700 (PDT) Received: (qmail invoked by alias); 26 Jul 2011 17:44:19 -0000 Received: from dhcp-172b.meeting.ietf.org (EHLO dhcp-172b.meeting.ietf.org) [130.129.23.43] by mail.gmx.net (mp069) with SMTP; 26 Jul 2011 19:44:19 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+mSlQgrnOmcoSKDTUhM8gIBwAA/YYs+ogBbMU7Ze EKonaV7R/k2sxk Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Tue, 26 Jul 2011 13:44:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0B276671-78E3-4F18-BB49-A9B4E52A7213@gmx.net> References: To: Marc Linsner X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] SWATting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 17:44:22 -0000 I also say this one recently: "Xboxer SWATTED by armed cops after = online spat"=20 http://www.theregister.co.uk/2011/06/30/xbox_swat_police_rait/ On Jul 26, 2011, at 1:12 PM, Marc Linsner wrote: > Or the reference Hannes uses: >=20 > http://www.fbi.gov/news/stories/2008/february/swatting020408 >=20 >=20 > -Marc- >=20 > -----Original Message----- > From: "Richard L. Barnes" > Date: Tue, 26 Jul 2011 12:21:57 -0400 > To: "ecrit@ietf.org Org" > Subject: [Ecrit] SWATting >=20 >> I heard from some people that they had not heard the verb "to SWAT" >> before the ECRIT meeting tomorrow. Today's news has a new example: >> = > d-swat-to-womans-house-20110726-1hxqm.html> >>=20 >> This is a vulnerability of the current system, but the trustworthy >> location document is intended to quantify the risk of similar attacks = in >> the ECRIT environment. >>=20 >> --Richard >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From rbarnes@bbn.com Tue Jul 26 11:01:09 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1B511E811B for ; Tue, 26 Jul 2011 11:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.593 X-Spam-Level: X-Spam-Status: No, score=-106.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SzWuzX90AWn9 for ; Tue, 26 Jul 2011 11:01:09 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 033CE11E810E for ; Tue, 26 Jul 2011 11:01:08 -0700 (PDT) Received: from [128.89.253.130] (port=62342 helo=[130.129.16.219]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QllwI-0003uL-SH; Tue, 26 Jul 2011 14:01:07 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <0B276671-78E3-4F18-BB49-A9B4E52A7213@gmx.net> Date: Tue, 26 Jul 2011 14:01:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <99ED83A9-C475-4855-A26B-32489C21C025@bbn.com> References: <0B276671-78E3-4F18-BB49-A9B4E52A7213@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1082) Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] SWATting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 18:01:09 -0000 Does anyone on this list know how these attacks are accomplished? =20 The only obvious approaches that occur to me are CLI spoofing and lying = on a VoIP provider's registration form (coincidentally, the same things = that Wikipedia suggests). But in the case I mention below, they say = that the call was from "a non-valid number". Incidentally, the ECRIT equivalent of CLI spoofing is IP address = spoofing (when the LIS is locating based on IP address). So it might be = worth referring to BCP 38 somewhere.=20 --Richard On Jul 26, 2011, at 1:44 PM, Hannes Tschofenig wrote: > I also say this one recently: "Xboxer SWATTED by armed cops after = online spat"=20 > http://www.theregister.co.uk/2011/06/30/xbox_swat_police_rait/ >=20 >=20 > On Jul 26, 2011, at 1:12 PM, Marc Linsner wrote: >=20 >> Or the reference Hannes uses: >>=20 >> http://www.fbi.gov/news/stories/2008/february/swatting020408 >>=20 >>=20 >> -Marc- >>=20 >> -----Original Message----- >> From: "Richard L. Barnes" >> Date: Tue, 26 Jul 2011 12:21:57 -0400 >> To: "ecrit@ietf.org Org" >> Subject: [Ecrit] SWATting >>=20 >>> I heard from some people that they had not heard the verb "to SWAT" >>> before the ECRIT meeting tomorrow. Today's news has a new example: >>> = >> d-swat-to-womans-house-20110726-1hxqm.html> >>>=20 >>> This is a vulnerability of the current system, but the trustworthy >>> location document is intended to quantify the risk of similar = attacks in >>> the ECRIT environment. >>>=20 >>> --Richard >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 From hgs@cs.columbia.edu Tue Jul 26 11:12:39 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42AA85E8005 for ; Tue, 26 Jul 2011 11:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.266 X-Spam-Level: X-Spam-Status: No, score=-5.266 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Ks970OzS7Zn for ; Tue, 26 Jul 2011 11:12:38 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB565E8002 for ; Tue, 26 Jul 2011 11:12:38 -0700 (PDT) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id p6QICUCI009218 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 Jul 2011 14:12:30 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <99ED83A9-C475-4855-A26B-32489C21C025@bbn.com> Date: Tue, 26 Jul 2011 14:12:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <850E78F3-C96C-43E8-B2C7-95925DE6D6DB@cs.columbia.edu> References: <0B276671-78E3-4F18-BB49-A9B4E52A7213@gmx.net> <99ED83A9-C475-4855-A26B-32489C21C025@bbn.com> To: "Richard L. Barnes" X-Mailer: Apple Mail (2.1244.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8 Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] SWATting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 18:12:39 -0000 You would also have to provide a fake credit card, as I suspect none of = the E911 interconnected VoIP providers provide free service. Plus, you'd = probably also would need to use a non-traceable IP address, such as a = coffee shop WiFi AP. If somebody knows how this "works", please let me know. (I might want to = talk to individuals with knowledge about this off-line wearing another = hat.) Henning On Jul 26, 2011, at 2:01 PM, Richard L. Barnes wrote: > Does anyone on this list know how these attacks are accomplished? =20 >=20 > The only obvious approaches that occur to me are CLI spoofing and = lying on a VoIP provider's registration form (coincidentally, the same = things that Wikipedia suggests). But in the case I mention below, they = say that the call was from "a non-valid number". >=20 > Incidentally, the ECRIT equivalent of CLI spoofing is IP address = spoofing (when the LIS is locating based on IP address). So it might be = worth referring to BCP 38 somewhere.=20 >=20 > --Richard >=20 >=20 >=20 > On Jul 26, 2011, at 1:44 PM, Hannes Tschofenig wrote: >=20 >> I also say this one recently: "Xboxer SWATTED by armed cops after = online spat"=20 >> http://www.theregister.co.uk/2011/06/30/xbox_swat_police_rait/ >>=20 >>=20 >> On Jul 26, 2011, at 1:12 PM, Marc Linsner wrote: >>=20 >>> Or the reference Hannes uses: >>>=20 >>> http://www.fbi.gov/news/stories/2008/february/swatting020408 >>>=20 >>>=20 >>> -Marc- >>>=20 >>> -----Original Message----- >>> From: "Richard L. Barnes" >>> Date: Tue, 26 Jul 2011 12:21:57 -0400 >>> To: "ecrit@ietf.org Org" >>> Subject: [Ecrit] SWATting >>>=20 >>>> I heard from some people that they had not heard the verb "to SWAT" >>>> before the ECRIT meeting tomorrow. Today's news has a new example: >>>> = >>> d-swat-to-womans-house-20110726-1hxqm.html> >>>>=20 >>>> This is a vulnerability of the current system, but the trustworthy >>>> location document is intended to quantify the risk of similar = attacks in >>>> the ECRIT environment. >>>>=20 >>>> --Richard >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 From bernard_aboba@hotmail.com Tue Jul 26 11:23:19 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 572AB21F8696 for ; Tue, 26 Jul 2011 11:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[AWL=0.599, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUS1uWt6uqJk for ; Tue, 26 Jul 2011 11:23:18 -0700 (PDT) Received: from blu0-omc3-s21.blu0.hotmail.com (blu0-omc3-s21.blu0.hotmail.com [65.55.116.96]) by ietfa.amsl.com (Postfix) with ESMTP id CE77321F8686 for ; Tue, 26 Jul 2011 11:23:17 -0700 (PDT) Received: from BLU0-SMTP48 ([65.55.116.72]) by blu0-omc3-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 11:23:16 -0700 X-Originating-IP: [130.129.19.47] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Received: from localhost ([130.129.19.47]) by BLU0-SMTP48.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 11:23:16 -0700 Date: Tue, 26 Jul 2011 14:23:17 -0400 From: Bernard Aboba To: Henning Schulzrinne , "Richard L. Barnes" MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-OriginalArrivalTime: 26 Jul 2011 18:23:16.0737 (UTC) FILETIME=[16A1B710:01CC4BC1] Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] SWATting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 18:23:19 -0000 VGhlIGFydGljbGUgcmVmZXJzIHRvIHVzZSBvZiBhIHJlbGF5IHNlcnZpY2UgYnV0IGRvZXNuJ3Qg cHJvdmlkZSBkZXRhaWxzLgoKSGVubmluZyBTY2h1bHpyaW5uZSA8aGdzQGNzLmNvbHVtYmlhLmVk dT4gd3JvdGU6Cgo+WW91IHdvdWxkIGFsc28gaGF2ZSB0byBwcm92aWRlIGEgZmFrZSBjcmVkaXQg Y2FyZCwgYXMgSSBzdXNwZWN0IG5vbmUgb2YgdGhlIEU5MTEgaW50ZXJjb25uZWN0ZWQgVm9JUCBw cm92aWRlcnMgcHJvdmlkZSBmcmVlIHNlcnZpY2UuIFBsdXMsIHlvdSdkIHByb2JhYmx5IGFsc28g d291bGQgbmVlZCB0byB1c2UgYSBub24tdHJhY2VhYmxlIElQIGFkZHJlc3MsIHN1Y2ggYXMgYSBj b2ZmZWUgc2hvcCBXaUZpIEFQLgo+Cj5JZiBzb21lYm9keSBrbm93cyBob3cgdGhpcyAid29ya3Mi LCBwbGVhc2UgbGV0IG1lIGtub3cuIChJIG1pZ2h0IHdhbnQgdG8gdGFsayB0byBpbmRpdmlkdWFs cyB3aXRoIGtub3dsZWRnZSBhYm91dCB0aGlzIG9mZi1saW5lIHdlYXJpbmcgYW5vdGhlciBoYXQu KQo+Cj5IZW5uaW5nCj4KPk9uIEp1bCAyNiwgMjAxMSwgYXQgMjowMSBQTSwgUmljaGFyZCBMLiBC YXJuZXMgd3JvdGU6Cj4KPj4gRG9lcyBhbnlvbmUgb24gdGhpcyBsaXN0IGtub3cgaG93IHRoZXNl IGF0dGFja3MgYXJlIGFjY29tcGxpc2hlZD8gIAo+PiAKPj4gVGhlIG9ubHkgb2J2aW91cyBhcHBy b2FjaGVzIHRoYXQgb2NjdXIgdG8gbWUgYXJlIENMSSBzcG9vZmluZyBhbmQgbHlpbmcgb24gYSBW b0lQIHByb3ZpZGVyJ3MgcmVnaXN0cmF0aW9uIGZvcm0gKGNvaW5jaWRlbnRhbGx5LCB0aGUgc2Ft ZSB0aGluZ3MgdGhhdCBXaWtpcGVkaWEgc3VnZ2VzdHMpLiAgQnV0IGluIHRoZSBjYXNlIEkgbWVu dGlvbiBiZWxvdywgdGhleSBzYXkgdGhhdCB0aGUgY2FsbCB3YXMgZnJvbSAiYSBub24tdmFsaWQg bnVtYmVyIi4KPj4gCj4+IEluY2lkZW50YWxseSwgdGhlIEVDUklUIGVxdWl2YWxlbnQgb2YgQ0xJ IHNwb29maW5nIGlzIElQIGFkZHJlc3Mgc3Bvb2ZpbmcgKHdoZW4gdGhlIExJUyBpcyBsb2NhdGlu ZyBiYXNlZCBvbiBJUCBhZGRyZXNzKS4gIFNvIGl0IG1pZ2h0IGJlIHdvcnRoIHJlZmVycmluZyB0 byBCQ1AgMzggc29tZXdoZXJlLiAKPj4gCj4+IC0tUmljaGFyZAo+PiAKPj4gCj4+IAo+PiBPbiBK dWwgMjYsIDIwMTEsIGF0IDE6NDQgUE0sIEhhbm5lcyBUc2Nob2ZlbmlnIHdyb3RlOgo+PiAKPj4+ IEkgYWxzbyBzYXkgdGhpcyBvbmUgcmVjZW50bHk6ICAiWGJveGVyIFNXQVRURUQgYnkgYXJtZWQg Y29wcyBhZnRlciBvbmxpbmUgc3BhdCIgCj4+PiBodHRwOi8vd3d3LnRoZXJlZ2lzdGVyLmNvLnVr LzIwMTEvMDYvMzAveGJveF9zd2F0X3BvbGljZV9yYWl0Lwo+Pj4gCj4+PiAKPj4+IE9uIEp1bCAy NiwgMjAxMSwgYXQgMToxMiBQTSwgTWFyYyBMaW5zbmVyIHdyb3RlOgo+Pj4gCj4+Pj4gT3IgdGhl IHJlZmVyZW5jZSBIYW5uZXMgdXNlczoKPj4+PiAKPj4+PiBodHRwOi8vd3d3LmZiaS5nb3YvbmV3 cy9zdG9yaWVzLzIwMDgvZmVicnVhcnkvc3dhdHRpbmcwMjA0MDgKPj4+PiAKPj4+PiAKPj4+PiAt TWFyYy0KPj4+PiAKPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+Pj4+IEZyb206ICJS aWNoYXJkIEwuIEJhcm5lcyIgPHJiYXJuZXNAYmJuLmNvbT4KPj4+PiBEYXRlOiBUdWUsIDI2IEp1 bCAyMDExIDEyOjIxOjU3IC0wNDAwCj4+Pj4gVG86ICJlY3JpdEBpZXRmLm9yZyBPcmciIDxlY3Jp dEBpZXRmLm9yZz4KPj4+PiBTdWJqZWN0OiBbRWNyaXRdIFNXQVR0aW5nCj4+Pj4gCj4+Pj4+IEkg aGVhcmQgZnJvbSBzb21lIHBlb3BsZSB0aGF0IHRoZXkgaGFkIG5vdCBoZWFyZCB0aGUgdmVyYiAi dG8gU1dBVCIKPj4+Pj4gYmVmb3JlIHRoZSBFQ1JJVCBtZWV0aW5nIHRvbW9ycm93LiBUb2RheSdz IG5ld3MgaGFzIGEgbmV3IGV4YW1wbGU6Cj4+Pj4+IDxodHRwOi8vd3d3LnNtaC5jb20uYXUvdGVj aG5vbG9neS90ZWNobm9sb2d5LW5ld3MvcHJhbmstZHJhd3MtMzAtcG9saWNlLWFuCj4+Pj4+IGQt c3dhdC10by13b21hbnMtaG91c2UtMjAxMTA3MjYtMWh4cW0uaHRtbD4KPj4+Pj4gCj4+Pj4+IFRo aXMgaXMgYSB2dWxuZXJhYmlsaXR5IG9mIHRoZSBjdXJyZW50IHN5c3RlbSwgYnV0IHRoZSB0cnVz dHdvcnRoeQo+Pj4+PiBsb2NhdGlvbiBkb2N1bWVudCBpcyBpbnRlbmRlZCB0byBxdWFudGlmeSB0 aGUgcmlzayBvZiBzaW1pbGFyIGF0dGFja3MgaW4KPj4+Pj4gdGhlIEVDUklUIGVudmlyb25tZW50 Lgo+Pj4+PiAKPj4+Pj4gLS1SaWNoYXJkCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCj4+Pj4+IEVjcml0IG1haWxpbmcgbGlzdAo+Pj4+PiBFY3Jp dEBpZXRmLm9yZwo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vj cml0Cj4+Pj4gCj4+Pj4gCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18KPj4+PiBFY3JpdCBtYWlsaW5nIGxpc3QKPj4+PiBFY3JpdEBpZXRmLm9yZwo+ Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQKPj4+IAo+PiAK Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4gRWNy aXQgbWFpbGluZyBsaXN0Cj4+IEVjcml0QGlldGYub3JnCj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZWNyaXQKPj4gCj4KPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCj5FY3JpdCBtYWlsaW5nIGxpc3QKPkVjcml0QGlldGYub3Jn Cj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0Cj4K From john@johnlange.ca Tue Jul 26 11:40:25 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747D821F8B07 for ; Tue, 26 Jul 2011 11:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 729KVin4aahL for ; Tue, 26 Jul 2011 11:40:24 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7FECC21F8B06 for ; Tue, 26 Jul 2011 11:40:24 -0700 (PDT) Received: by gxk19 with SMTP id 19so584638gxk.31 for ; Tue, 26 Jul 2011 11:40:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.118.204 with SMTP id w12mr5787486ibq.170.1311705623875; Tue, 26 Jul 2011 11:40:23 -0700 (PDT) Received: by 10.42.222.66 with HTTP; Tue, 26 Jul 2011 11:40:23 -0700 (PDT) X-Originating-IP: [199.27.223.254] In-Reply-To: <850E78F3-C96C-43E8-B2C7-95925DE6D6DB@cs.columbia.edu> References: <0B276671-78E3-4F18-BB49-A9B4E52A7213@gmx.net> <99ED83A9-C475-4855-A26B-32489C21C025@bbn.com> <850E78F3-C96C-43E8-B2C7-95925DE6D6DB@cs.columbia.edu> Date: Tue, 26 Jul 2011 13:40:23 -0500 Message-ID: From: John Lange To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Ecrit] SWATting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 18:40:25 -0000 You would just sign up for, or hack into a VOIP service which allows you to set your own outbound caller ID. Or possible a corporate VOIP server that is vulnerable. Then, just to be on the safe side, use whatever method you can to hide your IP address when placing the call, such as a Wifi hotspot or similar. Hiding your IP address is probably optional because I've not seen much interest on the part of the Telco's to track down calls from "fake" numbers despite the rampant fraud and nuisance they regularly cause. -- John Lange www.johnlange.ca From Martin.Thomson@commscope.com Tue Jul 26 12:36:48 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17FE011E8089 for ; Tue, 26 Jul 2011 12:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9Bjq13DT9yD for ; Tue, 26 Jul 2011 12:36:47 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 8A79211E8088 for ; Tue, 26 Jul 2011 12:36:47 -0700 (PDT) X-AuditID: 0a0404e8-b7c24ae000002adb-b8-4e2f175b35e1 Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id 30.F0.10971.B571F2E4; Tue, 26 Jul 2011 14:36:59 -0500 (CDT) Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.159.2; Tue, 26 Jul 2011 14:36: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, 27 Jul 2011 03:36:44 +0800 From: "Thomson, Martin" To: Henning Schulzrinne , "Richard L. Barnes" Date: Wed, 27 Jul 2011 03:36:36 +0800 Thread-Topic: [Ecrit] SWATting Thread-Index: AcxLv7TRVAvmynTAS9eJAvY+cj921AAC0S6g Message-ID: <8B0A9FCBB9832F43971E38010638454F040D2C361F@SISPE7MB1.commscope.com> References: <0B276671-78E3-4F18-BB49-A9B4E52A7213@gmx.net> <99ED83A9-C475-4855-A26B-32489C21C025@bbn.com> <850E78F3-C96C-43E8-B2C7-95925DE6D6DB@cs.columbia.edu> In-Reply-To: <850E78F3-C96C-43E8-B2C7-95925DE6D6DB@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: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] SWATting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 19:36:48 -0000 On 2011-07-26 at 14:12:30, Henning Schulzrinne wrote: > You would also have to provide a fake credit card, as I suspect none=20 > of the E911 interconnected VoIP providers provide free service. Plus,=20 > you'd probably also would need to use a non-traceable IP address, such=20 > as a coffee shop WiFi AP. It is possible to buy a pre-paid credit card with which to purchase a servi= ce. Such a card is indistinguishable from the real thing, but it requires = no authentication. For something like this, it would depend on whether the name on the card ma= tters to the service, but I suspect that it would not to many. Capacity to= pay tends to be the primary characteristic that is sought by operators. --Martin From dmarnold@verizon.net Tue Jul 26 17:50:56 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F23D11E80D4 for ; Tue, 26 Jul 2011 17:50:56 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGJ8vV3HlzFk for ; Tue, 26 Jul 2011 17:50:55 -0700 (PDT) Received: from vms173017pub.verizon.net (vms173017pub.verizon.net [206.46.173.17]) by ietfa.amsl.com (Postfix) with ESMTP id D6E9311E80C2 for ; Tue, 26 Jul 2011 17:50:55 -0700 (PDT) Received: from DelaineHP ([unknown] [76.108.107.195]) by vms173017.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0LOY0046HVOB1W90@vms173017.mailsrvcs.net> for ecrit@ietf.org; Tue, 26 Jul 2011 19:50:38 -0500 (CDT) From: "Delaine Arnold ENP" To: References: <0B276671-78E3-4F18-BB49-A9B4E52A7213@gmx.net> <99ED83A9-C475-4855-A26B-32489C21C025@bbn.com> <850E78F3-C96C-43E8-B2C7-95925DE6D6DB@cs.columbia.edu> <8B0A9FCBB9832F43971E38010638454F040D2C361F@SISPE7MB1.commscope.com> In-reply-to: <8B0A9FCBB9832F43971E38010638454F040D2C361F@SISPE7MB1.commscope.com> Date: Tue, 26 Jul 2011 20:50:31 -0400 Message-id: <01a101cc4bf7$31829af0$9487d0d0$@net> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcxLv7TRVAvmynTAS9eJAvY+cj921AAC0S6gAApQFRA= Content-language: en-us Subject: Re: [Ecrit] SWATting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 00:50:56 -0000 I was on a NENA conference call earlier today and a gentleman from Montgomery County, PA, was telling us about some major SKYPE phone = swatting issues going on across the US. PSAPs are being called, linked together = and then loud party noises and music are being played. If the calltaker = hangs up, within 2-3 minutes they get another call with the same noise - it = ties up their lines. They have finally assigned one calltaker to just answer these and let them play themselves out. They have been working with = Level 3 who supposedly provides the IP service for SKYPE. If you need more information, I can provide the person's name and contact info. Thank you, Delaine --------------------------------------- Delaine M. Arnold, ENP Chair, NENA Data Technical Committee Voice:=A0 813-960-1698 Cell:=A0=A0=A0=A0 813-928-1692 Email:=A0 dmarnold@verizon.net -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Thomson, Martin Sent: Tuesday, July 26, 2011 3:37 PM To: Henning Schulzrinne; Richard L. Barnes Cc: ecrit@ietf.org Org Subject: Re: [Ecrit] SWATting On 2011-07-26 at 14:12:30, Henning Schulzrinne wrote: > You would also have to provide a fake credit card, as I suspect none=20 > of the E911 interconnected VoIP providers provide free service. Plus,=20 > you'd probably also would need to use a non-traceable IP address, such = > as a coffee shop WiFi AP. It is possible to buy a pre-paid credit card with which to purchase a service. Such a card is indistinguishable from the real thing, but it requires no authentication. For something like this, it would depend on whether the name on the card matters to the service, but I suspect that it would not to many. = Capacity to pay tends to be the primary characteristic that is sought by = operators. --Martin _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From bernard_aboba@hotmail.com Tue Jul 26 17:51:34 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB01411E80E0 for ; Tue, 26 Jul 2011 17:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.962 X-Spam-Level: X-Spam-Status: No, score=-101.962 tagged_above=-999 required=5 tests=[AWL=0.636, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRuU16s30xxr for ; Tue, 26 Jul 2011 17:51:33 -0700 (PDT) Received: from blu0-omc2-s12.blu0.hotmail.com (blu0-omc2-s12.blu0.hotmail.com [65.55.111.87]) by ietfa.amsl.com (Postfix) with ESMTP id 9176F11E80DC for ; Tue, 26 Jul 2011 17:51:33 -0700 (PDT) Received: from BLU152-W38 ([65.55.111.73]) by blu0-omc2-s12.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 17:51:27 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_1fa6fb71-de4c-47a0-af10-d88c4b196bf3_" X-Originating-IP: [130.129.64.90] From: Bernard Aboba To: , , "Richard L. Barnes" Date: Tue, 26 Jul 2011 17:51:26 -0700 Importance: Normal In-Reply-To: <8B0A9FCBB9832F43971E38010638454F040D2C361F@SISPE7MB1.commscope.com> References: , <0B276671-78E3-4F18-BB49-A9B4E52A7213@gmx.net>, <99ED83A9-C475-4855-A26B-32489C21C025@bbn.com>, <850E78F3-C96C-43E8-B2C7-95925DE6D6DB@cs.columbia.edu>, <8B0A9FCBB9832F43971E38010638454F040D2C361F@SISPE7MB1.commscope.com> MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jul 2011 00:51:27.0324 (UTC) FILETIME=[50E741C0:01CC4BF7] Cc: ecrit@ietf.org Subject: Re: [Ecrit] SWATting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 00:51:34 -0000 --_1fa6fb71-de4c-47a0-af10-d88c4b196bf3_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable An incident from 2007: http://www.seattlepi.com/default/article/Teen-who-hacked-California-911-sys= tem-pleads-1268326.php http://www.heraldnet.com/article/20071016/NEWS01/71016015 > From: Martin.Thomson@commscope.com > To: hgs@cs.columbia.edu=3B rbarnes@bbn.com > Date: Wed=2C 27 Jul 2011 03:36:36 +0800 > CC: ecrit@ietf.org > Subject: Re: [Ecrit] SWATting >=20 > On 2011-07-26 at 14:12:30=2C Henning Schulzrinne wrote: > > You would also have to provide a fake credit card=2C as I suspect none= =20 > > of the E911 interconnected VoIP providers provide free service. Plus=2C= =20 > > you'd probably also would need to use a non-traceable IP address=2C suc= h=20 > > as a coffee shop WiFi AP. >=20 > It is possible to buy a pre-paid credit card with which to purchase a ser= vice. Such a card is indistinguishable from the real thing=2C but it requi= res no authentication. >=20 > For something like this=2C it would depend on whether the name on the car= d matters to the service=2C but I suspect that it would not to many. Capac= ity to pay tends to be the primary characteristic that is sought by operato= rs. >=20 > --Martin > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit = --_1fa6fb71-de4c-47a0-af10-d88c4b196bf3_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
An incident from 2007:
http://www.seattlepi.com/default/article/Teen-who= -hacked-California-911-system-pleads-1268326.php
http://www.heraldnet.co= m/article/20071016/NEWS01/71016015


>=3B From: Martin.Thom= son@commscope.com
>=3B To: hgs@cs.columbia.edu=3B rbarnes@bbn.com
&= gt=3B Date: Wed=2C 27 Jul 2011 03:36:36 +0800
>=3B CC: ecrit@ietf.org<= br>>=3B Subject: Re: [Ecrit] SWATting
>=3B
>=3B On 2011-07-26 = at 14:12:30=2C Henning Schulzrinne wrote:
>=3B >=3B You would also h= ave to provide a fake credit card=2C as I suspect none
>=3B >=3B of= the E911 interconnected VoIP providers provide free service. Plus=2C
&= gt=3B >=3B you'd probably also would need to use a non-traceable IP addre= ss=2C such
>=3B >=3B as a coffee shop WiFi AP.
>=3B
>=3B= It is possible to buy a pre-paid credit card with which to purchase a serv= ice. Such a card is indistinguishable from the real thing=2C but it requir= es no authentication.
>=3B
>=3B For something like this=2C it wo= uld depend on whether the name on the card matters to the service=2C but I = suspect that it would not to many. Capacity to pay tends to be the primary= characteristic that is sought by operators.
>=3B
>=3B --Martin<= br>>=3B _______________________________________________
>=3B Ecrit m= ailing list
>=3B Ecrit@ietf.org
>=3B https://www.ietf.org/mailman= /listinfo/ecrit
= --_1fa6fb71-de4c-47a0-af10-d88c4b196bf3_-- From Martin.Dawson@commscope.com Tue Jul 26 19:17:28 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0517E21F8AB8 for ; Tue, 26 Jul 2011 19:17:28 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2UmVMN-fIVz for ; Tue, 26 Jul 2011 19:17:27 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id E5C2E21F8AA8 for ; Tue, 26 Jul 2011 19:17:26 -0700 (PDT) X-AuditID: 0a0404e9-b7cc4ae00000074e-53-4e2f753f7dd3 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id DB.00.01870.F357F2E4; Tue, 26 Jul 2011 21:17:35 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.159.2; Tue, 26 Jul 2011 21:17:23 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 27 Jul 2011 10:17:17 +0800 From: "Dawson, Martin" To: "Richard L. Barnes" , Hannes Tschofenig Date: Wed, 27 Jul 2011 10:17:15 +0800 Thread-Topic: [Ecrit] SWATting Thread-Index: AcxLvgLvT3sq2NMFQHCm5BAuQsItRwAQ/DNg Message-ID: <8B0A9FCBB9832F43971E38010638454F040D2C36A8@SISPE7MB1.commscope.com> References: <0B276671-78E3-4F18-BB49-A9B4E52A7213@gmx.net> <99ED83A9-C475-4855-A26B-32489C21C025@bbn.com> In-Reply-To: <99ED83A9-C475-4855-A26B-32489C21C025@bbn.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] SWATting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 02:17:28 -0000 "... ECRIT equivalent of CLI spoofing is IP address spoofing (when the LIS = is locating based on IP address). " That might be the equivalent of "CLI spoofing" but the real issue is locati= on spoofing. In use cases that allow the terminal to deliver a literal PIDF= -LO then the ability to spoof location is direct; just craft your own PIDF-= LO. This is why it's important to be able to utilize delivery as location-b= y-reference so that PSAPs can apply a different policy based on whether loc= ation is just provided literally or whether there's the opportunity to sour= ce it from a recognized operator within the PSAP catchment (and in the abse= nce of any other mechanism such as ISP-signed PIDF-LO). Regulators wrestle with assumptions about interconnected VoIP providers but= that's a PSTN hangover and not a basis for long term policy - especially r= elying on something as tenuous as whether such VoIP providers only hand out= subscriptions to users with identity-verified credit cards.=20 Cheers, Martin -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of R= ichard L. Barnes Sent: Wednesday, 27 July 2011 4:01 AM To: Hannes Tschofenig Cc: ecrit@ietf.org Org Subject: Re: [Ecrit] SWATting Does anyone on this list know how these attacks are accomplished? =20 The only obvious approaches that occur to me are CLI spoofing and lying on = a VoIP provider's registration form (coincidentally, the same things that W= ikipedia suggests). But in the case I mention below, they say that the cal= l was from "a non-valid number". Incidentally, the ECRIT equivalent of CLI spoofing is IP address spoofing (= when the LIS is locating based on IP address). So it might be worth referr= ing to BCP 38 somewhere.=20 --Richard On Jul 26, 2011, at 1:44 PM, Hannes Tschofenig wrote: > I also say this one recently: "Xboxer SWATTED by armed cops after online= spat"=20 > http://www.theregister.co.uk/2011/06/30/xbox_swat_police_rait/ >=20 >=20 > On Jul 26, 2011, at 1:12 PM, Marc Linsner wrote: >=20 >> Or the reference Hannes uses: >>=20 >> http://www.fbi.gov/news/stories/2008/february/swatting020408 >>=20 >>=20 >> -Marc- >>=20 >> -----Original Message----- >> From: "Richard L. Barnes" >> Date: Tue, 26 Jul 2011 12:21:57 -0400 >> To: "ecrit@ietf.org Org" >> Subject: [Ecrit] SWATting >>=20 >>> I heard from some people that they had not heard the verb "to SWAT" >>> before the ECRIT meeting tomorrow. Today's news has a new example: >>> >> d-swat-to-womans-house-20110726-1hxqm.html> >>>=20 >>> This is a vulnerability of the current system, but the trustworthy >>> location document is intended to quantify the risk of similar attacks i= n >>> the ECRIT environment. >>>=20 >>> --Richard >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >>=20 >> _______________________________________________ >> 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 mlinsner@cisco.com Tue Jul 26 19:40:04 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37E311E80CB for ; Tue, 26 Jul 2011 19:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEMpd3dsmvp3 for ; Tue, 26 Jul 2011 19:40:03 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0AEB511E80EE for ; Tue, 26 Jul 2011 19:40:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mlinsner@cisco.com; l=4082; q=dns/txt; s=iport; t=1311734403; x=1312944003; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=744lkKDsAtNwLdyFzh8tmYZzXonBrYBS1Jn/0xl5GbY=; b=mbH4Y5mYex9IJ7NiA7+JsjR1iLYoZ5PuaLnIk81GPbqbvkq2SKKuvQa0 Kv5dfzb/xyyjMbjaL1Ze+cE3Ft7qxVBm3FpsllEZcLUaP2r0tFn0yqEjJ lfPhICX8N3izqE+12PNRHUFWWHPRsqvFG407lrT54Tscd1pYzBI1WRlOj s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAC16L06tJV2Y/2dsb2JhbAAqCwEBAQEDAQEBEQErAwE2CwwICREDAQEBARccGxgjDggHDwgfCKcpd4kAo2SGPZgTgySDHASScoUHi3U X-IronPort-AV: E=Sophos;i="4.67,273,1309737600"; d="scan'208";a="6755076" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 27 Jul 2011 02:40:02 +0000 Received: from [10.86.246.117] ([10.86.246.117]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6R2e0AT007662; Wed, 27 Jul 2011 02:40:01 GMT User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Tue, 26 Jul 2011 22:39:59 -0400 From: Marc Linsner To: "Dawson, Martin" Message-ID: Thread-Topic: [Ecrit] SWATting In-Reply-To: <8B0A9FCBB9832F43971E38010638454F040D2C36A8@SISPE7MB1.commscope.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] SWATting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 02:40:04 -0000 Martin, I believe the point was that IP address spoofing coupled with a stolen uri from the used IP address is location spoofing to a PSAP. BTW, current PSTN location mechanisms are in fact LbyR via a recognized operator. -Marc- -----Original Message----- From: "Dawson, Martin" Date: Wed, 27 Jul 2011 10:17:15 +0800 To: "Richard L. Barnes" , Hannes Tschofenig Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] SWATting >"... ECRIT equivalent of CLI spoofing is IP address spoofing (when the >LIS is locating based on IP address). " > >That might be the equivalent of "CLI spoofing" but the real issue is >location spoofing. In use cases that allow the terminal to deliver a >literal PIDF-LO then the ability to spoof location is direct; just craft >your own PIDF-LO. This is why it's important to be able to utilize >delivery as location-by-reference so that PSAPs can apply a different >policy based on whether location is just provided literally or whether >there's the opportunity to source it from a recognized operator within >the PSAP catchment (and in the absence of any other mechanism such as >ISP-signed PIDF-LO). > >Regulators wrestle with assumptions about interconnected VoIP providers >but that's a PSTN hangover and not a basis for long term policy - >especially relying on something as tenuous as whether such VoIP providers >only hand out subscriptions to users with identity-verified credit cards. > >Cheers, >Martin > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >Richard L. Barnes >Sent: Wednesday, 27 July 2011 4:01 AM >To: Hannes Tschofenig >Cc: ecrit@ietf.org Org >Subject: Re: [Ecrit] SWATting > >Does anyone on this list know how these attacks are accomplished? > >The only obvious approaches that occur to me are CLI spoofing and lying >on a VoIP provider's registration form (coincidentally, the same things >that Wikipedia suggests). But in the case I mention below, they say that >the call was from "a non-valid number". > >Incidentally, the ECRIT equivalent of CLI spoofing is IP address spoofing >(when the LIS is locating based on IP address). So it might be worth >referring to BCP 38 somewhere. > >--Richard > > > >On Jul 26, 2011, at 1:44 PM, Hannes Tschofenig wrote: > >> I also say this one recently: "Xboxer SWATTED by armed cops after >>online spat" >> http://www.theregister.co.uk/2011/06/30/xbox_swat_police_rait/ >> >> >> On Jul 26, 2011, at 1:12 PM, Marc Linsner wrote: >> >>> Or the reference Hannes uses: >>> >>> http://www.fbi.gov/news/stories/2008/february/swatting020408 >>> >>> >>> -Marc- >>> >>> -----Original Message----- >>> From: "Richard L. Barnes" >>> Date: Tue, 26 Jul 2011 12:21:57 -0400 >>> To: "ecrit@ietf.org Org" >>> Subject: [Ecrit] SWATting >>> >>>> I heard from some people that they had not heard the verb "to SWAT" >>>> before the ECRIT meeting tomorrow. Today's news has a new example: >>>> >>>>>>>-an >>>> d-swat-to-womans-house-20110726-1hxqm.html> >>>> >>>> This is a vulnerability of the current system, but the trustworthy >>>> location document is intended to quantify the risk of similar attacks >>>>in >>>> the ECRIT environment. >>>> >>>> --Richard >>>> _______________________________________________ >>>> 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@commscope.com Tue Jul 26 21:25:39 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D251B21F84C7 for ; Tue, 26 Jul 2011 21:25:39 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7olFJSw-LAN for ; Tue, 26 Jul 2011 21:25:38 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id C6E4821F84C9 for ; Tue, 26 Jul 2011 21:25:38 -0700 (PDT) X-AuditID: 0a0404e8-b7c24ae000002adb-bd-4e2f934ec0e9 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id 95.9A.10971.E439F2E4; Tue, 26 Jul 2011 23:25:50 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.159.2; Tue, 26 Jul 2011 23:25:37 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 27 Jul 2011 12:25:34 +0800 From: "Dawson, Martin" To: Marc Linsner Date: Wed, 27 Jul 2011 12:25:32 +0800 Thread-Topic: [Ecrit] SWATting Thread-Index: AcxMBpTxpjpjtY5+ShSdOMpL1xOpwgADj8zQ Message-ID: <8B0A9FCBB9832F43971E38010638454F040D2C3700@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F040D2C36A8@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: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] SWATting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 04:25:39 -0000 What is the method by which somebody spoofs an IP address to fool an ISP LI= S into giving them a PIDF-LO or location reference applicable to a differen= t location? How would this be done? Cheers, Martin -----Original Message----- From: Marc Linsner [mailto:mlinsner@cisco.com]=20 Sent: Wednesday, 27 July 2011 12:40 PM To: Dawson, Martin Cc: ecrit@ietf.org Org Subject: Re: [Ecrit] SWATting Martin, I believe the point was that IP address spoofing coupled with a stolen uri from the used IP address is location spoofing to a PSAP. BTW, current PSTN location mechanisms are in fact LbyR via a recognized operator. -Marc- -----Original Message----- From: "Dawson, Martin" Date: Wed, 27 Jul 2011 10:17:15 +0800 To: "Richard L. Barnes" , Hannes Tschofenig Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] SWATting >"... ECRIT equivalent of CLI spoofing is IP address spoofing (when the >LIS is locating based on IP address). " > >That might be the equivalent of "CLI spoofing" but the real issue is >location spoofing. In use cases that allow the terminal to deliver a >literal PIDF-LO then the ability to spoof location is direct; just craft >your own PIDF-LO. This is why it's important to be able to utilize >delivery as location-by-reference so that PSAPs can apply a different >policy based on whether location is just provided literally or whether >there's the opportunity to source it from a recognized operator within >the PSAP catchment (and in the absence of any other mechanism such as >ISP-signed PIDF-LO). > >Regulators wrestle with assumptions about interconnected VoIP providers >but that's a PSTN hangover and not a basis for long term policy - >especially relying on something as tenuous as whether such VoIP providers >only hand out subscriptions to users with identity-verified credit cards. > >Cheers, >Martin > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >Richard L. Barnes >Sent: Wednesday, 27 July 2011 4:01 AM >To: Hannes Tschofenig >Cc: ecrit@ietf.org Org >Subject: Re: [Ecrit] SWATting > >Does anyone on this list know how these attacks are accomplished? > >The only obvious approaches that occur to me are CLI spoofing and lying >on a VoIP provider's registration form (coincidentally, the same things >that Wikipedia suggests). But in the case I mention below, they say that >the call was from "a non-valid number". > >Incidentally, the ECRIT equivalent of CLI spoofing is IP address spoofing >(when the LIS is locating based on IP address). So it might be worth >referring to BCP 38 somewhere. > >--Richard > > > >On Jul 26, 2011, at 1:44 PM, Hannes Tschofenig wrote: > >> I also say this one recently: "Xboxer SWATTED by armed cops after >>online spat"=20 >> http://www.theregister.co.uk/2011/06/30/xbox_swat_police_rait/ >>=20 >>=20 >> On Jul 26, 2011, at 1:12 PM, Marc Linsner wrote: >>=20 >>> Or the reference Hannes uses: >>>=20 >>> http://www.fbi.gov/news/stories/2008/february/swatting020408 >>>=20 >>>=20 >>> -Marc- >>>=20 >>> -----Original Message----- >>> From: "Richard L. Barnes" >>> Date: Tue, 26 Jul 2011 12:21:57 -0400 >>> To: "ecrit@ietf.org Org" >>> Subject: [Ecrit] SWATting >>>=20 >>>> I heard from some people that they had not heard the verb "to SWAT" >>>> before the ECRIT meeting tomorrow. Today's news has a new example: >>>>=20 >>>>>>>-an >>>> d-swat-to-womans-house-20110726-1hxqm.html> >>>>=20 >>>> This is a vulnerability of the current system, but the trustworthy >>>> location document is intended to quantify the risk of similar attacks >>>>in >>>> the ECRIT environment. >>>>=20 >>>> --Richard >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>>=20 >>> _______________________________________________ >>> 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 >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From rbarnes@bbn.com Tue Jul 26 22:11:21 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC5E21F8A51 for ; Tue, 26 Jul 2011 22:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.593 X-Spam-Level: X-Spam-Status: No, score=-106.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B08Bb35bfTus for ; Tue, 26 Jul 2011 22:11:20 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3D021F8A4E for ; Tue, 26 Jul 2011 22:11:20 -0700 (PDT) Received: from [128.89.253.212] (port=63467 helo=dhcp-4094.meeting.ietf.org) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QlwOs-000Nru-VC; Wed, 27 Jul 2011 01:11:19 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <8B0A9FCBB9832F43971E38010638454F040D2C3700@SISPE7MB1.commscope.com> Date: Wed, 27 Jul 2011 01:11:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <44D0A147-6185-4B0F-B119-9AD23C235F4E@bbn.com> References: <8B0A9FCBB9832F43971E38010638454F040D2C36A8@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F040D2C3700@SISPE7MB1.commscope.com> To: "Dawson, Martin" X-Mailer: Apple Mail (2.1082) Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] SWATting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 05:11:21 -0000 I think risk is actually greater in the transition. If you look at = things like i2 and the NICC architecture, the user's IP address as seen = by the outbound proxy is used as the key to look up location with the = access network's LIS. So if the caller spoofs the IP on his INVITE, the = PSAP gets the wrong location. --Richard On Jul 27, 2011, at 12:25 AM, Dawson, Martin wrote: > What is the method by which somebody spoofs an IP address to fool an = ISP LIS into giving them a PIDF-LO or location reference applicable to a = different location? How would this be done? >=20 > Cheers, > Martin >=20 > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com]=20 > Sent: Wednesday, 27 July 2011 12:40 PM > To: Dawson, Martin > Cc: ecrit@ietf.org Org > Subject: Re: [Ecrit] SWATting >=20 > Martin, >=20 > I believe the point was that IP address spoofing coupled with a stolen = uri > from the used IP address is location spoofing to a PSAP. >=20 > BTW, current PSTN location mechanisms are in fact LbyR via a = recognized > operator. >=20 > -Marc- >=20 > -----Original Message----- > From: "Dawson, Martin" > Date: Wed, 27 Jul 2011 10:17:15 +0800 > To: "Richard L. Barnes" , Hannes Tschofenig > > Cc: "ecrit@ietf.org Org" > Subject: Re: [Ecrit] SWATting >=20 >> "... ECRIT equivalent of CLI spoofing is IP address spoofing (when = the >> LIS is locating based on IP address). " >>=20 >> That might be the equivalent of "CLI spoofing" but the real issue is >> location spoofing. In use cases that allow the terminal to deliver a >> literal PIDF-LO then the ability to spoof location is direct; just = craft >> your own PIDF-LO. This is why it's important to be able to utilize >> delivery as location-by-reference so that PSAPs can apply a different >> policy based on whether location is just provided literally or = whether >> there's the opportunity to source it from a recognized operator = within >> the PSAP catchment (and in the absence of any other mechanism such as >> ISP-signed PIDF-LO). >>=20 >> Regulators wrestle with assumptions about interconnected VoIP = providers >> but that's a PSTN hangover and not a basis for long term policy - >> especially relying on something as tenuous as whether such VoIP = providers >> only hand out subscriptions to users with identity-verified credit = cards. >>=20 >> Cheers, >> Martin >>=20 >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf Of >> Richard L. Barnes >> Sent: Wednesday, 27 July 2011 4:01 AM >> To: Hannes Tschofenig >> Cc: ecrit@ietf.org Org >> Subject: Re: [Ecrit] SWATting >>=20 >> Does anyone on this list know how these attacks are accomplished? >>=20 >> The only obvious approaches that occur to me are CLI spoofing and = lying >> on a VoIP provider's registration form (coincidentally, the same = things >> that Wikipedia suggests). But in the case I mention below, they say = that >> the call was from "a non-valid number". >>=20 >> Incidentally, the ECRIT equivalent of CLI spoofing is IP address = spoofing >> (when the LIS is locating based on IP address). So it might be worth >> referring to BCP 38 somewhere. >>=20 >> --Richard >>=20 >>=20 >>=20 >> On Jul 26, 2011, at 1:44 PM, Hannes Tschofenig wrote: >>=20 >>> I also say this one recently: "Xboxer SWATTED by armed cops after >>> online spat"=20 >>> http://www.theregister.co.uk/2011/06/30/xbox_swat_police_rait/ >>>=20 >>>=20 >>> On Jul 26, 2011, at 1:12 PM, Marc Linsner wrote: >>>=20 >>>> Or the reference Hannes uses: >>>>=20 >>>> http://www.fbi.gov/news/stories/2008/february/swatting020408 >>>>=20 >>>>=20 >>>> -Marc- >>>>=20 >>>> -----Original Message----- >>>> From: "Richard L. Barnes" >>>> Date: Tue, 26 Jul 2011 12:21:57 -0400 >>>> To: "ecrit@ietf.org Org" >>>> Subject: [Ecrit] SWATting >>>>=20 >>>>> I heard from some people that they had not heard the verb "to = SWAT" >>>>> before the ECRIT meeting tomorrow. Today's news has a new example: >>>>>=20 >>>>> = >>>> -an >>>>> d-swat-to-womans-house-20110726-1hxqm.html> >>>>>=20 >>>>> This is a vulnerability of the current system, but the trustworthy >>>>> location document is intended to quantify the risk of similar = attacks >>>>> in >>>>> the ECRIT environment. >>>>>=20 >>>>> --Richard >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>=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 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From bernard_aboba@hotmail.com Tue Jul 26 22:32:44 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16E2D5E8011 for ; Tue, 26 Jul 2011 22:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.025 X-Spam-Level: X-Spam-Status: No, score=-102.025 tagged_above=-999 required=5 tests=[AWL=0.573, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqKKPf+gMvzv for ; Tue, 26 Jul 2011 22:32:42 -0700 (PDT) Received: from blu0-omc2-s27.blu0.hotmail.com (blu0-omc2-s27.blu0.hotmail.com [65.55.111.102]) by ietfa.amsl.com (Postfix) with ESMTP id F3A1B21F874B for ; Tue, 26 Jul 2011 22:32:41 -0700 (PDT) Received: from BLU152-W11 ([65.55.111.72]) by blu0-omc2-s27.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 22:32:41 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_6df66aac-4235-4526-a6bf-a5eaa346dc61_" X-Originating-IP: [130.129.64.90] From: Bernard Aboba To: , Date: Tue, 26 Jul 2011 22:32:40 -0700 Importance: Normal In-Reply-To: <8B0A9FCBB9832F43971E38010638454F040D2C3700@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F040D2C36A8@SISPE7MB1.commscope.com>, , <8B0A9FCBB9832F43971E38010638454F040D2C3700@SISPE7MB1.commscope.com> MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jul 2011 05:32:41.0307 (UTC) FILETIME=[9A94BAB0:01CC4C1E] Cc: ecrit@ietf.org Subject: Re: [Ecrit] SWATting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 05:32:44 -0000 --_6df66aac-4235-4526-a6bf-a5eaa346dc61_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If the PIDF-LO isn't signed=2C you can just make one up.=20 Even if it is signed=2C for IP address spoofing with HELD=2C it is possible= to obtain a PIDF-LO for another IP address if you are on the path from the= fake source address to the LIS. Possible=2C but not easy. However=2C it is not necessary to spoof an IP address to obtain a (signed) = PIDF-LO that can be (falsely) conveyed. =20 You can have someone else obtain the (signed) PIDF-LO and give it to you to= convey within SIP ('cut and paste')=2C or you can obtain a PIDF-LO=2C chan= ge your location and then convey it later (time-shifting).=20 Even if the PIDF-LO is signed=2C and SIP uses RFC 4474=2C the 'cut and past= e' attack still works=2C if the identity in the PIDF-LO is unlinkable to th= e SIP identity (e.g. From field).=20 The time-shifting attack will work as long as the PIDF-LO timestamp is with= in the window checked by the PSAP.=20 While the PSAP may not want to necessarily reject the incoming call=2C ther= e is information that can be used in determining the "swatting" potential: 1. Checking the 'timestamp' field in the PIDF-LO against the SIP timestamp = or the time at the PSAP=3B 2. Checking fields in the PIDF-LO (such as 'contact') against the identity = in the SIP From: field=3B 3. Whether the PIDF-LO is signed=3B=20 4. Checking aspects of the signing certificate (e.g. altSubjectName)=3B 5. Whether SIP uses RFC 4474=3B As was noted in the discussion=2C this is not only about 'trustworthy locat= ion' but also about accountability. =20 If attackers feel confident that they will be held accountable (many are ca= ught now=2C after all)=2C they will be less likely to attempt these attacks= . We have seen this quite often with unauthenticated/unauthorized calling=3B = move from no SIM to a registered SIM (albeit with no balance) and voila=2C= attacks decline.=20 > From: Martin.Dawson@commscope.com > To: mlinsner@cisco.com > Date: Wed=2C 27 Jul 2011 12:25:32 +0800 > CC: ecrit@ietf.org > Subject: Re: [Ecrit] SWATting >=20 > What is the method by which somebody spoofs an IP address to fool an ISP = LIS into giving them a PIDF-LO or location reference applicable to a differ= ent location? How would this be done? >=20 > Cheers=2C > Martin >=20 > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com]=20 > Sent: Wednesday=2C 27 July 2011 12:40 PM > To: Dawson=2C Martin > Cc: ecrit@ietf.org Org > Subject: Re: [Ecrit] SWATting >=20 > Martin=2C >=20 > I believe the point was that IP address spoofing coupled with a stolen ur= i > from the used IP address is location spoofing to a PSAP. >=20 > BTW=2C current PSTN location mechanisms are in fact LbyR via a recognized > operator. >=20 > -Marc- >=20 > -----Original Message----- > From: "Dawson=2C Martin" > Date: Wed=2C 27 Jul 2011 10:17:15 +0800 > To: "Richard L. Barnes" =2C Hannes Tschofenig > > Cc: "ecrit@ietf.org Org" > Subject: Re: [Ecrit] SWATting >=20 > >"... ECRIT equivalent of CLI spoofing is IP address spoofing (when the > >LIS is locating based on IP address). " > > > >That might be the equivalent of "CLI spoofing" but the real issue is > >location spoofing. In use cases that allow the terminal to deliver a > >literal PIDF-LO then the ability to spoof location is direct=3B just cra= ft > >your own PIDF-LO. This is why it's important to be able to utilize > >delivery as location-by-reference so that PSAPs can apply a different > >policy based on whether location is just provided literally or whether > >there's the opportunity to source it from a recognized operator within > >the PSAP catchment (and in the absence of any other mechanism such as > >ISP-signed PIDF-LO). > > > >Regulators wrestle with assumptions about interconnected VoIP providers > >but that's a PSTN hangover and not a basis for long term policy - > >especially relying on something as tenuous as whether such VoIP provider= s > >only hand out subscriptions to users with identity-verified credit cards= . > > > >Cheers=2C > >Martin > > > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf O= f > >Richard L. Barnes > >Sent: Wednesday=2C 27 July 2011 4:01 AM > >To: Hannes Tschofenig > >Cc: ecrit@ietf.org Org > >Subject: Re: [Ecrit] SWATting > > > >Does anyone on this list know how these attacks are accomplished? > > > >The only obvious approaches that occur to me are CLI spoofing and lying > >on a VoIP provider's registration form (coincidentally=2C the same thing= s > >that Wikipedia suggests). But in the case I mention below=2C they say t= hat > >the call was from "a non-valid number". > > > >Incidentally=2C the ECRIT equivalent of CLI spoofing is IP address spoof= ing > >(when the LIS is locating based on IP address). So it might be worth > >referring to BCP 38 somewhere. > > > >--Richard > > > > > > > >On Jul 26=2C 2011=2C at 1:44 PM=2C Hannes Tschofenig wrote: > > > >> I also say this one recently: "Xboxer SWATTED by armed cops after > >>online spat"=20 > >> http://www.theregister.co.uk/2011/06/30/xbox_swat_police_rait/ > >>=20 > >>=20 > >> On Jul 26=2C 2011=2C at 1:12 PM=2C Marc Linsner wrote: > >>=20 > >>> Or the reference Hannes uses: > >>>=20 > >>> http://www.fbi.gov/news/stories/2008/february/swatting020408 > >>>=20 > >>>=20 > >>> -Marc- > >>>=20 > >>> -----Original Message----- > >>> From: "Richard L. Barnes" > >>> Date: Tue=2C 26 Jul 2011 12:21:57 -0400 > >>> To: "ecrit@ietf.org Org" > >>> Subject: [Ecrit] SWATting > >>>=20 > >>>> I heard from some people that they had not heard the verb "to SWAT" > >>>> before the ECRIT meeting tomorrow. Today's news has a new example: > >>>>=20 > >>>> >>>>-an > >>>> d-swat-to-womans-house-20110726-1hxqm.html> > >>>>=20 > >>>> This is a vulnerability of the current system=2C but the trustworthy > >>>> location document is intended to quantify the risk of similar attack= s > >>>>in > >>>> the ECRIT environment. > >>>>=20 > >>>> --Richard > >>>> _______________________________________________ > >>>> Ecrit mailing list > >>>> Ecrit@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>=20 > >>>=20 > >>> _______________________________________________ > >>> 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 > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit = --_6df66aac-4235-4526-a6bf-a5eaa346dc61_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
If the PIDF-LO isn't signed=2C you can just make one up.

Even if it= is signed=2C for IP address spoofing with HELD=2C it is possible to obtain= a PIDF-LO for another IP address if you are on the path from the fake sour= ce address to the LIS. =3B =3B Possible=2C but not easy.

How= ever=2C it is not necessary to spoof an IP address to obtain a (signed) PID= F-LO that can be (falsely) conveyed. =3B

You can have someone e= lse obtain the (signed) PIDF-LO and give it to you to convey within SIP ('c= ut and paste')=2C or you can obtain a PIDF-LO=2C change your location and t= hen convey it later (time-shifting).

Even if the PIDF-LO is signed= =2C and SIP uses RFC 4474=2C the 'cut and paste' attack still works=2C if t= he identity in the PIDF-LO is unlinkable to the SIP identity (e.g. From fie= ld).

The time-shifting attack will work as long as the PIDF-LO time= stamp is within the window checked by the PSAP.

While the PSAP may = not want to necessarily reject the incoming call=2C there is information th= at can be used in determining the "swatting" potential:

1. Checking = the 'timestamp' field in the PIDF-LO against the SIP timestamp or the time = at the PSAP=3B
2. Checking fields in the PIDF-LO (such as 'contact') aga= inst the identity in the SIP From: field=3B
3. Whether the PIDF-LO is si= gned=3B
4. Checking aspects of the signing certificate (e.g. altSubject= Name)=3B
5. Whether SIP uses RFC 4474=3B

As was noted in the disc= ussion=2C this is not only about 'trustworthy location' but also about acco= untability. =3B
If attackers feel confident that they will be held = accountable (many are caught now=2C after all)=2C they will be less likely = to attempt these attacks.

We have seen this quite often with unauthe= nticated/unauthorized calling=3B =3B move from no SIM to a registered S= IM (albeit with no balance) and voila=2C attacks decline.


= >=3B From: Martin.Dawson@commscope.com
>=3B To: mlinsner@cisco.com>=3B Date: Wed=2C 27 Jul 2011 12:25:32 +0800
>=3B CC: ecrit@ietf.o= rg
>=3B Subject: Re: [Ecrit] SWATting
>=3B
>=3B What is the= method by which somebody spoofs an IP address to fool an ISP LIS into givi= ng them a PIDF-LO or location reference applicable to a different location?= How would this be done?
>=3B
>=3B Cheers=2C
>=3B Martin>=3B
>=3B -----Original Message-----
>=3B From: Marc Linsner = [mailto:mlinsner@cisco.com]
>=3B Sent: Wednesday=2C 27 July 2011 12:4= 0 PM
>=3B To: Dawson=2C Martin
>=3B Cc: ecrit@ietf.org Org
>= =3B Subject: Re: [Ecrit] SWATting
>=3B
>=3B Martin=2C
>=3B =
>=3B I believe the point was that IP address spoofing coupled with a = stolen uri
>=3B from the used IP address is location spoofing to a PSA= P.
>=3B
>=3B BTW=2C current PSTN location mechanisms are in fact= LbyR via a recognized
>=3B operator.
>=3B
>=3B -Marc-
&= gt=3B
>=3B -----Original Message-----
>=3B From: "Dawson=2C Mart= in" <=3BMartin.Dawson@commscope.com>=3B
>=3B Date: Wed=2C 27 Jul 2= 011 10:17:15 +0800
>=3B To: "Richard L. Barnes" <=3Brbarnes@bbn.com&= gt=3B=2C Hannes Tschofenig
>=3B <=3Bhannes.tschofenig@gmx.net>=3B<= br>>=3B Cc: "ecrit@ietf.org Org" <=3Becrit@ietf.org>=3B
>=3B Sub= ject: Re: [Ecrit] SWATting
>=3B
>=3B >=3B"... ECRIT equivalent= of CLI spoofing is IP address spoofing (when the
>=3B >=3BLIS is lo= cating based on IP address). "
>=3B >=3B
>=3B >=3BThat might= be the equivalent of "CLI spoofing" but the real issue is
>=3B >=3B= location spoofing. In use cases that allow the terminal to deliver a
>= =3B >=3Bliteral PIDF-LO then the ability to spoof location is direct=3B j= ust craft
>=3B >=3Byour own PIDF-LO. This is why it's important to b= e able to utilize
>=3B >=3Bdelivery as location-by-reference so that= PSAPs can apply a different
>=3B >=3Bpolicy based on whether locati= on is just provided literally or whether
>=3B >=3Bthere's the opport= unity to source it from a recognized operator within
>=3B >=3Bthe PS= AP catchment (and in the absence of any other mechanism such as
>=3B &= gt=3BISP-signed PIDF-LO).
>=3B >=3B
>=3B >=3BRegulators wrest= le with assumptions about interconnected VoIP providers
>=3B >=3Bbut= that's a PSTN hangover and not a basis for long term policy -
>=3B &g= t=3Bespecially relying on something as tenuous as whether such VoIP provide= rs
>=3B >=3Bonly hand out subscriptions to users with identity-verif= ied credit cards.
>=3B >=3B
>=3B >=3BCheers=2C
>=3B >= =3BMartin
>=3B >=3B
>=3B >=3B-----Original Message-----
&g= t=3B >=3BFrom: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf Of
>=3B >=3BRichard L. Barnes
>=3B >=3BSent: Wednesday= =2C 27 July 2011 4:01 AM
>=3B >=3BTo: Hannes Tschofenig
>=3B &g= t=3BCc: ecrit@ietf.org Org
>=3B >=3BSubject: Re: [Ecrit] SWATting>=3B >=3B
>=3B >=3BDoes anyone on this list know how these atta= cks are accomplished?
>=3B >=3B
>=3B >=3BThe only obvious app= roaches that occur to me are CLI spoofing and lying
>=3B >=3Bon a Vo= IP provider's registration form (coincidentally=2C the same things
>= =3B >=3Bthat Wikipedia suggests). But in the case I mention below=2C the= y say that
>=3B >=3Bthe call was from "a non-valid number".
>= =3B >=3B
>=3B >=3BIncidentally=2C the ECRIT equivalent of CLI spoo= fing is IP address spoofing
>=3B >=3B(when the LIS is locating based= on IP address). So it might be worth
>=3B >=3Breferring to BCP 38 = somewhere.
>=3B >=3B
>=3B >=3B--Richard
>=3B >=3B
&= gt=3B >=3B
>=3B >=3B
>=3B >=3BOn Jul 26=2C 2011=2C at 1:44 = PM=2C Hannes Tschofenig wrote:
>=3B >=3B
>=3B >=3B>=3B I al= so say this one recently: "Xboxer SWATTED by armed cops after
>=3B &g= t=3B>=3Bonline spat"
>=3B >=3B>=3B http://www.theregister.co.uk= /2011/06/30/xbox_swat_police_rait/
>=3B >=3B>=3B
>=3B >=3B= >=3B
>=3B >=3B>=3B On Jul 26=2C 2011=2C at 1:12 PM=2C Marc Lins= ner wrote:
>=3B >=3B>=3B
>=3B >=3B>=3B>=3B Or the refe= rence Hannes uses:
>=3B >=3B>=3B>=3B
>=3B >=3B>=3B>= =3B http://www.fbi.gov/news/stories/2008/february/swatting020408
>=3B = >=3B>=3B>=3B
>=3B >=3B>=3B>=3B
>=3B >=3B>=3B>= =3B -Marc-
>=3B >=3B>=3B>=3B
>=3B >=3B>=3B>=3B -----= Original Message-----
>=3B >=3B>=3B>=3B From: "Richard L. Barnes= " <=3Brbarnes@bbn.com>=3B
>=3B >=3B>=3B>=3B Date: Tue=2C 26 = Jul 2011 12:21:57 -0400
>=3B >=3B>=3B>=3B To: "ecrit@ietf.org Or= g" <=3Becrit@ietf.org>=3B
>=3B >=3B>=3B>=3B Subject: [Ecrit]= SWATting
>=3B >=3B>=3B>=3B
>=3B >=3B>=3B>=3B>=3B = I heard from some people that they had not heard the verb "to SWAT"
>= =3B >=3B>=3B>=3B>=3B before the ECRIT meeting tomorrow. Today's new= s has a new example:
>=3B >=3B>=3B>=3B>=3B
>=3B >=3B&g= t=3B>=3B>=3B<=3Bhttp://www.smh.com.au/technology/technology-news/pran= k-draws-30-police
>=3B >=3B>=3B>=3B>=3B-an
>=3B >=3B>= =3B>=3B>=3B d-swat-to-womans-house-20110726-1hxqm.html>=3B
>=3B = >=3B>=3B>=3B>=3B
>=3B >=3B>=3B>=3B>=3B This is a vuln= erability of the current system=2C but the trustworthy
>=3B >=3B>= =3B>=3B>=3B location document is intended to quantify the risk of simil= ar attacks
>=3B >=3B>=3B>=3B>=3Bin
>=3B >=3B>=3B>= =3B>=3B the ECRIT environment.
>=3B >=3B>=3B>=3B>=3B
>= =3B >=3B>=3B>=3B>=3B --Richard
>=3B >=3B>=3B>=3B>=3B _= ______________________________________________
>=3B >=3B>=3B>=3B= >=3B Ecrit mailing list
>=3B >=3B>=3B>=3B>=3B Ecrit@ietf.org=
>=3B >=3B>=3B>=3B>=3B https://www.ietf.org/mailman/listinfo/e= crit
>=3B >=3B>=3B>=3B
>=3B >=3B>=3B>=3B
>=3B = >=3B>=3B>=3B _______________________________________________
>= =3B >=3B>=3B>=3B Ecrit mailing list
>=3B >=3B>=3B>=3B Ecri= t@ietf.org
>=3B >=3B>=3B>=3B https://www.ietf.org/mailman/listin= fo/ecrit
>=3B >=3B>=3B
>=3B >=3B
>=3B >=3B_________= ______________________________________
>=3B >=3BEcrit mailing list>=3B >=3BEcrit@ietf.org
>=3B >=3Bhttps://www.ietf.org/mailman/= listinfo/ecrit
>=3B >=3B____________________________________________= ___
>=3B >=3BEcrit mailing list
>=3B >=3BEcrit@ietf.org
&g= t=3B >=3Bhttps://www.ietf.org/mailman/listinfo/ecrit
>=3B
>=3B=
>=3B _______________________________________________
>=3B Ecrit= mailing list
>=3B Ecrit@ietf.org
>=3B https://www.ietf.org/mailm= an/listinfo/ecrit
= --_6df66aac-4235-4526-a6bf-a5eaa346dc61_-- From bernard_aboba@hotmail.com Tue Jul 26 22:36:10 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8899A11E8074 for ; Tue, 26 Jul 2011 22:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.077 X-Spam-Level: X-Spam-Status: No, score=-102.077 tagged_above=-999 required=5 tests=[AWL=0.521, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOa3atGi4dtL for ; Tue, 26 Jul 2011 22:36:09 -0700 (PDT) Received: from blu0-omc2-s28.blu0.hotmail.com (blu0-omc2-s28.blu0.hotmail.com [65.55.111.103]) by ietfa.amsl.com (Postfix) with ESMTP id EEEF911E8072 for ; Tue, 26 Jul 2011 22:36:08 -0700 (PDT) Received: from BLU152-W47 ([65.55.111.72]) by blu0-omc2-s28.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 22:36:08 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_3344cd5b-33d0-4326-ae8a-4220bf3cbd63_" X-Originating-IP: [130.129.64.90] From: Bernard Aboba To: , Date: Tue, 26 Jul 2011 22:36:08 -0700 Importance: Normal In-Reply-To: References: <8B0A9FCBB9832F43971E38010638454F040D2C36A8@SISPE7MB1.commscope.com>, , , , <8B0A9FCBB9832F43971E38010638454F040D2C3700@SISPE7MB1.commscope.com>, MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jul 2011 05:36:08.0411 (UTC) FILETIME=[16064AB0:01CC4C1F] Cc: ecrit@ietf.org Subject: Re: [Ecrit] SWATting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 05:36:10 -0000 --_3344cd5b-33d0-4326-ae8a-4220bf3cbd63_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable While LbyR helps with time-shifting attacks=2C the 'cut and paste' attack = can still work=2C as will the IP address spoofing attack. A collaborator c= an give you a PIDF-LO reference to include in your SIP message. =20 From: bernard_aboba@hotmail.com To: martin.dawson@commscope.com=3B mlinsner@cisco.com Date: Tue=2C 26 Jul 2011 22:32:40 -0700 CC: ecrit@ietf.org Subject: Re: [Ecrit] SWATting If the PIDF-LO isn't signed=2C you can just make one up.=20 Even if it is signed=2C for IP address spoofing with HELD=2C it is possible= to obtain a PIDF-LO for another IP address if you are on the path from the= fake source address to the LIS. Possible=2C but not easy. However=2C it is not necessary to spoof an IP address to obtain a (signed) = PIDF-LO that can be (falsely) conveyed. =20 You can have someone else obtain the (signed) PIDF-LO and give it to you to= convey within SIP ('cut and paste')=2C or you can obtain a PIDF-LO=2C chan= ge your location and then convey it later (time-shifting).=20 Even if the PIDF-LO is signed=2C and SIP uses RFC 4474=2C the 'cut and past= e' attack still works=2C if the identity in the PIDF-LO is unlinkable to th= e SIP identity (e.g. From field).=20 The time-shifting attack will work as long as the PIDF-LO timestamp is with= in the window checked by the PSAP.=20 While the PSAP may not want to necessarily reject the incoming call=2C ther= e is information that can be used in determining the "swatting" potential: 1. Checking the 'timestamp' field in the PIDF-LO against the SIP timestamp = or the time at the PSAP=3B 2. Checking fields in the PIDF-LO (such as 'contact') against the identity = in the SIP From: field=3B 3. Whether the PIDF-LO is signed=3B=20 4. Checking aspects of the signing certificate (e.g. altSubjectName)=3B 5. Whether SIP uses RFC 4474=3B As was noted in the discussion=2C this is not only about 'trustworthy locat= ion' but also about accountability. =20 If attackers feel confident that they will be held accountable (many are ca= ught now=2C after all)=2C they will be less likely to attempt these attacks= . We have seen this quite often with unauthenticated/unauthorized calling=3B = move from no SIM to a registered SIM (albeit with no balance) and voila=2C= attacks decline.=20 > From: Martin.Dawson@commscope.com > To: mlinsner@cisco.com > Date: Wed=2C 27 Jul 2011 12:25:32 +0800 > CC: ecrit@ietf.org > Subject: Re: [Ecrit] SWATting >=20 > What is the method by which somebody spoofs an IP address to fool an ISP = LIS into giving them a PIDF-LO or location reference applicable to a differ= ent location? How would this be done? >=20 > Cheers=2C > Martin >=20 > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com]=20 > Sent: Wednesday=2C 27 July 2011 12:40 PM > To: Dawson=2C Martin > Cc: ecrit@ietf.org Org > Subject: Re: [Ecrit] SWATting >=20 > Martin=2C >=20 > I believe the point was that IP address spoofing coupled with a stolen ur= i > from the used IP address is location spoofing to a PSAP. >=20 > BTW=2C current PSTN location mechanisms are in fact LbyR via a recognized > operator. >=20 > -Marc- >=20 > -----Original Message----- > From: "Dawson=2C Martin" > Date: Wed=2C 27 Jul 2011 10:17:15 +0800 > To: "Richard L. Barnes" =2C Hannes Tschofenig > > Cc: "ecrit@ietf.org Org" > Subject: Re: [Ecrit] SWATting >=20 > >"... ECRIT equivalent of CLI spoofing is IP address spoofing (when the > >LIS is locating based on IP address). " > > > >That might be the equivalent of "CLI spoofing" but the real issue is > >location spoofing. In use cases that allow the terminal to deliver a > >literal PIDF-LO then the ability to spoof location is direct=3B just cra= ft > >your own PIDF-LO. This is why it's important to be able to utilize > >delivery as location-by-reference so that PSAPs can apply a different > >policy based on whether location is just provided literally or whether > >there's the opportunity to source it from a recognized operator within > >the PSAP catchment (and in the absence of any other mechanism such as > >ISP-signed PIDF-LO). > > > >Regulators wrestle with assumptions about interconnected VoIP providers > >but that's a PSTN hangover and not a basis for long term policy - > >especially relying on something as tenuous as whether such VoIP provider= s > >only hand out subscriptions to users with identity-verified credit cards= . > > > >Cheers=2C > >Martin > > > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf O= f > >Richard L. Barnes > >Sent: Wednesday=2C 27 July 2011 4:01 AM > >To: Hannes Tschofenig > >Cc: ecrit@ietf.org Org > >Subject: Re: [Ecrit] SWATting > > > >Does anyone on this list know how these attacks are accomplished? > > > >The only obvious approaches that occur to me are CLI spoofing and lying > >on a VoIP provider's registration form (coincidentally=2C the same thing= s > >that Wikipedia suggests). But in the case I mention below=2C they say t= hat > >the call was from "a non-valid number". > > > >Incidentally=2C the ECRIT equivalent of CLI spoofing is IP address spoof= ing > >(when the LIS is locating based on IP address). So it might be worth > >referring to BCP 38 somewhere. > > > >--Richard > > > > > > > >On Jul 26=2C 2011=2C at 1:44 PM=2C Hannes Tschofenig wrote: > > > >> I also say this one recently: "Xboxer SWATTED by armed cops after > >>online spat"=20 > >> http://www.theregister.co.uk/2011/06/30/xbox_swat_police_rait/ > >>=20 > >>=20 > >> On Jul 26=2C 2011=2C at 1:12 PM=2C Marc Linsner wrote: > >>=20 > >>> Or the reference Hannes uses: > >>>=20 > >>> http://www.fbi.gov/news/stories/2008/february/swatting020408 > >>>=20 > >>>=20 > >>> -Marc- > >>>=20 > >>> -----Original Message----- > >>> From: "Richard L. Barnes" > >>> Date: Tue=2C 26 Jul 2011 12:21:57 -0400 > >>> To: "ecrit@ietf.org Org" > >>> Subject: [Ecrit] SWATting > >>>=20 > >>>> I heard from some people that they had not heard the verb "to SWAT" > >>>> before the ECRIT meeting tomorrow. Today's news has a new example: > >>>>=20 > >>>> >>>>-an > >>>> d-swat-to-womans-house-20110726-1hxqm.html> > >>>>=20 > >>>> This is a vulnerability of the current system=2C but the trustworthy > >>>> location document is intended to quantify the risk of similar attack= s > >>>>in > >>>> the ECRIT environment. > >>>>=20 > >>>> --Richard > >>>> _______________________________________________ > >>>> Ecrit mailing list > >>>> Ecrit@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>=20 > >>>=20 > >>> _______________________________________________ > >>> 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 > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit >=20 >=20 > _______________________________________________ > 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 = --_3344cd5b-33d0-4326-ae8a-4220bf3cbd63_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
While LbyR helps with time-shifting attacks=2C the =3B 'cut and paste' = attack can still work=2C as will the IP address spoofing attack. =3B A = collaborator can give you a PIDF-LO reference to include in your SIP messag= e. =3B


From: bernard_aboba@hotmail= .com
To: martin.dawson@commscope.com=3B mlinsner@cisco.com
Date: Tue= =2C 26 Jul 2011 22:32:40 -0700
CC: ecrit@ietf.org
Subject: Re: [Ecrit= ] SWATting

If the PIDF-LO isn't signed=2C you can just make one up.

Even if it= is signed=2C for IP address spoofing with HELD=2C it is possible to obtain= a PIDF-LO for another IP address if you are on the path from the fake sour= ce address to the LIS. =3B =3B Possible=2C but not easy.

How= ever=2C it is not necessary to spoof an IP address to obtain a (signed) PID= F-LO that can be (falsely) conveyed. =3B

You can have someone e= lse obtain the (signed) PIDF-LO and give it to you to convey within SIP ('c= ut and paste')=2C or you can obtain a PIDF-LO=2C change your location and t= hen convey it later (time-shifting).

Even if the PIDF-LO is signed= =2C and SIP uses RFC 4474=2C the 'cut and paste' attack still works=2C if t= he identity in the PIDF-LO is unlinkable to the SIP identity (e.g. From fie= ld).

The time-shifting attack will work as long as the PIDF-LO time= stamp is within the window checked by the PSAP.

While the PSAP may = not want to necessarily reject the incoming call=2C there is information th= at can be used in determining the "swatting" potential:

1. Checking = the 'timestamp' field in the PIDF-LO against the SIP timestamp or the time = at the PSAP=3B
2. Checking fields in the PIDF-LO (such as 'contact') aga= inst the identity in the SIP From: field=3B
3. Whether the PIDF-LO is si= gned=3B
4. Checking aspects of the signing certificate (e.g. altSubject= Name)=3B
5. Whether SIP uses RFC 4474=3B

As was noted in the disc= ussion=2C this is not only about 'trustworthy location' but also about acco= untability. =3B
If attackers feel confident that they will be held = accountable (many are caught now=2C after all)=2C they will be less likely = to attempt these attacks.

We have seen this quite often with unauthe= nticated/unauthorized calling=3B =3B move from no SIM to a registered S= IM (albeit with no balance) and voila=2C attacks decline.


= >=3B From: Martin.Dawson@commscope.com
>=3B To: mlinsner@cisco.com>=3B Date: Wed=2C 27 Jul 2011 12:25:32 +0800
>=3B CC: ecrit@ietf.o= rg
>=3B Subject: Re: [Ecrit] SWATting
>=3B
>=3B What is the= method by which somebody spoofs an IP address to fool an ISP LIS into givi= ng them a PIDF-LO or location reference applicable to a different location?= How would this be done?
>=3B
>=3B Cheers=2C
>=3B Martin>=3B
>=3B -----Original Message-----
>=3B From: Marc Linsner = [mailto:mlinsner@cisco.com]
>=3B Sent: Wednesday=2C 27 July 2011 12:4= 0 PM
>=3B To: Dawson=2C Martin
>=3B Cc: ecrit@ietf.org Org
>= =3B Subject: Re: [Ecrit] SWATting
>=3B
>=3B Martin=2C
>=3B =
>=3B I believe the point was that IP address spoofing coupled with a = stolen uri
>=3B from the used IP address is location spoofing to a PSA= P.
>=3B
>=3B BTW=2C current PSTN location mechanisms are in fact= LbyR via a recognized
>=3B operator.
>=3B
>=3B -Marc-
&= gt=3B
>=3B -----Original Message-----
>=3B From: "Dawson=2C Mart= in" <=3BMartin.Dawson@commscope.com>=3B
>=3B Date: Wed=2C 27 Jul 2= 011 10:17:15 +0800
>=3B To: "Richard L. Barnes" <=3Brbarnes@bbn.com&= gt=3B=2C Hannes Tschofenig
>=3B <=3Bhannes.tschofenig@gmx.net>=3B<= br>>=3B Cc: "ecrit@ietf.org Org" <=3Becrit@ietf.org>=3B
>=3B Sub= ject: Re: [Ecrit] SWATting
>=3B
>=3B >=3B"... ECRIT equivalent= of CLI spoofing is IP address spoofing (when the
>=3B >=3BLIS is lo= cating based on IP address). "
>=3B >=3B
>=3B >=3BThat might= be the equivalent of "CLI spoofing" but the real issue is
>=3B >=3B= location spoofing. In use cases that allow the terminal to deliver a
>= =3B >=3Bliteral PIDF-LO then the ability to spoof location is direct=3B j= ust craft
>=3B >=3Byour own PIDF-LO. This is why it's important to b= e able to utilize
>=3B >=3Bdelivery as location-by-reference so that= PSAPs can apply a different
>=3B >=3Bpolicy based on whether locati= on is just provided literally or whether
>=3B >=3Bthere's the opport= unity to source it from a recognized operator within
>=3B >=3Bthe PS= AP catchment (and in the absence of any other mechanism such as
>=3B &= gt=3BISP-signed PIDF-LO).
>=3B >=3B
>=3B >=3BRegulators wrest= le with assumptions about interconnected VoIP providers
>=3B >=3Bbut= that's a PSTN hangover and not a basis for long term policy -
>=3B &g= t=3Bespecially relying on something as tenuous as whether such VoIP provide= rs
>=3B >=3Bonly hand out subscriptions to users with identity-verif= ied credit cards.
>=3B >=3B
>=3B >=3BCheers=2C
>=3B >= =3BMartin
>=3B >=3B
>=3B >=3B-----Original Message-----
&g= t=3B >=3BFrom: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf Of
>=3B >=3BRichard L. Barnes
>=3B >=3BSent: Wednesday= =2C 27 July 2011 4:01 AM
>=3B >=3BTo: Hannes Tschofenig
>=3B &g= t=3BCc: ecrit@ietf.org Org
>=3B >=3BSubject: Re: [Ecrit] SWATting>=3B >=3B
>=3B >=3BDoes anyone on this list know how these atta= cks are accomplished?
>=3B >=3B
>=3B >=3BThe only obvious app= roaches that occur to me are CLI spoofing and lying
>=3B >=3Bon a Vo= IP provider's registration form (coincidentally=2C the same things
>= =3B >=3Bthat Wikipedia suggests). But in the case I mention below=2C the= y say that
>=3B >=3Bthe call was from "a non-valid number".
>= =3B >=3B
>=3B >=3BIncidentally=2C the ECRIT equivalent of CLI spoo= fing is IP address spoofing
>=3B >=3B(when the LIS is locating based= on IP address). So it might be worth
>=3B >=3Breferring to BCP 38 = somewhere.
>=3B >=3B
>=3B >=3B--Richard
>=3B >=3B
&= gt=3B >=3B
>=3B >=3B
>=3B >=3BOn Jul 26=2C 2011=2C at 1:44 = PM=2C Hannes Tschofenig wrote:
>=3B >=3B
>=3B >=3B>=3B I al= so say this one recently: "Xboxer SWATTED by armed cops after
>=3B &g= t=3B>=3Bonline spat"
>=3B >=3B>=3B http://www.theregister.co.uk= /2011/06/30/xbox_swat_police_rait/
>=3B >=3B>=3B
>=3B >=3B= >=3B
>=3B >=3B>=3B On Jul 26=2C 2011=2C at 1:12 PM=2C Marc Lins= ner wrote:
>=3B >=3B>=3B
>=3B >=3B>=3B>=3B Or the refe= rence Hannes uses:
>=3B >=3B>=3B>=3B
>=3B >=3B>=3B>= =3B http://www.fbi.gov/news/stories/2008/february/swatting020408
>=3B = >=3B>=3B>=3B
>=3B >=3B>=3B>=3B
>=3B >=3B>=3B>= =3B -Marc-
>=3B >=3B>=3B>=3B
>=3B >=3B>=3B>=3B -----= Original Message-----
>=3B >=3B>=3B>=3B From: "Richard L. Barnes= " <=3Brbarnes@bbn.com>=3B
>=3B >=3B>=3B>=3B Date: Tue=2C 26 = Jul 2011 12:21:57 -0400
>=3B >=3B>=3B>=3B To: "ecrit@ietf.org Or= g" <=3Becrit@ietf.org>=3B
>=3B >=3B>=3B>=3B Subject: [Ecrit]= SWATting
>=3B >=3B>=3B>=3B
>=3B >=3B>=3B>=3B>=3B = I heard from some people that they had not heard the verb "to SWAT"
>= =3B >=3B>=3B>=3B>=3B before the ECRIT meeting tomorrow. Today's new= s has a new example:
>=3B >=3B>=3B>=3B>=3B
>=3B >=3B&g= t=3B>=3B>=3B<=3Bhttp://www.smh.com.au/technology/technology-news/pran= k-draws-30-police
>=3B >=3B>=3B>=3B>=3B-an
>=3B >=3B>= =3B>=3B>=3B d-swat-to-womans-house-20110726-1hxqm.html>=3B
>=3B = >=3B>=3B>=3B>=3B
>=3B >=3B>=3B>=3B>=3B This is a vuln= erability of the current system=2C but the trustworthy
>=3B >=3B>= =3B>=3B>=3B location document is intended to quantify the risk of simil= ar attacks
>=3B >=3B>=3B>=3B>=3Bin
>=3B >=3B>=3B>= =3B>=3B the ECRIT environment.
>=3B >=3B>=3B>=3B>=3B
>= =3B >=3B>=3B>=3B>=3B --Richard
>=3B >=3B>=3B>=3B>=3B _= ______________________________________________
>=3B >=3B>=3B>=3B= >=3B Ecrit mailing list
>=3B >=3B>=3B>=3B>=3B Ecrit@ietf.org=
>=3B >=3B>=3B>=3B>=3B https://www.ietf.org/mailman/listinfo/e= crit
>=3B >=3B>=3B>=3B
>=3B >=3B>=3B>=3B
>=3B = >=3B>=3B>=3B _______________________________________________
>= =3B >=3B>=3B>=3B Ecrit mailing list
>=3B >=3B>=3B>=3B Ecri= t@ietf.org
>=3B >=3B>=3B>=3B https://www.ietf.org/mailman/listin= fo/ecrit
>=3B >=3B>=3B
>=3B >=3B
>=3B >=3B_________= ______________________________________
>=3B >=3BEcrit mailing list>=3B >=3BEcrit@ietf.org
>=3B >=3Bhttps://www.ietf.org/mailman/= listinfo/ecrit
>=3B >=3B____________________________________________= ___
>=3B >=3BEcrit mailing list
>=3B >=3BEcrit@ietf.org
&g= t=3B >=3Bhttps://www.ietf.org/mailman/listinfo/ecrit
>=3B
>=3B=
>=3B _______________________________________________
>=3B Ecrit= mailing list
>=3B Ecrit@ietf.org
>=3B https://www.ietf.org/mailm= an/listinfo/ecrit

_______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit
= --_3344cd5b-33d0-4326-ae8a-4220bf3cbd63_-- From James.Winterbottom@commscope.com Tue Jul 26 22:42:26 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BADF611E8083 for ; Tue, 26 Jul 2011 22:42:26 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ggyINvKXJhv for ; Tue, 26 Jul 2011 22:42:25 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 30ED811E8072 for ; Tue, 26 Jul 2011 22:42:25 -0700 (PDT) X-AuditID: 0a0404e9-b7cc4ae00000074e-86-4e2fa549c2b8 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id 39.03.01870.945AF2E4; Wed, 27 Jul 2011 00:42:34 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.159.2; Wed, 27 Jul 2011 00:42:24 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 27 Jul 2011 13:42:20 +0800 From: "Winterbottom, James" To: Bernard Aboba , "Dawson, Martin" , "mlinsner@cisco.com" Date: Wed, 27 Jul 2011 13:42:17 +0800 Thread-Topic: [Ecrit] SWATting Thread-Index: AcxMHrKc6cZ4TFHGSoaIEJF0AYwmcwAAKRsw Message-ID: <5A55A45AE77F5941B18E5457ECAC818801210D64A208@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F040D2C36A8@SISPE7MB1.commscope.com>, , <8B0A9FCBB9832F43971E38010638454F040D2C3700@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: multipart/alternative; boundary="_000_5A55A45AE77F5941B18E5457ECAC818801210D64A208SISPE7MB1co_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] SWATting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 05:42:26 -0000 --_000_5A55A45AE77F5941B18E5457ECAC818801210D64A208SISPE7MB1co_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comments inline. ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of B= ernard Aboba Sent: Wednesday, 27 July 2011 3:33 PM To: Dawson, Martin; mlinsner@cisco.com Cc: ecrit@ietf.org Subject: Re: [Ecrit] SWATting If the PIDF-LO isn't signed, you can just make one up. Even if it is signed, for IP address spoofing with HELD, it is possible to = obtain a PIDF-LO for another IP address if you are on the path from the fak= e source address to the LIS. Possible, but not easy. However, it is not necessary to spoof an IP address to obtain a (signed) PI= DF-LO that can be (falsely) conveyed. You can have someone else obtain the (signed) PIDF-LO and give it to you to= convey within SIP ('cut and paste'), or you can obtain a PIDF-LO, change y= our location and then convey it later (time-shifting). [AJW] This is a analogous to you lending me your phone to make an fraudulen= t emergency call though. In this case they will know where you were when yo= u made the call. If you look at the draft that Martin Thomson and I wrote on location signin= g some time ago, you will see that it provides a good way to a) link to the= SIP identity if you it to, and b) stop the time shifting problem by includ= ing a timestamp over which the signature is based. Location by value need t= o be attributable to a specific device at a specific point in time. Even if the PIDF-LO is signed, and SIP uses RFC 4474, the 'cut and paste' a= ttack still works, if the identity in the PIDF-LO is unlinkable to the SIP = identity (e.g. From field). The time-shifting attack will work as long as the PIDF-LO timestamp is with= in the window checked by the PSAP. [AJW] this is true, but it does require some degree of collusion, and there= fore requires some local footprint in order to achieve it. While the PSAP may not want to necessarily reject the incoming call, there = is information that can be used in determining the "swatting" potential: 1. Checking the 'timestamp' field in the PIDF-LO against the SIP timestamp = or the time at the PSAP; 2. Checking fields in the PIDF-LO (such as 'contact') against the identity = in the SIP From: field; 3. Whether the PIDF-LO is signed; 4. Checking aspects of the signing certificate (e.g. altSubjectName); 5. Whether SIP uses RFC 4474; As was noted in the discussion, this is not only about 'trustworthy locatio= n' but also about accountability. If attackers feel confident that they will be held accountable (many are ca= ught now, after all), they will be less likely to attempt these attacks. We have seen this quite often with unauthenticated/unauthorized calling; m= ove from no SIM to a registered SIM (albeit with no balance) and voila, att= acks decline. > From: Martin.Dawson@commscope.com > To: mlinsner@cisco.com > Date: Wed, 27 Jul 2011 12:25:32 +0800 > CC: ecrit@ietf.org > Subject: Re: [Ecrit] SWATting > > What is the method by which somebody spoofs an IP address to fool an ISP = LIS into giving them a PIDF-LO or location reference applicable to a differ= ent location? How would this be done? > > Cheers, > Martin > > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Wednesday, 27 July 2011 12:40 PM > To: Dawson, Martin > Cc: ecrit@ietf.org Org > Subject: Re: [Ecrit] SWATting > > Martin, > > I believe the point was that IP address spoofing coupled with a stolen ur= i > from the used IP address is location spoofing to a PSAP. > > BTW, current PSTN location mechanisms are in fact LbyR via a recognized > operator. > > -Marc- > > -----Original Message----- > From: "Dawson, Martin" > Date: Wed, 27 Jul 2011 10:17:15 +0800 > To: "Richard L. Barnes" , Hannes Tschofenig > > Cc: "ecrit@ietf.org Org" > Subject: Re: [Ecrit] SWATting > > >"... ECRIT equivalent of CLI spoofing is IP address spoofing (when the > >LIS is locating based on IP address). " > > > >That might be the equivalent of "CLI spoofing" but the real issue is > >location spoofing. In use cases that allow the terminal to deliver a > >literal PIDF-LO then the ability to spoof location is direct; just craft > >your own PIDF-LO. This is why it's important to be able to utilize > >delivery as location-by-reference so that PSAPs can apply a different > >policy based on whether location is just provided literally or whether > >there's the opportunity to source it from a recognized operator within > >the PSAP catchment (and in the absence of any other mechanism such as > >ISP-signed PIDF-LO). > > > >Regulators wrestle with assumptions about interconnected VoIP providers > >but that's a PSTN hangover and not a basis for long term policy - > >especially relying on something as tenuous as whether such VoIP provider= s > >only hand out subscriptions to users with identity-verified credit cards= . > > > >Cheers, > >Martin > > > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf O= f > >Richard L. Barnes > >Sent: Wednesday, 27 July 2011 4:01 AM > >To: Hannes Tschofenig > >Cc: ecrit@ietf.org Org > >Subject: Re: [Ecrit] SWATting > > > >Does anyone on this list know how these attacks are accomplished? > > > >The only obvious approaches that occur to me are CLI spoofing and lying > >on a VoIP provider's registration form (coincidentally, the same things > >that Wikipedia suggests). But in the case I mention below, they say that > >the call was from "a non-valid number". > > > >Incidentally, the ECRIT equivalent of CLI spoofing is IP address spoofin= g > >(when the LIS is locating based on IP address). So it might be worth > >referring to BCP 38 somewhere. > > > >--Richard > > > > > > > >On Jul 26, 2011, at 1:44 PM, Hannes Tschofenig wrote: > > > >> I also say this one recently: "Xboxer SWATTED by armed cops after > >>online spat" > >> http://www.theregister.co.uk/2011/06/30/xbox_swat_police_rait/ > >> > >> > >> On Jul 26, 2011, at 1:12 PM, Marc Linsner wrote: > >> > >>> Or the reference Hannes uses: > >>> > >>> http://www.fbi.gov/news/stories/2008/february/swatting020408 > >>> > >>> > >>> -Marc- > >>> > >>> -----Original Message----- > >>> From: "Richard L. Barnes" > >>> Date: Tue, 26 Jul 2011 12:21:57 -0400 > >>> To: "ecrit@ietf.org Org" > >>> Subject: [Ecrit] SWATting > >>> > >>>> I heard from some people that they had not heard the verb "to SWAT" > >>>> before the ECRIT meeting tomorrow. Today's news has a new example: > >>>> > >>>> >>>>-an > >>>> d-swat-to-womans-house-20110726-1hxqm.html> > >>>> > >>>> This is a vulnerability of the current system, but the trustworthy > >>>> location document is intended to quantify the risk of similar attack= s > >>>>in > >>>> the ECRIT environment. > >>>> > >>>> --Richard > >>>> _______________________________________________ > >>>> 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 --_000_5A55A45AE77F5941B18E5457ECAC818801210D64A208SISPE7MB1co_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Comments inline.

 

 


From:= ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Wednesday, 27 July 201= 1 3:33 PM
To: Dawson, Martin; mlinsner@cisco.com
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] SWATtin= g

 

If the PIDF-LO isn't signed, = you can just make one up.

Even if it is signed, for IP address spoofing with HELD, it is possible to obtain a PIDF-LO for another IP address if you are on the path from the fak= e source address to the LIS.   Possible, but not easy.

However, it is not necessary to spoof an IP address to obtain a (signed) PIDF-LO that can be (falsely) conveyed. 

You can have someone else obtain the (signed) PIDF-LO and give it to you to convey within SIP ('cut and paste'), or you can obtain a PIDF-LO, change yo= ur location and then convey it later (time-shifting).

= [AJW] This is a analogous to you lending me your phone to make an fraudulent emergency call though. In this case they will know where you were when you = made the call.

= If you look at the draft that Martin Thomson and I wrote on location signing some = time ago, you will see that it provides a good way to a) link to the SIP identit= y if you it to, and b) stop the time shifting problem by including a timestamp o= ver which the signature is based. Location by value need to be attributable to = a specific device at a specific point in time.



Even if the PIDF-LO is signed, and SIP uses RFC 4474, the 'cut and paste' attack still works, if the identity in the PIDF-LO is unlinkable to the SIP identity (e.g. From field).

The time-shifting attack will work as long as the PIDF-LO timestamp is with= in the window checked by the PSAP.

= [AJW] this is true, but it does require some degree of collusion, and therefore requires some local footprint in order to achieve it.=

While the PSAP may not want to necessarily reject the incoming call, there = is information that can be used in determining the "swatting" potent= ial:

1. Checking the 'timestamp' field in the PIDF-LO against the SIP timestamp = or the time at the PSAP;
2. Checking fields in the PIDF-LO (such as 'contact') against the identity = in the SIP From: field;
3. Whether the PIDF-LO is signed;
4. Checking aspects of the signing certificate (e.g. altSubjectName);
5. Whether SIP uses RFC 4474;

As was noted in the discussion, this is not only about 'trustworthy locatio= n' but also about accountability. 
If attackers feel confident that they will be held accountable (many are ca= ught now, after all), they will be less likely to attempt these attacks.

We have seen this quite often with unauthenticated/unauthorized calling;&nb= sp; move from no SIM to a registered SIM (albeit with no balance) and voila, attacks decline.

> From: Martin.Dawson@commscope.com
> To: mlinsner@cisco.com
> Date: Wed, 27 Jul 2011 12:25:32 +0800
> CC: ecrit@ietf.org
> Subject: Re: [Ecrit] SWATting
>
> What is the method by which somebody spoofs an IP address to fool an I= SP LIS into giving them a PIDF-LO or location reference applicable to a differ= ent location? How would this be done?
>
> Cheers,
> Martin
>
> -----Original Message-----
> From: Marc Linsner [mailto:mlinsner@cisco.com]
> Sent: Wednesday, 27 July 2011 12:40 PM
> To: Dawson, Martin
> Cc: ecrit@ietf.org Org
> Subject: Re: [Ecrit] SWATting
>
> Martin,
>
> I believe the point was that IP address spoofing coupled with a stolen= uri
> from the used IP address is location spoofing to a PSAP.
>
> BTW, current PSTN location mechanisms are in fact LbyR via a recognize= d
> operator.
>
> -Marc-
>
> -----Original Message-----
> From: "Dawson, Martin" <Martin.Dawson@commscope.com> > Date: Wed, 27 Jul 2011 10:17:15 +0800
> To: "Richard L. Barnes" <rbarnes@bbn.com>, Hannes Tschofenig
> <hannes.tschofenig@gmx.net>
> Cc: "ecrit@ietf.org Org" <ecrit@ietf.org>
> Subject: Re: [Ecrit] SWATting
>
> >"... ECRIT equivalent of CLI spoofing is IP address spoofing (when the
> >LIS is locating based on IP address). "
> >
> >That might be the equivalent of "CLI spoofing" but the r= eal issue is
> >location spoofing. In use cases that allow the terminal to deliver= a
> >literal PIDF-LO then the ability to spoof location is direct; just craft
> >your own PIDF-LO. This is why it's important to be able to utilize=
> >delivery as location-by-reference so that PSAPs can apply a differ= ent
> >policy based on whether location is just provided literally or whe= ther
> >there's the opportunity to source it from a recognized operator wi= thin
> >the PSAP catchment (and in the absence of any other mechanism such= as
> >ISP-signed PIDF-LO).
> >
> >Regulators wrestle with assumptions about interconnected VoIP providers
> >but that's a PSTN hangover and not a basis for long term policy -<= br> > >especially relying on something as tenuous as whether such VoIP providers
> >only hand out subscriptions to users with identity-verified credit cards.
> >
> >Cheers,
> >Martin
> >
> >-----Original Message-----
> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Be= half Of
> >Richard L. Barnes
> >Sent: Wednesday, 27 July 2011 4:01 AM
> >To: Hannes Tschofenig
> >Cc: ecrit@ietf.org Org
> >Subject: Re: [Ecrit] SWATting
> >
> >Does anyone on this list know how these attacks are accomplished?<= br> > >
> >The only obvious approaches that occur to me are CLI spoofing and lying
> >on a VoIP provider's registration form (coincidentally, the same things
> >that Wikipedia suggests). But in the case I mention below, they sa= y that
> >the call was from "a non-valid number".
> >
> >Incidentally, the ECRIT equivalent of CLI spoofing is IP address spoofing
> >(when the LIS is locating based on IP address). So it might be wor= th
> >referring to BCP 38 somewhere.
> >
> >--Richard
> >
> >
> >
> >On Jul 26, 2011, at 1:44 PM, Hannes Tschofenig wrote:
> >
> >> I also say this one recently: "Xboxer SWATTED by armed c= ops after
> >>online spat"
> >> http://www.theregister.co.uk/2011/06/30/xbox_swat_police_rait= /
> >>
> >>
> >> On Jul 26, 2011, at 1:12 PM, Marc Linsner wrote:
> >>
> >>> Or the reference Hannes uses:
> >>>
> >>> http://www.fbi.gov/news/stories/2008/february/swatting020= 408
> >>>
> >>>
> >>> -Marc-
> >>>
> >>> -----Original Message-----
> >>> From: "Richard L. Barnes" <rbarnes@bbn.com&g= t;
> >>> Date: Tue, 26 Jul 2011 12:21:57 -0400
> >>> To: "ecrit@ietf.org Org" <ecrit@ietf.org>=
> >>> Subject: [Ecrit] SWATting
> >>>
> >>>> I heard from some people that they had not heard the = verb "to SWAT"
> >>>> before the ECRIT meeting tomorrow. Today's news has a= new example:
> >>>>
> >>>><http://www.smh.com.au/technology/technology-news/prank-= draws-30-police
> >>>>-an
> >>>> d-swat-to-womans-house-20110726-1hxqm.html>
> >>>>
> >>>> This is a vulnerability of the current system, but th= e trustworthy
> >>>> location document is intended to quantify the risk of similar attacks
> >>>>in
> >>>> the ECRIT environment.
> >>>>
> >>>> --Richard
> >>>> _______________________________________________
> >>>> 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

--_000_5A55A45AE77F5941B18E5457ECAC818801210D64A208SISPE7MB1co_-- From Martin.Dawson@commscope.com Tue Jul 26 22:52:26 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE8BA21F8B1E for ; Tue, 26 Jul 2011 22:52:26 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OugCPGlF0NiJ for ; Tue, 26 Jul 2011 22:52:22 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 4478D21F8680 for ; Tue, 26 Jul 2011 22:52:22 -0700 (PDT) X-AuditID: 0a0404e9-b7cc4ae00000074e-8a-4e2fa79e189f Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id 56.33.01870.E97AF2E4; Wed, 27 Jul 2011 00:52:31 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.159.2; Wed, 27 Jul 2011 00:52:19 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 27 Jul 2011 13:52:17 +0800 From: "Dawson, Martin" To: Bernard Aboba , "mlinsner@cisco.com" Date: Wed, 27 Jul 2011 13:52:16 +0800 Thread-Topic: [Ecrit] SWATting Thread-Index: AcxMHq+jvbncsRtHQMquRnqrYVBYAgAAKl+Q Message-ID: <8B0A9FCBB9832F43971E38010638454F040D2C3721@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F040D2C36A8@SISPE7MB1.commscope.com>, , <8B0A9FCBB9832F43971E38010638454F040D2C3700@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: multipart/alternative; boundary="_000_8B0A9FCBB9832F43971E38010638454F040D2C3721SISPE7MB1comm_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] SWATting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 05:52:27 -0000 --_000_8B0A9FCBB9832F43971E38010638454F040D2C3721SISPE7MB1comm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with all of this. The "just make one up" was the point I was making= about the danger of relying on basic literal PIDF-LO. The cut and paste attack you refer to, nevertheless, still relies on the at= tacker having some sort of physical presence (themselves or from a proxy) a= t the location to be spoofed. This raises the bar very many notches from ju= st being able to "make one up". As we are both saying, this sort of information has major utility when it c= omes to the PSAP being able to apply effective policy to the incoming call.= Location information would not have to be very old before it is considered= suspicious or even not acceptable. Not that we currently have a specificat= ion for signing location - unless I missed something. There was a good draf= t a number of years ago that didn't progress. Currently, to my knowledge, a= ll we have is location URI (which is a deferred way to get location assuran= ce - with much the same properties as signing anyway). I'm interested in just how easily/routinely the IP spoofing that is regular= ly referred to can actually be done. As you say, getting yourself in the pa= th between the actual location and the ISP doesn't seem like such an easy t= hing. You're right on the accountability thing. Also, going back to conventional = circuit service cellular, there is good evidence in the difference in abuse= levels related to SIMless phone use between places that have good mobile l= ocation and those that don't. Cheers, Martin From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: Wednesday, 27 July 2011 3:33 PM To: Dawson, Martin; mlinsner@cisco.com Cc: ecrit@ietf.org Subject: RE: [Ecrit] SWATting If the PIDF-LO isn't signed, you can just make one up. Even if it is signed, for IP address spoofing with HELD, it is possible to = obtain a PIDF-LO for another IP address if you are on the path from the fak= e source address to the LIS. Possible, but not easy. However, it is not necessary to spoof an IP address to obtain a (signed) PI= DF-LO that can be (falsely) conveyed. You can have someone else obtain the (signed) PIDF-LO and give it to you to= convey within SIP ('cut and paste'), or you can obtain a PIDF-LO, change y= our location and then convey it later (time-shifting). Even if the PIDF-LO is signed, and SIP uses RFC 4474, the 'cut and paste' a= ttack still works, if the identity in the PIDF-LO is unlinkable to the SIP = identity (e.g. From field). The time-shifting attack will work as long as the PIDF-LO timestamp is with= in the window checked by the PSAP. While the PSAP may not want to necessarily reject the incoming call, there = is information that can be used in determining the "swatting" potential: 1. Checking the 'timestamp' field in the PIDF-LO against the SIP timestamp = or the time at the PSAP; 2. Checking fields in the PIDF-LO (such as 'contact') against the identity = in the SIP From: field; 3. Whether the PIDF-LO is signed; 4. Checking aspects of the signing certificate (e.g. altSubjectName); 5. Whether SIP uses RFC 4474; As was noted in the discussion, this is not only about 'trustworthy locatio= n' but also about accountability. If attackers feel confident that they will be held accountable (many are ca= ught now, after all), they will be less likely to attempt these attacks. We have seen this quite often with unauthenticated/unauthorized calling; m= ove from no SIM to a registered SIM (albeit with no balance) and voila, att= acks decline. > From: Martin.Dawson@commscope.com > To: mlinsner@cisco.com > Date: Wed, 27 Jul 2011 12:25:32 +0800 > CC: ecrit@ietf.org > Subject: Re: [Ecrit] SWATting > > What is the method by which somebody spoofs an IP address to fool an ISP = LIS into giving them a PIDF-LO or location reference applicable to a differ= ent location? How would this be done? > > Cheers, > Martin > > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Wednesday, 27 July 2011 12:40 PM > To: Dawson, Martin > Cc: ecrit@ietf.org Org > Subject: Re: [Ecrit] SWATting > > Martin, > > I believe the point was that IP address spoofing coupled with a stolen ur= i > from the used IP address is location spoofing to a PSAP. > > BTW, current PSTN location mechanisms are in fact LbyR via a recognized > operator. > > -Marc- > > -----Original Message----- > From: "Dawson, Martin" > Date: Wed, 27 Jul 2011 10:17:15 +0800 > To: "Richard L. Barnes" , Hannes Tschofenig > > Cc: "ecrit@ietf.org Org" > Subject: Re: [Ecrit] SWATting > > >"... ECRIT equivalent of CLI spoofing is IP address spoofing (when the > >LIS is locating based on IP address). " > > > >That might be the equivalent of "CLI spoofing" but the real issue is > >location spoofing. In use cases that allow the terminal to deliver a > >literal PIDF-LO then the ability to spoof location is direct; just craft > >your own PIDF-LO. This is why it's important to be able to utilize > >delivery as location-by-reference so that PSAPs can apply a different > >policy based on whether location is just provided literally or whether > >there's the opportunity to source it from a recognized operator within > >the PSAP catchment (and in the absence of any other mechanism such as > >ISP-signed PIDF-LO). > > > >Regulators wrestle with assumptions about interconnected VoIP providers > >but that's a PSTN hangover and not a basis for long term policy - > >especially relying on something as tenuous as whether such VoIP provider= s > >only hand out subscriptions to users with identity-verified credit cards= . > > > >Cheers, > >Martin > > > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf O= f > >Richard L. Barnes > >Sent: Wednesday, 27 July 2011 4:01 AM > >To: Hannes Tschofenig > >Cc: ecrit@ietf.org Org > >Subject: Re: [Ecrit] SWATting > > > >Does anyone on this list know how these attacks are accomplished? > > > >The only obvious approaches that occur to me are CLI spoofing and lying > >on a VoIP provider's registration form (coincidentally, the same things > >that Wikipedia suggests). But in the case I mention below, they say that > >the call was from "a non-valid number". > > > >Incidentally, the ECRIT equivalent of CLI spoofing is IP address spoofin= g > >(when the LIS is locating based on IP address). So it might be worth > >referring to BCP 38 somewhere. > > > >--Richard > > > > > > > >On Jul 26, 2011, at 1:44 PM, Hannes Tschofenig wrote: > > > >> I also say this one recently: "Xboxer SWATTED by armed cops after > >>online spat" > >> http://www.theregister.co.uk/2011/06/30/xbox_swat_police_rait/ > >> > >> > >> On Jul 26, 2011, at 1:12 PM, Marc Linsner wrote: > >> > >>> Or the reference Hannes uses: > >>> > >>> http://www.fbi.gov/news/stories/2008/february/swatting020408 > >>> > >>> > >>> -Marc- > >>> > >>> -----Original Message----- > >>> From: "Richard L. Barnes" > >>> Date: Tue, 26 Jul 2011 12:21:57 -0400 > >>> To: "ecrit@ietf.org Org" > >>> Subject: [Ecrit] SWATting > >>> > >>>> I heard from some people that they had not heard the verb "to SWAT" > >>>> before the ECRIT meeting tomorrow. Today's news has a new example: > >>>> > >>>> >>>>-an > >>>> d-swat-to-womans-house-20110726-1hxqm.html> > >>>> > >>>> This is a vulnerability of the current system, but the trustworthy > >>>> location document is intended to quantify the risk of similar attack= s > >>>>in > >>>> the ECRIT environment. > >>>> > >>>> --Richard > >>>> _______________________________________________ > >>>> 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 --_000_8B0A9FCBB9832F43971E38010638454F040D2C3721SISPE7MB1comm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree w= ith all of this. The “just make one up” was the point I was mak= ing about the danger of relying on basic literal PIDF-LO.=

 

The cut and paste attack you refer to, nevertheless, still rel= ies on the attacker having some sort of physical presence (themselves or fr= om a proxy) at the location to be spoofed. This raises the bar very many no= tches from just being able to “make one up”.<= /p>

 

As we are both saying, this sort of information has major utili= ty when it comes to the PSAP being able to apply effective policy to the in= coming call. Location information would not have to be very old before it i= s considered suspicious or even not acceptable. Not that we currently have = a specification for signing location – unless I missed something. The= re was a good draft a number of years ago that didn’t progress. Curre= ntly, to my knowledge, all we have is location URI (which is a deferred way= to get location assurance – with much the same properties as signing= anyway).

 

I’m interested in just how ea= sily/routinely the IP spoofing that is regularly referred to can actually b= e done. As you say, getting yourself in the path between the actual locatio= n and the ISP doesn’t seem like such an easy thing.=

 

You’re right on the accountability thing. Also, going ba= ck to conventional circuit service cellular, there is good evidence in the = difference in abuse levels related to SIMless phone use between places that= have good mobile location and those that don’t.

 

Cheers,

Martin

 

From: Bernard A= boba [mailto:bernard_aboba@hotmail.com]
Sent: Wednesday, 27 July= 2011 3:33 PM
To: Dawson, Martin; mlinsner@cisco.com
Cc: ecrit@ietf.org
Subject: RE: [Ecrit] SWATting
<= /p>

 

If the PIDF-LO isn't signed, you can just ma= ke one up.

Even if it is signed, for IP address spoofing with HELD,= it is possible to obtain a PIDF-LO for another IP address if you are on th= e path from the fake source address to the LIS.   Possible, but n= ot easy.

However, it is not necessary to spoof an IP address to obta= in a (signed) PIDF-LO that can be (falsely) conveyed. 

You can= have someone else obtain the (signed) PIDF-LO and give it to you to convey= within SIP ('cut and paste'), or you can obtain a PIDF-LO, change your loc= ation and then convey it later (time-shifting).

Even if the PIDF-LO= is signed, and SIP uses RFC 4474, the 'cut and paste' attack still works, = if the identity in the PIDF-LO is unlinkable to the SIP identity (e.g. From= field).

The time-shifting attack will work as long as the PIDF-LO = timestamp is within the window checked by the PSAP.

While the PSAP = may not want to necessarily reject the incoming call, there is information = that can be used in determining the "swatting" potential:

= 1. Checking the 'timestamp' field in the PIDF-LO against the SIP timestamp = or the time at the PSAP;
2. Checking fields in the PIDF-LO (such as 'con= tact') against the identity in the SIP From: field;
3. Whether the PIDF-= LO is signed;
4. Checking aspects of the signing certificate (e.g. altS= ubjectName);
5. Whether SIP uses RFC 4474;

As was noted in the di= scussion, this is not only about 'trustworthy location' but also about acco= untability. 
If attackers feel confident that they will be held ac= countable (many are caught now, after all), they will be less likely to att= empt these attacks.

We have seen this quite often with unauthenticat= ed/unauthorized calling;  move from no SIM to a registered SIM (albeit= with no balance) and voila, attacks decline.

> From: Martin.Dawson@commscope.com
> To: mlins= ner@cisco.com
> Date: Wed, 27 Jul 2011 12:25:32 +0800
> CC: ecr= it@ietf.org
> Subject: Re: [Ecrit] SWATting
>
> What is = the method by which somebody spoofs an IP address to fool an ISP LIS into g= iving them a PIDF-LO or location reference applicable to a different locati= on? How would this be done?
>
> Cheers,
> Martin
>=
> -----Original Message-----
> From: Marc Linsner [mailto:mli= nsner@cisco.com]
> Sent: Wednesday, 27 July 2011 12:40 PM
> To= : Dawson, Martin
> Cc: ecrit@ietf.org Org
> Subject: Re: [Ecrit= ] SWATting
>
> Martin,
>
> I believe the point wa= s that IP address spoofing coupled with a stolen uri
> from the used = IP address is location spoofing to a PSAP.
>
> BTW, current PS= TN location mechanisms are in fact LbyR via a recognized
> operator.<= br>>
> -Marc-
>
> -----Original Message-----
>= From: "Dawson, Martin" <Martin.Dawson@commscope.com>
&g= t; Date: Wed, 27 Jul 2011 10:17:15 +0800
> To: "Richard L. Barne= s" <rbarnes@bbn.com>, Hannes Tschofenig
> <hannes.tscho= fenig@gmx.net>
> Cc: "ecrit@ietf.org Org" <ecrit@ietf= .org>
> Subject: Re: [Ecrit] SWATting
>
> >".= .. ECRIT equivalent of CLI spoofing is IP address spoofing (when the
>= ; >LIS is locating based on IP address). "
> >
> >= ;That might be the equivalent of "CLI spoofing" but the real issu= e is
> >location spoofing. In use cases that allow the terminal to= deliver a
> >literal PIDF-LO then the ability to spoof location i= s direct; just craft
> >your own PIDF-LO. This is why it's importa= nt to be able to utilize
> >delivery as location-by-reference so t= hat PSAPs can apply a different
> >policy based on whether locatio= n is just provided literally or whether
> >there's the opportunity= to source it from a recognized operator within
> >the PSAP catchm= ent (and in the absence of any other mechanism such as
> >ISP-sign= ed PIDF-LO).
> >
> >Regulators wrestle with assumptions a= bout interconnected VoIP providers
> >but that's a PSTN hangover a= nd not a basis for long term policy -
> >especially relying on som= ething as tenuous as whether such VoIP providers
> >only hand out = subscriptions to users with identity-verified credit cards.
> >> >Cheers,
> >Martin
> >
> >-----Original= Message-----
> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounce= s@ietf.org] On Behalf Of
> >Richard L. Barnes
> >Sent: We= dnesday, 27 July 2011 4:01 AM
> >To: Hannes Tschofenig
> >= ;Cc: ecrit@ietf.org Org
> >Subject: Re: [Ecrit] SWATting
> &= gt;
> >Does anyone on this list know how these attacks are accompl= ished?
> >
> >The only obvious approaches that occur to m= e are CLI spoofing and lying
> >on a VoIP provider's registration = form (coincidentally, the same things
> >that Wikipedia suggests).= But in the case I mention below, they say that
> >the call was fr= om "a non-valid number".
> >
> >Incidentally, t= he ECRIT equivalent of CLI spoofing is IP address spoofing
> >(whe= n the LIS is locating based on IP address). So it might be worth
> &g= t;referring to BCP 38 somewhere.
> >
> >--Richard
>= >
> >
> >
> >On Jul 26, 2011, at 1:44 PM, Ha= nnes Tschofenig wrote:
> >
> >> I also say this one re= cently: "Xboxer SWATTED by armed cops after
> >>online spa= t"
> >> http://www.theregister.co.uk/2011/06/30/xbox_swat= _police_rait/
> >>
> >>
> >> On Jul 2= 6, 2011, at 1:12 PM, Marc Linsner wrote:
> >>
> >>= > Or the reference Hannes uses:
> >>>
> >>&g= t; http://www.fbi.gov/news/stories/2008/february/swatting020408
> >= ;>>
> >>>
> >>> -Marc-
> >&g= t;>
> >>> -----Original Message-----
> >>>= ; From: "Richard L. Barnes" <rbarnes@bbn.com>
> >&= gt;> Date: Tue, 26 Jul 2011 12:21:57 -0400
> >>> To: &quo= t;ecrit@ietf.org Org" <ecrit@ietf.org>
> >>> Subj= ect: [Ecrit] SWATting
> >>>
> >>>> I hear= d from some people that they had not heard the verb "to SWAT"
= > >>>> before the ECRIT meeting tomorrow. Today's news has a= new example:
> >>>>
> >>>><http://= www.smh.com.au/technology/technology-news/prank-draws-30-police
> >= ;>>>-an
> >>>> d-swat-to-womans-house-20110726-1= hxqm.html>
> >>>>
> >>>> This is a = vulnerability of the current system, but the trustworthy
> >>&g= t;> location document is intended to quantify the risk of similar attack= s
> >>>>in
> >>>> the ECRIT environment= .
> >>>>
> >>>> --Richard
> >= >>> _______________________________________________
> >&g= t;>> Ecrit mailing list
> >>>> Ecrit@ietf.org
&g= t; >>>> https://www.ietf.org/mailman/listinfo/ecrit
> >= ;>>
> >>>
> >>> _____________________= __________________________
> >>> Ecrit mailing list
> = >>> Ecrit@ietf.org
> >>> https://www.ietf.org/mailm= an/listinfo/ecrit
> >>
> >
> >______________= _________________________________
> >Ecrit mailing list
> &g= t;Ecrit@ietf.org
> >https://www.ietf.org/mailman/listinfo/ecrit> >_______________________________________________
> >Ecrit= mailing list
> >Ecrit@ietf.org
> >https://www.ietf.org/m= ailman/listinfo/ecrit
>
>
> ___________________________= ____________________
> Ecrit mailing list
> Ecrit@ietf.org
&= gt; https://www.ietf.org/mailman/listinfo/ecrit

=
= --_000_8B0A9FCBB9832F43971E38010638454F040D2C3721SISPE7MB1comm_-- From bernard_aboba@hotmail.com Wed Jul 27 05:15:16 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5006121F8BA4 for ; Wed, 27 Jul 2011 05:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.821 X-Spam-Level: X-Spam-Status: No, score=-101.821 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6m5Cbgi7qUl for ; Wed, 27 Jul 2011 05:15:14 -0700 (PDT) Received: from blu0-omc2-s36.blu0.hotmail.com (blu0-omc2-s36.blu0.hotmail.com [65.55.111.111]) by ietfa.amsl.com (Postfix) with ESMTP id 4C26521F8BA3 for ; Wed, 27 Jul 2011 05:15:14 -0700 (PDT) Received: from BLU152-W6 ([65.55.111.71]) by blu0-omc2-s36.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Jul 2011 05:15:13 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_a0aa39b3-2472-44e6-8412-db5da8bbfd53_" X-Originating-IP: [130.129.17.34] From: Bernard Aboba To: , Date: Wed, 27 Jul 2011 05:15:13 -0700 Importance: Normal In-Reply-To: <8B0A9FCBB9832F43971E38010638454F040D2C3721@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F040D2C36A8@SISPE7MB1.commscope.com>, , <8B0A9FCBB9832F43971E38010638454F040D2C3700@SISPE7MB1.commscope.com>, , <8B0A9FCBB9832F43971E38010638454F040D2C3721@SISPE7MB1.commscope.com> MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jul 2011 12:15:13.0999 (UTC) FILETIME=[D6B50DF0:01CC4C56] Cc: ecrit@ietf.org Subject: Re: [Ecrit] SWATting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 12:15:16 -0000 --_a0aa39b3-2472-44e6-8412-db5da8bbfd53_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Based on this thread=2C Hannes and I can formulate some text for review by = the WG. =20 From: Martin.Dawson@commscope.com To: bernard_aboba@hotmail.com=3B mlinsner@cisco.com CC: ecrit@ietf.org Date: Wed=2C 27 Jul 2011 13:52:16 +0800 Subject: RE: [Ecrit] SWATting I agree with all of this. The =93just make one up=94 was the point I was ma= king about the danger of relying on basic literal PIDF-LO. The cut and past= e attack you refer to=2C nevertheless=2C still relies on the attacker havin= g some sort of physical presence (themselves or from a proxy) at the locati= on to be spoofed. This raises the bar very many notches from just being abl= e to =93make one up=94. As we are both saying=2C this sort of information h= as major utility when it comes to the PSAP being able to apply effective po= licy to the incoming call. Location information would not have to be very o= ld before it is considered suspicious or even not acceptable. Not that we c= urrently have a specification for signing location =96 unless I missed some= thing. There was a good draft a number of years ago that didn=92t progress.= Currently=2C to my knowledge=2C all we have is location URI (which is a de= ferred way to get location assurance =96 with much the same properties as s= igning anyway). I=92m interested in just how easily/routinely the IP spoofi= ng that is regularly referred to can actually be done. As you say=2C gettin= g yourself in the path between the actual location and the ISP doesn=92t se= em like such an easy thing. You=92re right on the accountability thing. Als= o=2C going back to conventional circuit service cellular=2C there is good e= vidence in the difference in abuse levels related to SIMless phone use betw= een places that have good mobile location and those that don=92t. Cheers=2C= Martin From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: Wednesday=2C 27 July 2011 3:33 PM To: Dawson=2C Martin=3B mlinsner@cisco.com Cc: ecrit@ietf.org Subject: RE: [Ecrit] SWATting If the PIDF-LO isn't signed=2C you can just m= ake one up.=20 Even if it is signed=2C for IP address spoofing with HELD=2C it is possible= to obtain a PIDF-LO for another IP address if you are on the path from the= fake source address to the LIS. Possible=2C but not easy. However=2C it is not necessary to spoof an IP address to obtain a (signed) = PIDF-LO that can be (falsely) conveyed. =20 You can have someone else obtain the (signed) PIDF-LO and give it to you to= convey within SIP ('cut and paste')=2C or you can obtain a PIDF-LO=2C chan= ge your location and then convey it later (time-shifting).=20 Even if the PIDF-LO is signed=2C and SIP uses RFC 4474=2C the 'cut and past= e' attack still works=2C if the identity in the PIDF-LO is unlinkable to th= e SIP identity (e.g. From field).=20 The time-shifting attack will work as long as the PIDF-LO timestamp is with= in the window checked by the PSAP.=20 While the PSAP may not want to necessarily reject the incoming call=2C ther= e is information that can be used in determining the "swatting" potential: 1. Checking the 'timestamp' field in the PIDF-LO against the SIP timestamp = or the time at the PSAP=3B 2. Checking fields in the PIDF-LO (such as 'contact') against the identity = in the SIP From: field=3B 3. Whether the PIDF-LO is signed=3B=20 4. Checking aspects of the signing certificate (e.g. altSubjectName)=3B 5. Whether SIP uses RFC 4474=3B As was noted in the discussion=2C this is not only about 'trustworthy locat= ion' but also about accountability. =20 If attackers feel confident that they will be held accountable (many are ca= ught now=2C after all)=2C they will be less likely to attempt these attacks= . We have seen this quite often with unauthenticated/unauthorized calling=3B = move from no SIM to a registered SIM (albeit with no balance) and voila=2C= attacks decline.=20 > From: Martin.Dawson@commscope.com > To: mlinsner@cisco.com > Date: Wed=2C 27 Jul 2011 12:25:32 +0800 > CC: ecrit@ietf.org > Subject: Re: [Ecrit] SWATting >=20 > What is the method by which somebody spoofs an IP address to fool an ISP = LIS into giving them a PIDF-LO or location reference applicable to a differ= ent location? How would this be done? >=20 > Cheers=2C > Martin >=20 > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com]=20 > Sent: Wednesday=2C 27 July 2011 12:40 PM > To: Dawson=2C Martin > Cc: ecrit@ietf.org Org > Subject: Re: [Ecrit] SWATting >=20 > Martin=2C >=20 > I believe the point was that IP address spoofing coupled with a stolen ur= i > from the used IP address is location spoofing to a PSAP. >=20 > BTW=2C current PSTN location mechanisms are in fact LbyR via a recognized > operator. >=20 > -Marc- >=20 > -----Original Message----- > From: "Dawson=2C Martin" > Date: Wed=2C 27 Jul 2011 10:17:15 +0800 > To: "Richard L. Barnes" =2C Hannes Tschofenig > > Cc: "ecrit@ietf.org Org" > Subject: Re: [Ecrit] SWATting >=20 > >"... ECRIT equivalent of CLI spoofing is IP address spoofing (when the > >LIS is locating based on IP address). " > > > >That might be the equivalent of "CLI spoofing" but the real issue is > >location spoofing. In use cases that allow the terminal to deliver a > >literal PIDF-LO then the ability to spoof location is direct=3B just cra= ft > >your own PIDF-LO. This is why it's important to be able to utilize > >delivery as location-by-reference so that PSAPs can apply a different > >policy based on whether location is just provided literally or whether > >there's the opportunity to source it from a recognized operator within > >the PSAP catchment (and in the absence of any other mechanism such as > >ISP-signed PIDF-LO). > > > >Regulators wrestle with assumptions about interconnected VoIP providers > >but that's a PSTN hangover and not a basis for long term policy - > >especially relying on something as tenuous as whether such VoIP provider= s > >only hand out subscriptions to users with identity-verified credit cards= . > > > >Cheers=2C > >Martin > > > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf O= f > >Richard L. Barnes > >Sent: Wednesday=2C 27 July 2011 4:01 AM > >To: Hannes Tschofenig > >Cc: ecrit@ietf.org Org > >Subject: Re: [Ecrit] SWATting > > > >Does anyone on this list know how these attacks are accomplished? > > > >The only obvious approaches that occur to me are CLI spoofing and lying > >on a VoIP provider's registration form (coincidentally=2C the same thing= s > >that Wikipedia suggests). But in the case I mention below=2C they say th= at > >the call was from "a non-valid number". > > > >Incidentally=2C the ECRIT equivalent of CLI spoofing is IP address spoof= ing > >(when the LIS is locating based on IP address). So it might be worth > >referring to BCP 38 somewhere. > > > >--Richard > > > > > > > >On Jul 26=2C 2011=2C at 1:44 PM=2C Hannes Tschofenig wrote: > > > >> I also say this one recently: "Xboxer SWATTED by armed cops after > >>online spat"=20 > >> http://www.theregister.co.uk/2011/06/30/xbox_swat_police_rait/ > >>=20 > >>=20 > >> On Jul 26=2C 2011=2C at 1:12 PM=2C Marc Linsner wrote: > >>=20 > >>> Or the reference Hannes uses: > >>>=20 > >>> http://www.fbi.gov/news/stories/2008/february/swatting020408 > >>>=20 > >>>=20 > >>> -Marc- > >>>=20 > >>> -----Original Message----- > >>> From: "Richard L. Barnes" > >>> Date: Tue=2C 26 Jul 2011 12:21:57 -0400 > >>> To: "ecrit@ietf.org Org" > >>> Subject: [Ecrit] SWATting > >>>=20 > >>>> I heard from some people that they had not heard the verb "to SWAT" > >>>> before the ECRIT meeting tomorrow. Today's news has a new example: > >>>>=20 > >>>> >>>>-an > >>>> d-swat-to-womans-house-20110726-1hxqm.html> > >>>>=20 > >>>> This is a vulnerability of the current system=2C but the trustworthy > >>>> location document is intended to quantify the risk of similar attack= s > >>>>in > >>>> the ECRIT environment. > >>>>=20 > >>>> --Richard > >>>> _______________________________________________ > >>>> Ecrit mailing list > >>>> Ecrit@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>=20 > >>>=20 > >>> _______________________________________________ > >>> 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 > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit = --_a0aa39b3-2472-44e6-8412-db5da8bbfd53_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Based on this thread=2C Hannes and I can formulate some text for review by = the WG. =3B


From: Martin.Dawson@co= mmscope.com
To: bernard_aboba@hotmail.com=3B mlinsner@cisco.com
CC: e= crit@ietf.org
Date: Wed=2C 27 Jul 2011 13:52:16 +0800
Subject: RE: [E= crit] SWATting

I agree with all of this. The =93just make one up=94 was the point I was= making about the danger of relying on basic literal PIDF-LO.

 =3B

The cut and paste attack you refer to=2C nevertheless=2C= still relies on the attacker having some sort of physical presence (themse= lves or from a proxy) at the location to be spoofed. This raises the bar ve= ry many notches from just being able to =93make one up=94.

 =3B

As we are both saying=2C this sort of information has maj= or utility when it comes to the PSAP being able to apply effective policy t= o the incoming call. Location information would not have to be very old bef= ore it is considered suspicious or even not acceptable. Not that we current= ly have a specification for signing location =96 unless I missed something.= There was a good draft a number of years ago that didn=92t progress. Curre= ntly=2C to my knowledge=2C all we have is location URI (which is a deferred= way to get location assurance =96 with much the same properties as signing= anyway).

 =3B<= /p>

I=92m interested in just how easi= ly/routinely the IP spoofing that is regularly referred to can actually be = done. As you say=2C getting yourself in the path between the actual locatio= n and the ISP doesn=92t seem like such an easy thing.

 =3B

You=92re right on the accountability thing. Also=2C going back t= o conventional circuit service cellular=2C there is good evidence in the di= fference in abuse levels related to SIMless phone use between places that h= ave good mobile location and those that don=92t.

 =3B

Cheers=2C

Martin

 =3B

From:= Bernard Aboba [mailto:bernard_aboba@hotmail.com]
Sent: Wednesda= y=2C 27 July 2011 3:33 PM
To: Dawson=2C Martin=3B mlinsner@cisco.= com
Cc: ecrit@ietf.org
Subject: RE: [Ecrit] SWATting

 =3B

If the PIDF-LO isn't signed=2C you= can just make one up.

Even if it is signed=2C for IP address spoof= ing with HELD=2C it is possible to obtain a PIDF-LO for another IP address = if you are on the path from the fake source address to the LIS. =3B&nbs= p=3B Possible=2C but not easy.

However=2C it is not necessary to spo= of an IP address to obtain a (signed) PIDF-LO that can be (falsely) conveye= d. =3B

You can have someone else obtain the (signed) PIDF-LO an= d give it to you to convey within SIP ('cut and paste')=2C or you can obtai= n a PIDF-LO=2C change your location and then convey it later (time-shifting= ).

Even if the PIDF-LO is signed=2C and SIP uses RFC 4474=2C the 'c= ut and paste' attack still works=2C if the identity in the PIDF-LO is unlin= kable to the SIP identity (e.g. From field).

The time-shifting atta= ck will work as long as the PIDF-LO timestamp is within the window checked = by the PSAP.

While the PSAP may not want to necessarily reject the = incoming call=2C there is information that can be used in determining the "= swatting" potential:

1. Checking the 'timestamp' field in the PIDF-L= O against the SIP timestamp or the time at the PSAP=3B
2. Checking field= s in the PIDF-LO (such as 'contact') against the identity in the SIP From: = field=3B
3. Whether the PIDF-LO is signed=3B
4. Checking aspects of = the signing certificate (e.g. altSubjectName)=3B
5. Whether SIP uses RFC= 4474=3B

As was noted in the discussion=2C this is not only about 't= rustworthy location' but also about accountability. =3B
If attacker= s feel confident that they will be held accountable (many are caught now=2C= after all)=2C they will be less likely to attempt these attacks.

We= have seen this quite often with unauthenticated/unauthorized calling=3B&nb= sp=3B move from no SIM to a registered SIM (albeit with no balance) and voi= la=2C attacks decline.

>=3B= From: Martin.Dawson@commscope.com
>=3B To: mlinsner@cisco.com
>= =3B Date: Wed=2C 27 Jul 2011 12:25:32 +0800
>=3B CC: ecrit@ietf.org>=3B Subject: Re: [Ecrit] SWATting
>=3B
>=3B What is the meth= od by which somebody spoofs an IP address to fool an ISP LIS into giving th= em a PIDF-LO or location reference applicable to a different location? How = would this be done?
>=3B
>=3B Cheers=2C
>=3B Martin
>= =3B
>=3B -----Original Message-----
>=3B From: Marc Linsner [mai= lto:mlinsner@cisco.com]
>=3B Sent: Wednesday=2C 27 July 2011 12:40 PM=
>=3B To: Dawson=2C Martin
>=3B Cc: ecrit@ietf.org Org
>=3B = Subject: Re: [Ecrit] SWATting
>=3B
>=3B Martin=2C
>=3B
= >=3B I believe the point was that IP address spoofing coupled with a stol= en uri
>=3B from the used IP address is location spoofing to a PSAP.>=3B
>=3B BTW=2C current PSTN location mechanisms are in fact Lby= R via a recognized
>=3B operator.
>=3B
>=3B -Marc-
>= =3B
>=3B -----Original Message-----
>=3B From: "Dawson=2C Martin= " <=3BMartin.Dawson@commscope.com>=3B
>=3B Date: Wed=2C 27 Jul 201= 1 10:17:15 +0800
>=3B To: "Richard L. Barnes" <=3Brbarnes@bbn.com>= =3B=2C Hannes Tschofenig
>=3B <=3Bhannes.tschofenig@gmx.net>=3B>=3B Cc: "ecrit@ietf.org Org" <=3Becrit@ietf.org>=3B
>=3B Subje= ct: Re: [Ecrit] SWATting
>=3B
>=3B >=3B"... ECRIT equivalent o= f CLI spoofing is IP address spoofing (when the
>=3B >=3BLIS is loca= ting based on IP address). "
>=3B >=3B
>=3B >=3BThat might be= the equivalent of "CLI spoofing" but the real issue is
>=3B >=3Bloc= ation spoofing. In use cases that allow the terminal to deliver a
>=3B= >=3Bliteral PIDF-LO then the ability to spoof location is direct=3B just= craft
>=3B >=3Byour own PIDF-LO. This is why it's important to be a= ble to utilize
>=3B >=3Bdelivery as location-by-reference so that PS= APs can apply a different
>=3B >=3Bpolicy based on whether location = is just provided literally or whether
>=3B >=3Bthere's the opportuni= ty to source it from a recognized operator within
>=3B >=3Bthe PSAP = catchment (and in the absence of any other mechanism such as
>=3B >= =3BISP-signed PIDF-LO).
>=3B >=3B
>=3B >=3BRegulators wrestle= with assumptions about interconnected VoIP providers
>=3B >=3Bbut t= hat's a PSTN hangover and not a basis for long term policy -
>=3B >= =3Bespecially relying on something as tenuous as whether such VoIP provider= s
>=3B >=3Bonly hand out subscriptions to users with identity-verifi= ed credit cards.
>=3B >=3B
>=3B >=3BCheers=2C
>=3B >= =3BMartin
>=3B >=3B
>=3B >=3B-----Original Message-----
&g= t=3B >=3BFrom: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf Of
>=3B >=3BRichard L. Barnes
>=3B >=3BSent: Wednesday= =2C 27 July 2011 4:01 AM
>=3B >=3BTo: Hannes Tschofenig
>=3B &g= t=3BCc: ecrit@ietf.org Org
>=3B >=3BSubject: Re: [Ecrit] SWATting>=3B >=3B
>=3B >=3BDoes anyone on this list know how these atta= cks are accomplished?
>=3B >=3B
>=3B >=3BThe only obvious app= roaches that occur to me are CLI spoofing and lying
>=3B >=3Bon a Vo= IP provider's registration form (coincidentally=2C the same things
>= =3B >=3Bthat Wikipedia suggests). But in the case I mention below=2C they= say that
>=3B >=3Bthe call was from "a non-valid number".
>=3B= >=3B
>=3B >=3BIncidentally=2C the ECRIT equivalent of CLI spoofin= g is IP address spoofing
>=3B >=3B(when the LIS is locating based on= IP address). So it might be worth
>=3B >=3Breferring to BCP 38 some= where.
>=3B >=3B
>=3B >=3B--Richard
>=3B >=3B
>= =3B >=3B
>=3B >=3B
>=3B >=3BOn Jul 26=2C 2011=2C at 1:44 PM= =2C Hannes Tschofenig wrote:
>=3B >=3B
>=3B >=3B>=3B I also= say this one recently: "Xboxer SWATTED by armed cops after
>=3B >= =3B>=3Bonline spat"
>=3B >=3B>=3B http://www.theregister.co.uk/= 2011/06/30/xbox_swat_police_rait/
>=3B >=3B>=3B
>=3B >=3B&= gt=3B
>=3B >=3B>=3B On Jul 26=2C 2011=2C at 1:12 PM=2C Marc Linsn= er wrote:
>=3B >=3B>=3B
>=3B >=3B>=3B>=3B Or the refer= ence Hannes uses:
>=3B >=3B>=3B>=3B
>=3B >=3B>=3B>= =3B http://www.fbi.gov/news/stories/2008/february/swatting020408
>=3B = >=3B>=3B>=3B
>=3B >=3B>=3B>=3B
>=3B >=3B>=3B>= =3B -Marc-
>=3B >=3B>=3B>=3B
>=3B >=3B>=3B>=3B -----= Original Message-----
>=3B >=3B>=3B>=3B From: "Richard L. Barnes= " <=3Brbarnes@bbn.com>=3B
>=3B >=3B>=3B>=3B Date: Tue=2C 26 = Jul 2011 12:21:57 -0400
>=3B >=3B>=3B>=3B To: "ecrit@ietf.org Or= g" <=3Becrit@ietf.org>=3B
>=3B >=3B>=3B>=3B Subject: [Ecrit]= SWATting
>=3B >=3B>=3B>=3B
>=3B >=3B>=3B>=3B>=3B = I heard from some people that they had not heard the verb "to SWAT"
>= =3B >=3B>=3B>=3B>=3B before the ECRIT meeting tomorrow. Today's new= s has a new example:
>=3B >=3B>=3B>=3B>=3B
>=3B >=3B&g= t=3B>=3B>=3B<=3Bhttp://www.smh.com.au/technology/technology-news/pran= k-draws-30-police
>=3B >=3B>=3B>=3B>=3B-an
>=3B >=3B>= =3B>=3B>=3B d-swat-to-womans-house-20110726-1hxqm.html>=3B
>=3B = >=3B>=3B>=3B>=3B
>=3B >=3B>=3B>=3B>=3B This is a vuln= erability of the current system=2C but the trustworthy
>=3B >=3B>= =3B>=3B>=3B location document is intended to quantify the risk of simil= ar attacks
>=3B >=3B>=3B>=3B>=3Bin
>=3B >=3B>=3B>= =3B>=3B the ECRIT environment.
>=3B >=3B>=3B>=3B>=3B
>= =3B >=3B>=3B>=3B>=3B --Richard
>=3B >=3B>=3B>=3B>=3B _= ______________________________________________
>=3B >=3B>=3B>=3B= >=3B Ecrit mailing list
>=3B >=3B>=3B>=3B>=3B Ecrit@ietf.org=
>=3B >=3B>=3B>=3B>=3B https://www.ietf.org/mailman/listinfo/e= crit
>=3B >=3B>=3B>=3B
>=3B >=3B>=3B>=3B
>=3B = >=3B>=3B>=3B _______________________________________________
>= =3B >=3B>=3B>=3B Ecrit mailing list
>=3B >=3B>=3B>=3B Ecri= t@ietf.org
>=3B >=3B>=3B>=3B https://www.ietf.org/mailman/listin= fo/ecrit
>=3B >=3B>=3B
>=3B >=3B
>=3B >=3B_________= ______________________________________
>=3B >=3BEcrit mailing list>=3B >=3BEcrit@ietf.org
>=3B >=3Bhttps://www.ietf.org/mailman/= listinfo/ecrit
>=3B >=3B____________________________________________= ___
>=3B >=3BEcrit mailing list
>=3B >=3BEcrit@ietf.org
&g= t=3B >=3Bhttps://www.ietf.org/mailman/listinfo/ecrit
>=3B
>=3B=
>=3B _______________________________________________
>=3B Ecrit= mailing list
>=3B Ecrit@ietf.org
>=3B https://www.ietf.org/mailm= an/listinfo/ecrit

= --_a0aa39b3-2472-44e6-8412-db5da8bbfd53_-- From bernard_aboba@hotmail.com Wed Jul 27 05:39:31 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEA621F8A64 for ; Wed, 27 Jul 2011 05:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.134 X-Spam-Level: X-Spam-Status: No, score=-102.134 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWKu73giT9Pi for ; Wed, 27 Jul 2011 05:39:30 -0700 (PDT) Received: from blu0-omc3-s34.blu0.hotmail.com (blu0-omc3-s34.blu0.hotmail.com [65.55.116.109]) by ietfa.amsl.com (Postfix) with ESMTP id 74C1421F8A62 for ; Wed, 27 Jul 2011 05:39:30 -0700 (PDT) Received: from BLU152-W62 ([65.55.116.73]) by blu0-omc3-s34.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Jul 2011 05:39:30 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_735d8f08-2fef-4b32-b244-7adcc66948c6_" X-Originating-IP: [130.129.17.34] From: Bernard Aboba To: Date: Wed, 27 Jul 2011 05:39:29 -0700 Importance: Normal In-Reply-To: <8B0A9FCBB9832F43971E38010638454F040D2C3721@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F040D2C36A8@SISPE7MB1.commscope.com>, , <8B0A9FCBB9832F43971E38010638454F040D2C3700@SISPE7MB1.commscope.com>, , <8B0A9FCBB9832F43971E38010638454F040D2C3721@SISPE7MB1.commscope.com> MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jul 2011 12:39:30.0061 (UTC) FILETIME=[3A967BD0:01CC4C5A] Subject: Re: [Ecrit] SWATting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 12:39:31 -0000 --_735d8f08-2fef-4b32-b244-7adcc66948c6_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [BA]You can have someone else obtain the (signed) PIDF-LO and give it to you to convey within SIP ('cut and paste')=2C or you can obtain a PIDF-LO=2C=20 change your location and then convey it later (time-shifting). [AJW] This is a analogous to you lending me your phone to make an fraudulen= t emergency call though. In this case they will know where you were when you made the c= all. If you look at the draft that Martin Thomson and I wrote on location=20 signing some time ago=2C you will see that it provides a good way to a) link to the SIP=20 identity if you it to=2C and b) stop the time shifting problem by=20 including a timestamp over which the signature is based. Location by=20 value need to be attributable to a specific device at a specific point in time. [BA]Linking to a specific device isn't enough to stop cut and paste attacks= -- you need linkability between the PIDF-LO and the SIP Identity (e.g. 'co= ntact'). A device identity doesn't necessarily provide this. Multiple types of deception fit under the rubric of "swatting". There is t= he enclosure of an invented=2C time-shifted or contact-shifted PIDF-LO in a= SIP message from an authentic identity. Then there is a forged SIP messag= e which might contain a bogus or genuine PIDF-LO. Then there are bogus cla= ims (e.g. fire! fire!) transmitted via various media (voice=2C text=2C vide= o=2C etc.)=2C which could involve authentic/non-authentic SIP identities + = bogus/genuine PIDF-LOs=2C etc. [BA]Even if the PIDF-LO is signed=2C and SIP uses RFC 4474=2C the 'cut and= =20 paste' attack still works=2C if the identity in the PIDF-LO is unlinkable=20 to the SIP identity (e.g. From field).=20 The time-shifting attack will work as long as the PIDF-LO timestamp is with= in the window checked by the PSAP. [AJW] this is true=2C but it does require some degree of collusion=2C and t= herefore requires some local footprint in order to achieve it. [BA] This attack may or may not involve collusion between individuals=3B th= e main characteristic is that it provides evidence of where someone was at = one point in the past=2C not where the caller is at the time of the emergen= cy call. For example=2C when travelling at 60 mph=2C 10 minutes of elapsed= time can put you 10 miles from the transmitted location.=20 = --_735d8f08-2fef-4b32-b244-7adcc66948c6_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
[BA]You can have someone else obtain the (signed) PIDF-LO and give it to you to convey within SIP ('cut and paste')=2C or you can obtain a PIDF-LO=2C=20 change your location and then convey it later (time-shifting).

[AJW] This is a analogous to you lending me your phone to = make an fraudulent emergency call though. In this case they will know where you were when you made the c= all.
If you look at the draft that Martin Thomson and I wrote on location=20 signing some time ago=2C you will see that it provides a good way to a) link to the SIP=20 identity if you it to=2C and b) stop the time shifting problem by=20 including a timestamp over which the signature is based. Location by=20 value need to be attributable to a specific device at a specific point in time.

[BA]Linking to a specific device isn't enoug= h to stop cut and paste attacks -- you need linkability between the PIDF-LO= and the SIP Identity (e.g. 'contact'). =3B A device identity doesn't n= ecessarily provide this.

Multiple types of deception fit under the r= ubric of "swatting". =3B There is the enclosure of an invented=2C time-= shifted or contact-shifted PIDF-LO in a SIP message from an authentic ident= ity. =3B Then there is a forged SIP message which might contain a bogus= or genuine PIDF-LO. =3B Then there are bogus claims (e.g. fire! fire!)= transmitted via various media (voice=2C text=2C video=2C etc.)=2C which co= uld involve authentic/non-authentic SIP identities + bogus/genuine PIDF-LOs= =2C etc.



[BA]<= font face=3D"Tahoma" size=3D"2">Even if the = PIDF-LO is signed=2C and SIP uses RFC 4474=2C the 'cut and=20 paste' attack still works=2C if the identity in the PIDF-LO is unlinkable=20 to the SIP identity (e.g. From field).

The time-shifting attack will work as long as the PIDF-LO timestamp is with= in the window checked by the PSAP.
[AJW] this is true=2C but it does require some degree of c= ollusion=2C and therefore requires some local footprint in order to achieve it.

[BA] This attack may or may not in= volve collusion between individuals=3B the main characteristic is that it p= rovides evidence of where someone was at one point in the past=2C not where= the caller is at the time of the emergency call. =3B For example=2C wh= en travelling at 60 mph=2C 10 minutes of elapsed time can put you 10 miles = from the transmitted location.

= --_735d8f08-2fef-4b32-b244-7adcc66948c6_-- From trac+ecrit@trac.tools.ietf.org Wed Jul 27 06:24:46 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A7D11E807A for ; Wed, 27 Jul 2011 06:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ai27y7YMo+i for ; Wed, 27 Jul 2011 06:24:45 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 456AB11E808D for ; Wed, 27 Jul 2011 06:24:45 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1Qm46C-0002Zi-F7; Wed, 27 Jul 2011 06:24:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "ecrit issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: draft-ietf-ecrit-trustworthy-location@tools.ietf.org, Bernard_Aboba@hotmail.com X-Trac-Project: ecrit Date: Wed, 27 Jul 2011 13:24:32 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ecrit/trac/ticket/8 Message-ID: <065.165eff18457d51bb8c98009f8bce2353@trac.tools.ietf.org> X-Trac-Ticket-ID: 8 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-ecrit-trustworthy-location@tools.ietf.org, Bernard_Aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20110727132445.456AB11E808D@ietfa.amsl.com> Resent-Date: Wed, 27 Jul 2011 06:24:45 -0700 (PDT) Resent-From: trac+ecrit@trac.tools.ietf.org Cc: ecrit@ietf.org Subject: [Ecrit] [ecrit] #8: Solutions X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 13:24:46 -0000 #8: Solutions The draft currently does not make recommendations. It should. Find below some suggestions fro list discussion. Martin said: The cut and paste attack you refer to, nevertheless, still relies on the attacker having some sort of physical presence (themselves or from a proxy) at the location to be spoofed. This raises the bar very many notches from just being able to “make one up”. As we are both saying, this sort of information has major utility when it comes to the PSAP being able to apply effective policy to the incoming call. Location information would not have to be very old before it is considered suspicious or even not acceptable. Not that we currently have a specification for signing location – unless I missed something. There was a good draft a number of years ago that didn’t progress. Currently, to my knowledge, all we have is location URI (which is a deferred way to get l ocation assurance – with much the same properties as signing anyway). I’m interested in just how easily/routinely the IP spoofing that is regularly referred to can actually be done. As you say, getting yourself in the path between the actual location and the ISP doesn’t seem like such an easy thing. You’re right on the accountability thing. Also, going back to conventional circuit service cellular, there is good evidence in the difference in abuse levels related to SIMless phone use between places that have good mobile location and those that don’t. Bernard said: If the PIDF-LO isn't signed, you can just make one up. Even if it is signed, for IP address spoofing with HELD, it is possible to obtain a PIDF-LO for another IP address if you are on the path from the fake source address to the LIS. Possible, but not easy. However, it is not necessary to spoof an IP address to obtain a (signed) PIDF-LO that can be (falsely) conveyed. You can have someone else obtain the (signed) PIDF-LO and give it to you to convey within SIP ('cut and paste'), or you can obtain a PIDF-LO, change your location and then convey it later (time-shifting). Even if the PIDF-LO is signed, and SIP uses RFC 4474, the 'cut and paste' attack still works, if the identity in the PIDF-LO is unlinkable to the SIP identity (e.g. From field). The time-shifting attack will work as long as the PIDF-LO timestamp is within the window checked by the PSAP. While the PSAP may not want to necessarily reject the incoming call, there is information that can be used in determining the "swatting" potential: 1. Checking the 'timestamp' field in the PIDF-LO against the SIP timestamp or the time at the PSAP; 2. Checking fields in the PIDF-LO (such as 'contact') against the identity in the SIP From: field; 3. Whether the PIDF-LO is signed; 4. Checking aspects of the signing certificate (e.g. altSubjectName); 5. Whether SIP uses RFC 4474; As was noted in the discussion, this is not only about 'trustworthy location' but also about accountability. If attackers feel confident that they will be held accountable (many are caught now, after all), they will be less likely to attempt these attacks. We have seen this quite often with unauthenticated/unauthorized calling; move from no SIM to a registered SIM (albeit with no balance) and voila, attacks decline. Marc aid: I believe the point was that IP address spoofing coupled with a stolen uri from the used IP address is location spoofing to a PSAP. BTW, current PSTN location mechanisms are in fact LbyR via a recognized operator. Martin said: Regulators wrestle with assumptions about interconnected VoIP providers but that's a PSTN hangover and not a basis for long term policy - especially relying on something as tenuous as whether such VoIP providers only hand out subscriptions to users with identity-verified credit cards. John Lange said: You would just sign up for, or hack into a VOIP service which allows you to set your own outbound caller ID. Or possible a corporate VOIP server that is vulnerable. Then, just to be on the safe side, use whatever method you can to hide your IP address when placing the call, such as a Wifi hotspot or similar. Hiding your IP address is probably optional because I've not seen much interest on the part of the Telco's to track down calls from "fake" numbers despite the rampant fraud and nuisance they regularly cause. Richard said: The only obvious approaches that occur to me are CLI spoofing and lying on a VoIP provider's registration form (coincidentally, the same things that Wikipedia suggests). But in the case I mention below, they say that the call was from "a non-valid number". The ECRIT equivalent of CLI spoofing is IP address spoofing when the LIS is locating based on IP address). So it might be worth referring to BCP 38 somewhere. http://www.seattlepi.com/default/article/Teen-who-hacked-California-911 -system-pleads-1268326.php http://www.heraldnet.com/article/20071016/NEWS01/71016015 http://www.theregister.co.uk/2011/06/30/xbox_swat_police_rait/ http://www.fbi.gov/news/stories/2008/february/swatting020408 http://www.smh.com.au/technology/technology-news/prank-draws-30-police- and-swat-to-womans-house-20110726-1hxqm.html -- ---------------------------------------+------------------------------------ Reporter: Bernard_Aboba@… | Owner: draft-ietf-ecrit-trustworthy-location@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: trustworthy-location | Version: 2.0 Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: ecrit From Hannes.Tschofenig@gmx.net Wed Jul 27 09:13:06 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D5911E808E for ; Wed, 27 Jul 2011 09:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oFc2h4OqziO for ; Wed, 27 Jul 2011 09:13:05 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id CDCE211E807E for ; Wed, 27 Jul 2011 09:13:04 -0700 (PDT) Received: (qmail invoked by alias); 27 Jul 2011 16:13:03 -0000 Received: from dhcp-172b.meeting.ietf.org (EHLO dhcp-172b.meeting.ietf.org) [130.129.23.43] by mail.gmx.net (mp018) with SMTP; 27 Jul 2011 18:13:03 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19W0VVIeoNWtT6sNvIs2fecwBzoHko+pnnfz81l74 hlmPHqX/BuoKWJ Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Wed, 27 Jul 2011 12:12:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9C045A2C-2B23-415C-A5D7-BFF5A779611B@gmx.net> To: "ecrit@ietf.org Org" X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: Re: [Ecrit] PSAP Callback Informal Meeting, Tuesday, 17:10 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 16:13:06 -0000 Yesterday we met to discuss a way forward with the PSAP callback story = following the discussions we had during the ECRIT working group meeting.=20= The following persons attended our informal gathering:=20 - Christer Holmberg - Marc Linsner - Richard Barnes - Martin Dolly - Atle Monrad - Brian Rosen - Hannes Tschofenig - Martin Thomson - Andrew Allen [I hope I haven't forgotten anyone]=20 We used the slides I prepared for the ECRIT working group session to = sync us up on where we are at the moment with the PhoneBCP solution and = the scenarios where phone BCP fails.=20 Here are the slides:=20 http://www.ietf.org/proceedings/81/slides/ecrit-6.pptx The current PSAP callback working group draft captures these aspects: http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-02 In the subsequent discussions we then fairly quickly found an agreement = among the meeting participants that * a special emergency services GRUU would fulfill the scenarios layout = out in the Section 1 of draft-ietf-ecrit-psap-callback-02 (expect for = the PSTN interworking scenario),=20 * we agreed that the PSAP interworking scenario is not something we want = to cover with a solution being developed in ECRIT. A GRUU-based approach = will address the problems raised with all other scenarios.=20 I will work with Christer on the solution aspect to have a detailed = proposal for the ECRIT working group to look at. In particular, we will = have to update the text in Section 1 of = draft-ietf-ecrit-psap-callback-02 to talk about why the PSTN = interworking scenario is a valid scenario but outside the scope of this = work, to replace the current solution in Section 4 with a new GRUU-based = approach. Correspondingly, the security consideration section as well as = the IANA consideration section has to be changed as well. During our = meeting I had proposed to the ECRIT chairs to have Christer added as a = co-author of the working group document because of the contributions he = has made so far.=20 Since our constructive side-discussion I have a much better feeling that = we will be able to progress the work on PSAP callback faster.=20 Feedback from the working group is appreciated! Ciao Hannes On Jul 26, 2011, at 5:11 PM, Brian Rosen wrote: > Meeting in room 207 now >=20 >=20 > On Jul 25, 2011, at 4:49 PM, Hannes Tschofenig wrote: >=20 >> It will be difficult to find a slot that fits everyone. >> We will, of course, distribute some short meeting notes and will see = whether we need further discussion time during the rest of the week.=20 >>=20 >> On Jul 25, 2011, at 4:41 PM, DRAGE, Keith (Keith) wrote: >>=20 >>> That sound like it is in parallel with the RAI area meeting, which I = would like to be at. >>>=20 >>> Keith >>>=20 >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf Of >>>> Hannes Tschofenig >>>> Sent: 25 July 2011 21:38 >>>> To: ecrit@ietf.org >>>> Subject: [Ecrit] PSAP Callback Informal Meeting, Tuesday, 17:10 >>>>=20 >>>> Following today's discussion we will meet for an informal meeting = on >>>> Tuesday, 17:10 in front of the breakfast room. >>>> The purpose of our meeting is to gather ideas about how to move = forward >>>> with the PSAP callback document. >>>>=20 >>>> Ciao >>>> Hannes >>>> _______________________________________________ >>>> 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 >=20 From john@johnlange.ca Wed Jul 27 11:57:29 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8673311E814B for ; Wed, 27 Jul 2011 11:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36YmNCezue3s for ; Wed, 27 Jul 2011 11:57:28 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id A963511E8145 for ; Wed, 27 Jul 2011 11:57:28 -0700 (PDT) Received: by yie30 with SMTP id 30so1559098yie.31 for ; Wed, 27 Jul 2011 11:57:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.77.7 with SMTP id g7mr153629ick.88.1311793047892; Wed, 27 Jul 2011 11:57:27 -0700 (PDT) Received: by 10.42.222.66 with HTTP; Wed, 27 Jul 2011 11:57:27 -0700 (PDT) X-Originating-IP: [199.27.223.254] In-Reply-To: References: <8B0A9FCBB9832F43971E38010638454F040D2C36A8@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F040D2C3700@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F040D2C3721@SISPE7MB1.commscope.com> Date: Wed, 27 Jul 2011 13:57:27 -0500 Message-ID: From: John Lange To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Ecrit] SWATting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 18:57:29 -0000 Another swatting incident yesterday. http://www.cbc.ca/news/technology/story/2011/07/27/bc-langley-swatting-911-hacker.html "Cassidy says swatters can just as easily make it appear the call comes from a target's home by using one of several spoofing companies on the internet offering a free service allowing callers to choose whatever number they want to show up on the caller ID." John From john@johnlange.ca Wed Jul 27 13:28:00 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D878111E809F for ; Wed, 27 Jul 2011 13:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVvtF89SM4Wp for ; Wed, 27 Jul 2011 13:28:00 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id EE98D11E8092 for ; Wed, 27 Jul 2011 13:27:57 -0700 (PDT) Received: by yie30 with SMTP id 30so1631341yie.31 for ; Wed, 27 Jul 2011 13:27:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.97.136 with SMTP id o8mr204154icn.222.1311798477222; Wed, 27 Jul 2011 13:27:57 -0700 (PDT) Received: by 10.42.222.66 with HTTP; Wed, 27 Jul 2011 13:27:57 -0700 (PDT) X-Originating-IP: [199.27.223.254] In-Reply-To: <47F749F6-DF99-4CDE-A094-E851E6C5CC37@brianrosen.net> References: <8B0A9FCBB9832F43971E38010638454F040D2C36A8@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F040D2C3700@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F040D2C3721@SISPE7MB1.commscope.com> <47F749F6-DF99-4CDE-A094-E851E6C5CC37@brianrosen.net> Date: Wed, 27 Jul 2011 15:27:57 -0500 Message-ID: From: John Lange To: Brian Rosen Content-Type: text/plain; charset=ISO-8859-1 Cc: ecrit@ietf.org Subject: Re: [Ecrit] SWATting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 20:28:00 -0000 The story says: "In the Langley case, police said the call appeared to come from a cell phone with a California area code." So it would seem that they do indeed use callerID to some extent. The story also says it was a "fake 911" call, but I wonder if that is accurate? It would seem more likely that the call came in through a traditional non-emergency 10 digit number which could be dialed from anywhere. That would allow fake callerID and wouldn't have ANI. The "911" trunks, on the other hand, are strictly local and would use ANI, not callerID. Do PSAPs even display caller id? Or maybe it's as simple as a cloned or stolen cell phone? John From brian.rosen@neustar.biz Thu Jul 28 06:42:58 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C9721F87ED for ; Thu, 28 Jul 2011 06:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.972 X-Spam-Level: X-Spam-Status: No, score=-5.972 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5yrA0ubHmaV for ; Thu, 28 Jul 2011 06:42:57 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 5871021F8AD9 for ; Thu, 28 Jul 2011 06:42:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1311860575; x=1627214943; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=DO/0la59Khuly/DT6OyYU 2qvyHuwOn7RNDw4gqQVzyI=; b=Q+K5slgh1+d3JLLiV8vaf1BobdxotoC0kvjTR sZ53yb8+nScs8JkYhc5Jngx0wnMB5cQpflfdlEmv0Au3SHMyg== Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id 5202732.47889222; Thu, 28 Jul 2011 09:42:54 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Thu, 28 Jul 2011 09:42:53 -0400 From: "Rosen, Brian" To: "ecrit@ietf.org Org" Date: Thu, 28 Jul 2011 09:42:52 -0400 Thread-Topic: ED-66 in -phonebcp Thread-Index: AcxNLD9NmQNIBfvLR0WHBK8EFCxElA== Message-ID: <036928B6-8D98-49B1-A725-7241F9655996@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: Q/y4vxB9FGsBfJ9PGHmFsA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Ecrit] ED-66 in -phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 13:42:58 -0000 ED-66 is the "what happens if the BYE is lost" text in -phonbcp" line. It = has a security hole, which is noted, but it generated a DISCUSS. In looki= ng at the history of this, I believe it's a left over from the called party= (PSAP) control discussion (PSAP control of disconnect). I think we should= just delete the requirement. I have an editorial problem with this deletion. It is the only requirement= in the section, and the sections of -phonebcp aligns with the sections of = -framework, and there is some helpful text in -framework on termination. S= o, I ask for editorial license to replace the text of ED-66 with something = that says termination MUST use the procedures in RFC3261. This is, of cour= se, a no op. But it avoids renumbering, and avoids either an empty section= or a mismatch of sections. Brian= From rbarnes@bbn.com Thu Jul 28 07:05:39 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB8321F8B2B for ; Thu, 28 Jul 2011 07:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.594 X-Spam-Level: X-Spam-Status: No, score=-106.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DY38+Ux-fX8M for ; Thu, 28 Jul 2011 07:05:38 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 150A121F8AD3 for ; Thu, 28 Jul 2011 07:05:38 -0700 (PDT) Received: from [128.89.253.234] (port=55015 helo=dhcp-10db.meeting.ietf.org) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QmRDV-0001mN-Ib; Thu, 28 Jul 2011 10:05:37 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <036928B6-8D98-49B1-A725-7241F9655996@neustar.biz> Date: Thu, 28 Jul 2011 10:05:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <036928B6-8D98-49B1-A725-7241F9655996@neustar.biz> To: "Rosen, Brian" X-Mailer: Apple Mail (2.1082) Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] ED-66 in -phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 14:05:39 -0000 That sounds like a reasonable plan to me. --Richard On Jul 28, 2011, at 9:42 AM, Rosen, Brian wrote: > ED-66 is the "what happens if the BYE is lost" text in -phonbcp" line. = It has a security hole, which is noted, but it generated a DISCUSS. = In looking at the history of this, I believe it's a left over from the = called party (PSAP) control discussion (PSAP control of disconnect). I = think we should just delete the requirement. >=20 > I have an editorial problem with this deletion. It is the only = requirement in the section, and the sections of -phonebcp aligns with = the sections of -framework, and there is some helpful text in -framework = on termination. So, I ask for editorial license to replace the text of = ED-66 with something that says termination MUST use the procedures in = RFC3261. This is, of course, a no op. But it avoids renumbering, and = avoids either an empty section or a mismatch of sections. >=20 > Brian > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From rbarnes@bbn.com Thu Jul 28 07:06:16 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93CE321F8B21 for ; Thu, 28 Jul 2011 07:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.594 X-Spam-Level: X-Spam-Status: No, score=-106.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNCA54YC4vto for ; Thu, 28 Jul 2011 07:06:16 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 327D021F8AD3 for ; Thu, 28 Jul 2011 07:06:16 -0700 (PDT) Received: from [128.89.253.234] (port=55015 helo=dhcp-10db.meeting.ietf.org) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QmRE7-0001mN-QN; Thu, 28 Jul 2011 10:06:15 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Thu, 28 Jul 2011 10:06:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <55FE70DF-CBDD-4672-9EE6-2D392D60FE9B@bbn.com> References: <9C045A2C-2B23-415C-A5D7-BFF5A779611B@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1082) Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] PSAP Callback Informal Meeting, Tuesday, 17:10 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 14:06:16 -0000 > The following persons attended our informal gathering:=20 > - Christer Holmberg > - Marc Linsner > - Richard Barnes For the record, I did not attend this meeting. Not sure how I ended up = on the list... --Richard From mlinsner@cisco.com Thu Jul 28 07:48:10 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A0721F8CB2 for ; Thu, 28 Jul 2011 07:48:10 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-IFPqAees+L for ; Thu, 28 Jul 2011 07:48:09 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id A49F521F8CAE for ; Thu, 28 Jul 2011 07:48:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mlinsner@cisco.com; l=1557; q=dns/txt; s=iport; t=1311864489; x=1313074089; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=biObZ8ce2U2KJ/2hneaURWaZutJ4GSpnx2f9Y+mJkF0=; b=Qee2oPE5D8FHM/V5KmZIKWYhM2lNuNLbuK4rr66vb47yRaezXwXhW4q/ aL8jMcm6JavYnnzmw1vs1Y0bzdeuZq6+U63f3F2UHO69BkBITvou7zQDM X33GcVLsAQ+vvvYEaUYUlpq3A/bTIXCdwzMeRrgX20zAA3z/ekLshBpkb A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIZ1MU6rRDoG/2dsb2JhbAA0AQEBAQMBAQERASsDATYLDAgJEQMBAgFOGDEIBw8IJ6cxd4kApDWeV4ZBBJJ5hQeLeQ X-IronPort-AV: E=Sophos;i="4.67,282,1309737600"; d="scan'208";a="7402678" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-3.cisco.com with ESMTP; 28 Jul 2011 14:48:09 +0000 Received: from [10.21.113.195] (sjc-vpn2-451.cisco.com [10.21.113.195]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6SEm8Ax016838; Thu, 28 Jul 2011 14:48:08 GMT User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Thu, 28 Jul 2011 10:48:05 -0400 From: Marc Linsner To: "Rosen, Brian" Message-ID: Thread-Topic: [Ecrit] ED-66 in -phonebcp In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] ED-66 in -phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 14:48:10 -0000 +1 -Marc- -----Original Message----- From: "Richard L. Barnes" Date: Thu, 28 Jul 2011 10:05:36 -0400 To: "Rosen, Brian" Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] ED-66 in -phonebcp > > >That sounds like a reasonable plan to me. > >--Richard > > > >On Jul 28, 2011, at 9:42 AM, Rosen, Brian wrote: > >> ED-66 is the "what happens if the BYE is lost" text in -phonbcp" line. >>It has a security hole, which is noted, but it generated a DISCUSS. In >>looking at the history of this, I believe it's a left over from the >>called party (PSAP) control discussion (PSAP control of disconnect). I >>think we should just delete the requirement. >> >> I have an editorial problem with this deletion. It is the only >>requirement in the section, and the sections of -phonebcp aligns with >>the sections of -framework, and there is some helpful text in -framework >>on termination. So, I ask for editorial license to replace the text of >>ED-66 with something that says termination MUST use the procedures in >>RFC3261. This is, of course, a no op. But it avoids renumbering, and >>avoids either an empty section or a mismatch of sections. >> >> Brian >> _______________________________________________ >> 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 internet-drafts@ietf.org Thu Jul 28 10:39:09 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69EB511E80CC; Thu, 28 Jul 2011 10:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFC2UD4UPJ8D; Thu, 28 Jul 2011 10:39:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F82321F88A5; Thu, 28 Jul 2011 10:39:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.57 Message-ID: <20110728173909.29296.8273.idtracker@ietfa.amsl.com> Date: Thu, 28 Jul 2011 10:39:09 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-phonebcp-18.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 17:39:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Int= ernet Technologies Working Group of the IETF. Title : Best Current Practice for Communications Services in sup= port of Emergency Calling Author(s) : Brian Rosen James Polk Filename : draft-ietf-ecrit-phonebcp-18.txt Pages : 26 Date : 2011-07-28 The IETF and other standards organization have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks and services should use such standards to make emergency calls. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-18.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-18.txt From brian.rosen@neustar.biz Thu Jul 28 11:01:13 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F55E11E810B for ; Thu, 28 Jul 2011 11:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.022 X-Spam-Level: X-Spam-Status: No, score=-6.022 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjDHbkG-1iY5 for ; Thu, 28 Jul 2011 11:01:11 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 314AC11E80E2 for ; Thu, 28 Jul 2011 11:01:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1311876068; x=1627200462; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=ZoNBrzBaqhxiIgEXPPDXj LmhC3dZt4bJslOn7jRjPQY=; b=lCZh5+qCMsdTDxmRXn3A93YFdfVglyIPTEHuS ZOMvMxU+RP2MwuSdpE+eR3GSggXvVt/YBKfmHHSQRUHr/A3FA== Received: from ([10.31.13.228]) by stihiron1.va.neustar.com with ESMTP with TLS id G6K7MJ1.25306703; Thu, 28 Jul 2011 14:01:07 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Thu, 28 Jul 2011 14:01:06 -0400 From: "Rosen, Brian" To: "ecrit@ietf.org Org" Date: Thu, 28 Jul 2011 14:01:05 -0400 Thread-Topic: IPsec Thread-Index: AcxNUFJpHl1V6m6yTYGeeExxUUMvmw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: EuKQh82XWmrYFi280tAnNg== Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Ecrit] IPsec X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 18:01:13 -0000 I forgot an item, sigh. I said there would be another version=85 Stephen Farrell objected to our text on allowing either IPsec or TLS, becau= se the usual concerns about implementors making non interoperable choices. My solution is to change ED-48/SP-24 to: Either TLS or IPsec MUST be used to protect location (but see Section ??). = All implementations MUST support TLS. IPsec MAY be used instead of TLS on= any hop. Brian= From rbarnes@bbn.com Thu Jul 28 11:09:25 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F255321F89B8 for ; Thu, 28 Jul 2011 11:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.594 X-Spam-Level: X-Spam-Status: No, score=-106.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdbUUyEQCqBX for ; Thu, 28 Jul 2011 11:09:25 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6D12C21F899F for ; Thu, 28 Jul 2011 11:09:25 -0700 (PDT) Received: from [128.89.253.186] (port=55488 helo=dhcp-10db.meeting.ietf.org) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QmV1P-0005Uh-4N; Thu, 28 Jul 2011 14:09:23 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: "Richard L. Barnes" In-Reply-To: Date: Thu, 28 Jul 2011 14:09:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0E908176-F06D-4738-AEDC-1B74CB549738@bbn.com> References: To: "Rosen, Brian" X-Mailer: Apple Mail (2.1082) Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] IPsec X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 18:09:26 -0000 Note that the following already exists in RFC 3261: " Proxy servers, redirect servers, and registrars MUST implement TLS, and MUST support both mutual and one-way authentication. It is strongly RECOMMENDED that UAs be capable initiating TLS; UAs MAY also be capable of acting as a TLS server. " Could we just refer to this? --Richard On Jul 28, 2011, at 2:01 PM, Rosen, Brian wrote: > I forgot an item, sigh. I said there would be another version=85 >=20 > Stephen Farrell objected to our text on allowing either IPsec or TLS, = because the usual concerns about implementors making non interoperable = choices. >=20 > My solution is to change ED-48/SP-24 to: > Either TLS or IPsec MUST be used to protect location (but see Section = ??). All implementations MUST support TLS. IPsec MAY be used instead = of TLS on any hop. >=20 > Brian > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From brian.rosen@neustar.biz Thu Jul 28 11:15:46 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFE611E80F0 for ; Thu, 28 Jul 2011 11:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.301 X-Spam-Level: X-Spam-Status: No, score=-6.301 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Y3MrpJogV8D for ; Thu, 28 Jul 2011 11:15:46 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id CBC9B11E80D7 for ; Thu, 28 Jul 2011 11:15:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1311876939; x=1627234752; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=8pvLpzB9XN5yYfLJfMikG SL6pgTgUJVDcW6DsT0Cx3E=; b=eNnelahLyPmuIC4CHpwE486io+fbADDOVlCYz v32NjTvh3PVSjKnI6bwRnNkl2Nnf1IC+OHlTMDdwSnJFRR0/g== Received: from ([10.31.13.229]) by chihiron2.nc.neustar.com with ESMTP with TLS id 5202415.39791073; Thu, 28 Jul 2011 14:15:38 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Thu, 28 Jul 2011 14:15:37 -0400 From: "Rosen, Brian" To: "Richard L. Barnes" Date: Thu, 28 Jul 2011 14:15:36 -0400 Thread-Topic: [Ecrit] IPsec Thread-Index: AcxNUlmtvSRVTsHKRYKTnlKVGG7k4g== Message-ID: <1CF65D62-7DBF-447E-912E-4B27002B70B6@neustar.biz> References: <0E908176-F06D-4738-AEDC-1B74CB549738@bbn.com> In-Reply-To: <0E908176-F06D-4738-AEDC-1B74CB549738@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: VnnUjFmY8eLipITm4y5cFw== Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] IPsec X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 18:15:46 -0000 I may have to pass that by Stephen, because it doesn't require it at the UA= . Brian On Jul 28, 2011, at 2:09 PM, Richard L. Barnes wrote: > Note that the following already exists in RFC 3261: > " > Proxy servers, redirect servers, and registrars MUST implement TLS, > and MUST support both mutual and one-way authentication. It is > strongly RECOMMENDED that UAs be capable initiating TLS; UAs MAY also > be capable of acting as a TLS server. > " >=20 > Could we just refer to this? >=20 > --Richard >=20 >=20 >=20 > On Jul 28, 2011, at 2:01 PM, Rosen, Brian wrote: >=20 >> I forgot an item, sigh. I said there would be another version=85 >>=20 >> Stephen Farrell objected to our text on allowing either IPsec or TLS, be= cause the usual concerns about implementors making non interoperable choice= s. >>=20 >> My solution is to change ED-48/SP-24 to: >> Either TLS or IPsec MUST be used to protect location (but see Section ??= ). All implementations MUST support TLS. IPsec MAY be used instead of TLS= on any hop. >>=20 >> Brian >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 From jmpolk@cisco.com Thu Jul 28 11:21:42 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5C1F11E8145 for ; Thu, 28 Jul 2011 11:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0x4SToiQcdD for ; Thu, 28 Jul 2011 11:21:42 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id E4A0B11E813B for ; Thu, 28 Jul 2011 11:21:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1522; q=dns/txt; s=iport; t=1311877302; x=1313086902; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version:content-transfer-encoding; bh=M+tFx7dv/Tw+MQNgkYiublDeYQJ8CsTXmPxMwSyyowA=; b=WQxPjFglrTMjRBOU4LSusIy5WmACnee4MZCX678x4g4aRab2P7QqBwV0 C/GanClR96wrUyhfUszc2vvi71d7ZNrQshFp6b/4XZJ7/2U83sftAnNUV eLOIHuc7jptOl98euhJ4He+0S15G1FYwgoc3khnULs98MWoGdCKYQ2VLR 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACeoMU6tJXG8/2dsb2JhbAA0AQEBAQMBAQERASk8CxEIBBg6FAYSOQcXIAemUWl3iQCkaJ5EhkEEhyovnCI X-IronPort-AV: E=Sophos;i="4.67,283,1309737600"; d="scan'208";a="7483027" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 28 Jul 2011 18:21:41 +0000 Received: from jmpolk-wxp01.cisco.com (rtp-vpn2-246.cisco.com [10.82.240.246]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6SILes8029918; Thu, 28 Jul 2011 18:21:41 GMT Message-Id: <201107281821.p6SILes8029918@rcdn-core2-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 28 Jul 2011 13:21:39 -0500 To: "Richard L. Barnes" , "Rosen, Brian" From: "James M. Polk" In-Reply-To: <0E908176-F06D-4738-AEDC-1B74CB549738@bbn.com> References: <0E908176-F06D-4738-AEDC-1B74CB549738@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] IPsec X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 18:21:42 -0000 Richard 3261 saying SIP servers "...MUST implement=20 TLS..." and "...strongly RECOMMENDED that UAs use=20 TLS..." is very different than Phonebcp now=20 saying "...UAs MUST support TLS." and "...IPsec MAY be used per hop..." I like what phonebcp says now. James At 01:09 PM 7/28/2011, Richard L. Barnes wrote: >Note that the following already exists in RFC 3261: >" >Proxy servers, redirect servers, and registrars MUST implement TLS, >and MUST support both mutual and one-way authentication. It is >strongly RECOMMENDED that UAs be capable initiating TLS; UAs MAY also >be capable of acting as a TLS server. >" > >Could we just refer to this? > >--Richard > > > >On Jul 28, 2011, at 2:01 PM, Rosen, Brian wrote: > > > I forgot an item, sigh. I said there would be another version=85 > > > > Stephen Farrell objected to our text on=20 > allowing either IPsec or TLS, because the usual=20 > concerns about implementors making non interoperable choices. > > > > My solution is to change ED-48/SP-24 to: > > Either TLS or IPsec MUST be used to protect=20 > location (but see Section ??). All=20 > implementations MUST support TLS. IPsec MAY be used instead of TLS on any= hop. > > > > Brian > > _______________________________________________ > > 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 paulbeaumont.ietf@gmail.com Thu Jul 28 11:19:47 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD70F11E8162 for ; Thu, 28 Jul 2011 11:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjlSTiHJWCno for ; Thu, 28 Jul 2011 11:19:47 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE5011E80F8 for ; Thu, 28 Jul 2011 11:19:46 -0700 (PDT) Received: by qyk29 with SMTP id 29so1893473qyk.10 for ; Thu, 28 Jul 2011 11:19:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:from:content-type:x-mailer:message-id:date:to :content-transfer-encoding:mime-version; bh=J4VjdStI+5gbzMxiy4Kqhva9pMzy1wvGa4DSLbhS+Kk=; b=w101WibUz25Z/T6JqbKLKdGQnf+vx8Z0nITIWdMljQF46j/yVii17Rbt0E12XK1wIN I1uYCnO8KdzymX9bmZ8/bcsjGdJw/OHuGF+5lBa3V2M7jN3+i5SGhLrrFuhbZ+UAi572 TaAmCFwCqwMJ6P3/sJfbmbCGmV5HJj8tsV9EM= Received: by 10.229.53.82 with SMTP id l18mr243853qcg.286.1311877185611; Thu, 28 Jul 2011 11:19:45 -0700 (PDT) Received: from [130.129.21.194] (dhcp-15c2.meeting.ietf.org [130.129.21.194]) by mx.google.com with ESMTPS id b6sm846468qcb.35.2011.07.28.11.19.44 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jul 2011 11:19:45 -0700 (PDT) From: Paul Beaumont Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (8J2) Message-Id: <8CC2315D-DAD1-4948-A014-FD36DC6BECE2@gmail.com> Date: Thu, 28 Jul 2011 19:20:31 +0100 To: IETF - ECRIT Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (iPad Mail 8J2) Subject: [Ecrit] Emergency Call On-Hook / Off-Hook Indication during Manual Hold Over SIP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 18:23:56 -0000 All Apologies, being first time to IETF and its mailing lists, if this is not th= e right mailing list to post this request to. There does not appear to be a standardised means using SIP on emergency call= s where B-Party Control [aka Manual Hold] to allow the Emergency Service ope= rator to have visibility of the A-Party [who called 999/112/18000*] hook sta= te. This is something that is supported in circuit switched and is intrinsic= to Emergency Service bureau processes. To deal with young children playing w= ith the phone, persons dialling hoax calls, persons incapacitated during the= call, etc. Today this is done using SS7 ISUP SUSpend [on-hook cleared] and R= ESume [off-hook reanswer]. One possibility, although not specifically intend= ed for this purpose - it's for ISDN Terminal Portability - is to formalise u= se of P-Service-Notification of "user-suspended" and "user-resumed" respecti= vely between Service Provider platforms. Currently the mechanism to achieve t= his capability is not consistent between IP interconnected operators and als= o even in a SP's own network where interworking between SIP on Inter Machine= Trunk and legacy SS7 ISUP InterConnect Trunks. Please can you advise where I should submit this question or if this is the r= ight forum then whether the above observation is correct and any supplementa= l information/comments you may have?=20 Thanks Paul Beaumont * PS I do not know if this would also be true in NA with 911 and for other n= ations beyond UK= From g.caron@bell.ca Thu Jul 28 11:34:28 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C522211E8118 for ; Thu, 28 Jul 2011 11:34: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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLV565vmbKJT for ; Thu, 28 Jul 2011 11:34:28 -0700 (PDT) Received: from mail91.messagelabs.com (mail91.messagelabs.com [194.106.220.35]) by ietfa.amsl.com (Postfix) with ESMTP id BDA2611E811C for ; Thu, 28 Jul 2011 11:34:27 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: g.caron@bell.ca X-Msg-Ref: server-15.tower-91.messagelabs.com!1311878060!30023289!8 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [206.47.0.173] Received: (qmail 4565 invoked from network); 28 Jul 2011 18:34:26 -0000 Received: from bell.ca (HELO TLS.Exchange.Bell.ca) (206.47.0.173) by server-15.tower-91.messagelabs.com with RC4-SHA encrypted SMTP; 28 Jul 2011 18:34:26 -0000 Received: from hub02-wyn.bell.corp.bce.ca (142.182.199.50) by dm1c8f.exchange1.bell.ca (198.235.102.112) with Microsoft SMTP Server id 8.3.83.0; Thu, 28 Jul 2011 14:34:24 -0400 Received: from MBX02.bell.corp.bce.ca ([142.182.199.11]) by hub02-wyn.bell.corp.bce.ca ([142.182.199.50]) with mapi; Thu, 28 Jul 2011 14:33:59 -0400 From: "g.caron@bell.ca" To: Paul Beaumont , IETF - ECRIT Date: Thu, 28 Jul 2011 14:33:58 -0400 Thread-Topic: [Ecrit] Emergency Call On-Hook / Off-Hook Indication during Manual Hold Over SIP Thread-Index: AcxNU3omD3/Ax+i5Qz2SfmzXI3EkAgAAFP3g Message-ID: <0FEAC1C09868B34A982F4FB40254B37C290158A9D2@MBX02.bell.corp.bce.ca> References: <8CC2315D-DAD1-4948-A014-FD36DC6BECE2@gmail.com> In-Reply-To: <8CC2315D-DAD1-4948-A014-FD36DC6BECE2@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Ecrit] Emergency Call On-Hook / Off-Hook Indication during Manual Hold Over SIP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 18:34:28 -0000 Hi Paul, This is an concept (not necessarily the mechanism) that I support as it is = definitively a requirement for some countries, notable in North America. I'= m certain you are referring to the PSTN only by way of example, not implyin= g to replicate how this functionality is implemented. I do believe that having a STANDARD mechanism will be beneficial to avoid t= he vendor-specific, non-compatible approaches we have to deal with today. Guy -----Message d'origine----- De=A0: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] De la part de= Paul Beaumont Envoy=E9=A0: 28 juillet 2011 14:21 =C0=A0: IETF - ECRIT Objet=A0: [Ecrit] Emergency Call On-Hook / Off-Hook Indication during Manua= l Hold Over SIP All Apologies, being first time to IETF and its mailing lists, if this is not t= he right mailing list to post this request to. There does not appear to be a standardised means using SIP on emergency cal= ls where B-Party Control [aka Manual Hold] to allow the Emergency Service o= perator to have visibility of the A-Party [who called 999/112/18000*] hook = state. This is something that is supported in circuit switched and is intri= nsic to Emergency Service bureau processes. To deal with young children pla= ying with the phone, persons dialling hoax calls, persons incapacitated dur= ing the call, etc. Today this is done using SS7 ISUP SUSpend [on-hook clear= ed] and RESume [off-hook reanswer]. One possibility, although not specifica= lly intended for this purpose - it's for ISDN Terminal Portability - is to = formalise use of P-Service-Notification of "user-suspended" and "user-resum= ed" respectively between Service Provider platforms. Currently the mechanis= m to achieve this capability is not consistent between IP interconnected op= erators and also even in a SP's own network where interworking between SIP = on Inter Machin e Trunk and legacy SS7 ISUP InterConnect Trunks. Please can you advise where I should submit this question or if this is the= right forum then whether the above observation is correct and any suppleme= ntal information/comments you may have?=20 Thanks Paul Beaumont * PS I do not know if this would also be true in NA with 911 and for other = nations beyond UK _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From brian.rosen@neustar.biz Thu Jul 28 11:40:54 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA6715E800D for ; Thu, 28 Jul 2011 11:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.325 X-Spam-Level: X-Spam-Status: No, score=-6.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7g4LJle6vfI for ; Thu, 28 Jul 2011 11:40:54 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED5B21F880C for ; Thu, 28 Jul 2011 11:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1311878451; x=1627238286; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=+D7DQf9r1u1VLMDcWcVpI NIHZ97lFdkVM/V8KvQnsRU=; b=V5a1mR6a8kL6BL7lcpeRN/86UFR1rkroOtjSD t6sHhSDKTB6YWoiaAetAiLFi5+0FZZ4og/FAIz0ZZVV59uMHg== Received: from ([10.31.13.228]) by stihiron1.va.neustar.com with ESMTP with TLS id G6K7MJ1.25308210; Thu, 28 Jul 2011 14:40:50 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Thu, 28 Jul 2011 14:40:49 -0400 From: "Rosen, Brian" To: Paul Beaumont Date: Thu, 28 Jul 2011 14:40:48 -0400 Thread-Topic: [Ecrit] Emergency Call On-Hook / Off-Hook Indication during Manual Hold Over SIP Thread-Index: AcxNVd7qqDTB7VJNQrSFuzl4OXEhHg== Message-ID: References: <8CC2315D-DAD1-4948-A014-FD36DC6BECE2@gmail.com> In-Reply-To: <8CC2315D-DAD1-4948-A014-FD36DC6BECE2@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: z3wEUT4qf6CiIPL14fyjJw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF - ECRIT Subject: Re: [Ecrit] Emergency Call On-Hook / Off-Hook Indication during Manual Hold Over SIP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 18:40:55 -0000 If I'm following this, you are talking about the ability of the PSAP to con= trol termination of the call, and be able to detect hook state while the ca= ll is being held up by the PSAP. This is a long running discussion. This requirement is very firm for some = members of the work group, but has very strong opposition. Some of those o= bjecting believe that the mechanism the PSTN uses is inappropriate, and the= problem that the PSTN solution addresses is better obtained with user inte= rface changes on IP devices. Other objectors believe that it should not be= possible for the PSAP to hold the call because it may use too many resourc= es in a network, especially a mobile network. We have had numerous conversations. We could not converge on a problem sta= tement, requirements or solutions. =20 Given the IETF consensus process, I personally don't see a way forward on t= his requirement, although if there were significantly more participants who= came to the conclusion that the requirement is important, and solutions mu= st be found, that could change. There have been discussions of doing this w= ork outside the IETF, but that would violate the SIP change process. =20 Brian On Jul 28, 2011, at 2:20 PM, Paul Beaumont wrote: > All >=20 > Apologies, being first time to IETF and its mailing lists, if this is not= the right mailing list to post this request to. >=20 > There does not appear to be a standardised means using SIP on emergency c= alls where B-Party Control [aka Manual Hold] to allow the Emergency Service= operator to have visibility of the A-Party [who called 999/112/18000*] hoo= k state. This is something that is supported in circuit switched and is int= rinsic to Emergency Service bureau processes. To deal with young children p= laying with the phone, persons dialling hoax calls, persons incapacitated d= uring the call, etc. Today this is done using SS7 ISUP SUSpend [on-hook cle= ared] and RESume [off-hook reanswer]. One possibility, although not specifi= cally intended for this purpose - it's for ISDN Terminal Portability - is t= o formalise use of P-Service-Notification of "user-suspended" and "user-res= umed" respectively between Service Provider platforms. Currently the mechan= ism to achieve this capability is not consistent between IP interconnected = operators and also even in a SP's own network where interworking between SI= P on Inter Machin > e Trunk and legacy SS7 ISUP InterConnect Trunks. >=20 > Please can you advise where I should submit this question or if this is t= he right forum then whether the above observation is correct and any supple= mental information/comments you may have?=20 >=20 > Thanks > Paul Beaumont >=20 > * PS I do not know if this would also be true in NA with 911 and for othe= r nations beyond UK > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From keith.drage@alcatel-lucent.com Thu Jul 28 11:42:04 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 638405E801E for ; Thu, 28 Jul 2011 11:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.905 X-Spam-Level: X-Spam-Status: No, score=-105.905 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDlaqg2pMcbz for ; Thu, 28 Jul 2011 11:42:03 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8E97421F887C for ; Thu, 28 Jul 2011 11:42:03 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p6SIfxwu027877 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 28 Jul 2011 20:42:00 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 28 Jul 2011 20:42:00 +0200 From: "DRAGE, Keith (Keith)" To: "g.caron@bell.ca" , Paul Beaumont , IETF - ECRIT Date: Thu, 28 Jul 2011 20:41:58 +0200 Thread-Topic: [Ecrit] Emergency Call On-Hook / Off-Hook Indication during Manual Hold Over SIP Thread-Index: AcxNU3omD3/Ax+i5Qz2SfmzXI3EkAgAAFP3gAAB4etA= Message-ID: References: <8CC2315D-DAD1-4948-A014-FD36DC6BECE2@gmail.com> <0FEAC1C09868B34A982F4FB40254B37C290158A9D2@MBX02.bell.corp.bce.ca> In-Reply-To: <0FEAC1C09868B34A982F4FB40254B37C290158A9D2@MBX02.bell.corp.bce.ca> 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: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: Re: [Ecrit] Emergency Call On-Hook / Off-Hook Indication during Manual Hold Over SIP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 18:42:04 -0000 I believe this was extensively discussed during the development of this doc= ument. Given the late stage of this document before publication, I think it behove= s anyone wanting a change in the document to identify new arguments over an= d above the prior discussion which took place a long long time ago. Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > g.caron@bell.ca > Sent: 28 July 2011 19:34 > To: Paul Beaumont; IETF - ECRIT > Subject: Re: [Ecrit] Emergency Call On-Hook / Off-Hook Indication during > Manual Hold Over SIP >=20 > Hi Paul, >=20 > This is an concept (not necessarily the mechanism) that I support as it i= s > definitively a requirement for some countries, notable in North America. > I'm certain you are referring to the PSTN only by way of example, not > implying to replicate how this functionality is implemented. >=20 > I do believe that having a STANDARD mechanism will be beneficial to avoid > the vendor-specific, non-compatible approaches we have to deal with today= . >=20 > Guy >=20 > -----Message d'origine----- > De=A0: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] De la part = de > Paul Beaumont > Envoy=E9=A0: 28 juillet 2011 14:21 > =C0=A0: IETF - ECRIT > Objet=A0: [Ecrit] Emergency Call On-Hook / Off-Hook Indication during Man= ual > Hold Over SIP >=20 > All >=20 > Apologies, being first time to IETF and its mailing lists, if this is not > the right mailing list to post this request to. >=20 > There does not appear to be a standardised means using SIP on emergency > calls where B-Party Control [aka Manual Hold] to allow the Emergency > Service operator to have visibility of the A-Party [who called > 999/112/18000*] hook state. This is something that is supported in circui= t > switched and is intrinsic to Emergency Service bureau processes. To deal > with young children playing with the phone, persons dialling hoax calls, > persons incapacitated during the call, etc. Today this is done using SS7 > ISUP SUSpend [on-hook cleared] and RESume [off-hook reanswer]. One > possibility, although not specifically intended for this purpose - it's > for ISDN Terminal Portability - is to formalise use of P-Service- > Notification of "user-suspended" and "user-resumed" respectively between > Service Provider platforms. Currently the mechanism to achieve this > capability is not consistent between IP interconnected operators and also > even in a SP's own network where interworking between SIP on Inter Machin > e Trunk and legacy SS7 ISUP InterConnect Trunks. >=20 > Please can you advise where I should submit this question or if this is > the right forum then whether the above observation is correct and any > supplemental information/comments you may have? >=20 > Thanks > Paul Beaumont >=20 > * PS I do not know if this would also be true in NA with 911 and for othe= r > nations beyond UK > _______________________________________________ > 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 Jul 28 11:47:00 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFBD5E801D for ; Thu, 28 Jul 2011 11:47:00 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aO6QIrRRwM9G for ; Thu, 28 Jul 2011 11:46:59 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id D1D8711E8101 for ; Thu, 28 Jul 2011 11:46:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mlinsner@cisco.com; l=2165; q=dns/txt; s=iport; t=1311878819; x=1313088419; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=UZq8YsjfL0cy6weCScE3/icA6Cxr/VMDta0ptyZZaZk=; b=lW3izoOPIxs4zky0nJ5Z97oMGRv25hFwEXiDyfOBi0lcyXTbxIIuDzvX 5/9rKWsz8mZUZvMQDjcwxFoblADyj5qRnsECbnfUUJT/N8eVG7EE6qisO vhhH7mnAqaPlyl3EOGGdGcFJU7gyFLUvmxsDE8X1OW6ecy9SfRTqUjjMM E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMatMU6rRDoJ/2dsb2JhbAA0AQEBAQMBAQERAQ8cAwE2FwgJEQMBAho1EgYxCAcBFienOneJAKUTnkGDKoMXBJJ5hQeEZIcV X-IronPort-AV: E=Sophos;i="4.67,283,1309737600"; d="scan'208";a="7492973" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-3.cisco.com with ESMTP; 28 Jul 2011 18:46:32 +0000 Received: from [10.21.90.195] (sjc-vpn5-707.cisco.com [10.21.90.195]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6SIkTns012467; Thu, 28 Jul 2011 18:46:31 GMT User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Thu, 28 Jul 2011 14:46:28 -0400 From: Marc Linsner To: Paul Beaumont , IETF - ECRIT Message-ID: Thread-Topic: [Ecrit] Emergency Call On-Hook / Off-Hook Indication during Manual Hold Over SIP In-Reply-To: <8CC2315D-DAD1-4948-A014-FD36DC6BECE2@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [Ecrit] Emergency Call On-Hook / Off-Hook Indication during Manual Hold Over SIP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 18:47:00 -0000 Paul, Feel free to review the draft submission at: http://tools.ietf.org/html/draft-rosen-ecrit-premature-disconnect-rqmts-02 You may also find message threads on the topic in the list archives in the early 2009 timeframe. -Marc- -----Original Message----- From: Paul Beaumont Date: Thu, 28 Jul 2011 19:20:31 +0100 To: IETF - ECRIT Subject: [Ecrit] Emergency Call On-Hook / Off-Hook Indication during Manual Hold Over SIP >All > >Apologies, being first time to IETF and its mailing lists, if this is not >the right mailing list to post this request to. > >There does not appear to be a standardised means using SIP on emergency >calls where B-Party Control [aka Manual Hold] to allow the Emergency >Service operator to have visibility of the A-Party [who called >999/112/18000*] hook state. This is something that is supported in >circuit switched and is intrinsic to Emergency Service bureau processes. >To deal with young children playing with the phone, persons dialling hoax >calls, persons incapacitated during the call, etc. Today this is done >using SS7 ISUP SUSpend [on-hook cleared] and RESume [off-hook reanswer]. >One possibility, although not specifically intended for this purpose - >it's for ISDN Terminal Portability - is to formalise use of >P-Service-Notification of "user-suspended" and "user-resumed" >respectively between Service Provider platforms. Currently the mechanism >to achieve this capability is not consistent between IP interconnected >operators and also even in a SP's own network where interworking between >SIP on Inter Machin > e Trunk and legacy SS7 ISUP InterConnect Trunks. > >Please can you advise where I should submit this question or if this is >the right forum then whether the above observation is correct and any >supplemental information/comments you may have? > >Thanks >Paul Beaumont > >* PS I do not know if this would also be true in NA with 911 and for >other nations beyond UK >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From mary.ietf.barnes@gmail.com Thu Jul 28 11:50:09 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9EC5E8020 for ; Thu, 28 Jul 2011 11:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.463 X-Spam-Level: X-Spam-Status: No, score=-103.463 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XCFARKcLWjs for ; Thu, 28 Jul 2011 11:50:09 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 890E45E801D for ; Thu, 28 Jul 2011 11:50:01 -0700 (PDT) Received: by vws12 with SMTP id 12so2689168vws.31 for ; Thu, 28 Jul 2011 11:50:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6PqZ/M+XYal5QKnbrQGtkaD/U83HTY4CmcVKM/OAhzY=; b=P2XXteBZOYnK+4PaBbj75TOTcSwEZNXxR1Yr/H+ItTNyENpKoFs4GzYnmEuYHiFG2R KHPqGdCIGQXbIyeyFNY3cV+t/oBRTPmuVdQIooLs9HChHwxOA42F/CHIfBQdk58QBuCa MIacJgEcMg1dq/AoSYT+ws4/lv4koNV20Lp/8= MIME-Version: 1.0 Received: by 10.52.183.42 with SMTP id ej10mr367651vdc.451.1311879001042; Thu, 28 Jul 2011 11:50:01 -0700 (PDT) Received: by 10.52.167.34 with HTTP; Thu, 28 Jul 2011 11:50:01 -0700 (PDT) In-Reply-To: <55FE70DF-CBDD-4672-9EE6-2D392D60FE9B@bbn.com> References: <9C045A2C-2B23-415C-A5D7-BFF5A779611B@gmx.net> <55FE70DF-CBDD-4672-9EE6-2D392D60FE9B@bbn.com> Date: Thu, 28 Jul 2011 13:50:01 -0500 Message-ID: From: Mary Barnes To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=bcaec548a017d8707c04a925a1d5 Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] PSAP Callback Informal Meeting, Tuesday, 17:10 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 18:50:09 -0000 --bcaec548a017d8707c04a925a1d5 Content-Type: text/plain; charset=ISO-8859-1 And, it was a really bad idea to schedule this during the RAI area meeting. In particular, since all the 3GPP people were at this meeting and not at the RAI area meeting. I would have thought that they had some feedback on how the process is working. Mary. On Thu, Jul 28, 2011 at 9:06 AM, Richard L. Barnes wrote: > > The following persons attended our informal gathering: > > - Christer Holmberg > > - Marc Linsner > > - Richard Barnes > > For the record, I did not attend this meeting. Not sure how I ended up on > the list... > > --Richard > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > --bcaec548a017d8707c04a925a1d5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable And, it was a really bad idea to schedule this during the RAI area meeting.= =A0In particular, since all the 3GPP people were at this meeting and not a= t the RAI area meeting. I would have thought that they had some feedback on= how the process is working. =A0=A0

Mary.=A0

On Thu, Jul 28, 2= 011 at 9:06 AM, Richard L. Barnes <rbarnes@bbn.com> wrote:
> The following persons attended our informal gatherin= g:
> - Christer Holmberg
> - Marc Linsner
> - Richard Barnes

For the record, I did not attend this meeting. =A0Not sure how I ende= d up on the list...

--Richard


_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ecrit

--bcaec548a017d8707c04a925a1d5-- From keith.drage@alcatel-lucent.com Thu Jul 28 12:56:05 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5A121F8A7A for ; Thu, 28 Jul 2011 12:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.918 X-Spam-Level: X-Spam-Status: No, score=-105.918 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9opvmvIhqVi for ; Thu, 28 Jul 2011 12:56:05 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id B0F4721F8A70 for ; Thu, 28 Jul 2011 12:56:04 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p6SJu3We030346 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 28 Jul 2011 21:56:03 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 28 Jul 2011 21:56:03 +0200 From: "DRAGE, Keith (Keith)" To: "Rosen, Brian" , "ecrit@ietf.org Org" Date: Thu, 28 Jul 2011 21:56:01 +0200 Thread-Topic: ED-66 in -phonebcp Thread-Index: AcxNLD9NmQNIBfvLR0WHBK8EFCxElAAM/sQg Message-ID: References: <036928B6-8D98-49B1-A725-7241F9655996@neustar.biz> In-Reply-To: <036928B6-8D98-49B1-A725-7241F9655996@neustar.biz> 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.64 on 155.132.188.80 Subject: Re: [Ecrit] ED-66 in -phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 19:56:05 -0000 Why not just replace it with text that says: "This is an empty section to maintain alignment of section numbering with R= FC XXXX" Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Rosen, Brian > Sent: 28 July 2011 14:43 > To: ecrit@ietf.org Org > Subject: [Ecrit] ED-66 in -phonebcp >=20 > ED-66 is the "what happens if the BYE is lost" text in -phonbcp" line. I= t > has a security hole, which is noted, but it generated a DISCUSS. In > looking at the history of this, I believe it's a left over from the calle= d > party (PSAP) control discussion (PSAP control of disconnect). I think we > should just delete the requirement. >=20 > I have an editorial problem with this deletion. It is the only > requirement in the section, and the sections of -phonebcp aligns with the > sections of -framework, and there is some helpful text in -framework on > termination. So, I ask for editorial license to replace the text of ED-6= 6 > with something that says termination MUST use the procedures in RFC3261. > This is, of course, a no op. But it avoids renumbering, and avoids eithe= r > an empty section or a mismatch of sections. >=20 > Brian > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From brian.rosen@neustar.biz Thu Jul 28 13:26:34 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA8C11E808A for ; Thu, 28 Jul 2011 13:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.07 X-Spam-Level: X-Spam-Status: No, score=-6.07 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5O+vKAoVE0S3 for ; Thu, 28 Jul 2011 13:26:33 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 51B7511E8083 for ; Thu, 28 Jul 2011 13:26:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1311884790; x=1627231160; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=dkoXj6HBAYmyuWpvMX1cv yqS3ldwoY8kXeV9l+AiK0c=; b=AsH2XaCsV9Zsu3ymcMFzmiWVrCnxzWe8u5zPf /13Mz5wQIGFpd3gWjMufi+vcFsmxyA2NQqFE7MIoo39spOfGA== Received: from ([10.31.13.229]) by stihiron2.va.neustar.com with ESMTP with TLS id 5202732.47901795; Thu, 28 Jul 2011 16:26:29 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Thu, 28 Jul 2011 16:26:29 -0400 From: "Rosen, Brian" To: "DRAGE, Keith (Keith)" Date: Thu, 28 Jul 2011 16:26:28 -0400 Thread-Topic: [Ecrit] ED-66 in -phonebcp Thread-Index: AcxNZKFSWxaLlBc9TES5lO0JD5uEzw== Message-ID: <56F14846-89F7-4A35-95F0-176717F32575@neustar.biz> References: <036928B6-8D98-49B1-A725-7241F9655996@neustar.biz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: qnq+23OlQyz8/cJfcJj3Wg== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] ED-66 in -phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 20:26:34 -0000 Keith and I have been discussing this off list. We are down to > Section?? Termination >=20 > This is an empty section to maintain alignment... > ED-66 Void or > Section ?? Termination >=20 > ED-66 Do what 3261 says This is a small issue of little impact. Keith doesn't like meaningless req= uirements Brian 't Jul 28, 2011, at 3:56 PM, DRAGE, Keith (Keith) wrote: > Why not just replace it with text that says: >=20 > "This is an empty section to maintain alignment of section numbering with= RFC XXXX" >=20 > Keith >=20 >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf O= f >> Rosen, Brian >> Sent: 28 July 2011 14:43 >> To: ecrit@ietf.org Org >> Subject: [Ecrit] ED-66 in -phonebcp >>=20 >> ED-66 is the "what happens if the BYE is lost" text in -phonbcp" line. = It >> has a security hole, which is noted, but it generated a DISCUSS. In >> looking at the history of this, I believe it's a left over from the call= ed >> party (PSAP) control discussion (PSAP control of disconnect). I think w= e >> should just delete the requirement. >>=20 >> I have an editorial problem with this deletion. It is the only >> requirement in the section, and the sections of -phonebcp aligns with th= e >> sections of -framework, and there is some helpful text in -framework on >> termination. So, I ask for editorial license to replace the text of ED-= 66 >> with something that says termination MUST use the procedures in RFC3261. >> This is, of course, a no op. But it avoids renumbering, and avoids eith= er >> an empty section or a mismatch of sections. >>=20 >> Brian >> _______________________________________________ >> 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 Jul 28 13:53:02 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 920E021F8B36 for ; Thu, 28 Jul 2011 13:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.595 X-Spam-Level: X-Spam-Status: No, score=-106.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+s3p3CeWZGu for ; Thu, 28 Jul 2011 13:53:02 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6B521F8B23 for ; Thu, 28 Jul 2011 13:53:02 -0700 (PDT) Received: from [128.89.253.184] (port=56267 helo=dhcp-10db.meeting.ietf.org) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QmXZl-000Pp6-3p; Thu, 28 Jul 2011 16:53:01 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <56F14846-89F7-4A35-95F0-176717F32575@neustar.biz> Date: Thu, 28 Jul 2011 16:52:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <08C35305-E921-4456-B088-DE1E33FE838C@bbn.com> References: <036928B6-8D98-49B1-A725-7241F9655996@neustar.biz> <56F14846-89F7-4A35-95F0-176717F32575@neustar.biz> To: "Rosen, Brian" X-Mailer: Apple Mail (2.1082) Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] ED-66 in -phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 20:53:02 -0000 Either one is OK with me if it's with the AD. --Richard=20 On Jul 28, 2011, at 4:26 PM, Rosen, Brian wrote: > Keith and I have been discussing this off list. We are down to >=20 >> Section?? Termination >>=20 >> This is an empty section to maintain alignment... >> ED-66 Void >=20 > or >=20 >> Section ?? Termination >>=20 >> ED-66 Do what 3261 says >=20 > This is a small issue of little impact. Keith doesn't like = meaningless requirements >=20 > Brian >=20 > 't Jul 28, 2011, at 3:56 PM, DRAGE, Keith (Keith) wrote: >=20 >> Why not just replace it with text that says: >>=20 >> "This is an empty section to maintain alignment of section numbering = with RFC XXXX" >>=20 >> Keith >>=20 >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf Of >>> Rosen, Brian >>> Sent: 28 July 2011 14:43 >>> To: ecrit@ietf.org Org >>> Subject: [Ecrit] ED-66 in -phonebcp >>>=20 >>> ED-66 is the "what happens if the BYE is lost" text in -phonbcp" = line. It >>> has a security hole, which is noted, but it generated a DISCUSS. = In >>> looking at the history of this, I believe it's a left over from the = called >>> party (PSAP) control discussion (PSAP control of disconnect). I = think we >>> should just delete the requirement. >>>=20 >>> I have an editorial problem with this deletion. It is the only >>> requirement in the section, and the sections of -phonebcp aligns = with the >>> sections of -framework, and there is some helpful text in -framework = on >>> termination. So, I ask for editorial license to replace the text of = ED-66 >>> with something that says termination MUST use the procedures in = RFC3261. >>> This is, of course, a no op. But it avoids renumbering, and avoids = either >>> an empty section or a mismatch of sections. >>>=20 >>> Brian >>> _______________________________________________ >>> 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 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From bidulock@openss7.org Thu Jul 28 16:38:58 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD9C11E80EF for ; Thu, 28 Jul 2011 16:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46PTbW-y0rpw for ; Thu, 28 Jul 2011 16:38:57 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [206.75.117.178]) by ietfa.amsl.com (Postfix) with ESMTP id 751A211E80C3 for ; Thu, 28 Jul 2011 16:38:56 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p6SNcqlv000750; Thu, 28 Jul 2011 17:38:52 -0600 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p6SNcpCu004399; Thu, 28 Jul 2011 17:38:51 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id p6SNcphG004398; Thu, 28 Jul 2011 17:38:51 -0600 Date: Thu, 28 Jul 2011 17:38:51 -0600 From: "Brian F. G. Bidulock" To: Paul Beaumont Message-ID: <20110728233851.GA28008@openss7.org> References: <8CC2315D-DAD1-4948-A014-FD36DC6BECE2@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8CC2315D-DAD1-4948-A014-FD36DC6BECE2@gmail.com> Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: IETF - ECRIT Subject: Re: [Ecrit] Emergency Call On-Hook / Off-Hook Indication during Manual Hold Over SIP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bidulock@openss7.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 23:38:58 -0000 Paul, See RFC 3398 Section 9 for SIP in the core network (SIP to ISUP interworking). This handles both ISUP terminal portability and the equivalent POTS-based suspend/resume. For SIP at the access device, there is not necessarily a hook-state, but if the UA wants to, it could use equivalent re-INVITE or UPDATE (RFC 3311) methods. The value to the PSAP is knowing why there is silence on the line. A decent UA should never disconnect a 911 call in the first place, and there is no need to disconnect the microphone and speakers regardless of any physical positioning of the handset. This is something that is only possible using metallic access in the PSTN. --brian On Thu, 28 Jul 2011, Paul Beaumont wrote: > All > > Apologies, being first time to IETF and its mailing lists, if this is > not the right mailing list to post this request to. > > There does not appear to be a standardised means using SIP on > emergency calls where B-Party Control [aka Manual Hold] to allow the > Emergency Service operator to have visibility of the A-Party [who > called 999/112/18000*] hook state. This is something that is supported > in circuit switched and is intrinsic to Emergency Service bureau > processes. To deal with young children playing with the phone, persons > dialling hoax calls, persons incapacitated during the call, etc. Today > this is done using SS7 ISUP SUSpend [on-hook cleared] and RESume > [off-hook reanswer]. One possibility, although not specifically > intended for this purpose - it's for ISDN Terminal Portability - is to > formalise use of P-Service-Notification of "user-suspended" and > "user-resumed" respectively between Service Provider platforms. > Currently the mechanism to achieve this capability is not consistent > between IP interconnected operators and also even in a SP's own > network where interworking between SIP on Inter Machine Trunk and > legacy SS7 ISUP InterConnect Trunks. > > Please can you advise where I should submit this question or if this > is the right forum then whether the above observation is correct and > any supplemental information/comments you may have? > > Thanks > Paul Beaumont > > * PS I do not know if this would also be true in NA with 911 and for > other nations beyond UK > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Brian F. G. Bidulock The reasonable man adapts himself to the bidulock@openss7.org world; the unreasonable one persists in http://www.openss7.org/ trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw From paulbeaumont.ietf@gmail.com Fri Jul 29 14:22:12 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F87421F8B3C for ; Fri, 29 Jul 2011 14:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZmkOMnIQWYb for ; Fri, 29 Jul 2011 14:22:11 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 944AA21F8B38 for ; Fri, 29 Jul 2011 14:22:11 -0700 (PDT) Received: by qyk9 with SMTP id 9so76778qyk.10 for ; Fri, 29 Jul 2011 14:22:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=pV1yhqgyJUXXbPePK/v+hKE0ettV8YCIe2+c/jlsjnA=; b=ft2qfKinAjWYSqHanbR8OHrhijxrGrhgUftNnlyCwKAnrJ7vbVb1lFVzafijVcDWGI iUAORprjHjkcHUK1Z//VgNOBPklF76pythFrIQAp9xQCIkn0wCrJRr7nGXm39209et+V L6Kwt1oNPtxpTj8BlHr52OU/nFSAZ9fV1MfFU= Received: by 10.224.192.137 with SMTP id dq9mr1348596qab.166.1311974530858; Fri, 29 Jul 2011 14:22:10 -0700 (PDT) Received: from [192.168.1.227] ([206.172.18.93]) by mx.google.com with ESMTPS id s14sm1650840qct.30.2011.07.29.14.22.09 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jul 2011 14:22:10 -0700 (PDT) References: <8CC2315D-DAD1-4948-A014-FD36DC6BECE2@gmail.com> <0FEAC1C09868B34A982F4FB40254B37C290158A9D2@MBX02.bell.corp.bce.ca> In-Reply-To: <0FEAC1C09868B34A982F4FB40254B37C290158A9D2@MBX02.bell.corp.bce.ca> Mime-Version: 1.0 (iPad Mail 8J2) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <30BEF302-6907-402E-860B-FB591F78086D@gmail.com> X-Mailer: iPad Mail (8J2) From: Paul Beaumont Date: Fri, 29 Jul 2011 22:22:56 +0100 To: "g.caron@bell.ca" Cc: IETF - ECRIT Subject: Re: [Ecrit] Emergency Call On-Hook / Off-Hook Indication during Manual Hold Over SIP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 21:22:12 -0000 Hi Guy Thank you for response. It is good to know that you like me have encountered= the issue. As you indicate having a standard mechanism for how this functio= n is implemented, as an adjunct to RFC3261, that can be cited to vendors an= d other carriers we interconnect with will remove the current ambiguity. Yes, as you surmised I am referring to the PSTN. In my case the issue arises= both on legacy access, where there is SIP interworking in the network, and N= GA, where there are SIP controlled ATA in the homes of users connected via FT= TH. Paul Beaumont -- On 28 Jul 2011, at 19:33, "g.caron@bell.ca" wrote: > Hi Paul, >=20 > This is an concept (not necessarily the mechanism) that I support as it is= definitively a requirement for some countries, notable in North America. I'= m certain you are referring to the PSTN only by way of example, not implying= to replicate how this functionality is implemented. >=20 > I do believe that having a STANDARD mechanism will be beneficial to avoid t= he vendor-specific, non-compatible approaches we have to deal with today. >=20 > Guy >=20 > -----Message d'origine----- > De : ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] De la part de P= aul Beaumont > Envoy=C3=A9 : 28 juillet 2011 14:21 > =C3=80 : IETF - ECRIT > Objet : [Ecrit] Emergency Call On-Hook / Off-Hook Indication during Manual= Hold Over SIP >=20 > All >=20 > Apologies, being first time to IETF and its mailing lists, if this is not t= he right mailing list to post this request to. >=20 > There does not appear to be a standardised means using SIP on emergency ca= lls where B-Party Control [aka Manual Hold] to allow the Emergency Service o= perator to have visibility of the A-Party [who called 999/112/18000*] hook s= tate. This is something that is supported in circuit switched and is intrins= ic to Emergency Service bureau processes. To deal with young children playin= g with the phone, persons dialling hoax calls, persons incapacitated during t= he call, etc. Today this is done using SS7 ISUP SUSpend [on-hook cleared] an= d RESume [off-hook reanswer]. One possibility, although not specifically int= ended for this purpose - it's for ISDN Terminal Portability - is to formalis= e use of P-Service-Notification of "user-suspended" and "user-resumed" respe= ctively between Service Provider platforms. Currently the mechanism to achie= ve this capability is not consistent between IP interconnected operators and= also even in a SP's own network where interworking between SIP on Inter Mac= hin > e Trunk and legacy SS7 ISUP InterConnect Trunks. >=20 > Please can you advise where I should submit this question or if this is th= e right forum then whether the above observation is correct and any suppleme= ntal information/comments you may have?=20 >=20 > Thanks > Paul Beaumont >=20 > * PS I do not know if this would also be true in NA with 911 and for other= nations beyond UK > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From paulbeaumont.ietf@gmail.com Sat Jul 30 03:30:56 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0E5821F8743 for ; Sat, 30 Jul 2011 03:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boYuQxMFkfSp for ; Sat, 30 Jul 2011 03:30:56 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id D5AAB21F8745 for ; Sat, 30 Jul 2011 03:30:55 -0700 (PDT) Received: by fxe6 with SMTP id 6so3478133fxe.31 for ; Sat, 30 Jul 2011 03:30:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:references:cc:from:content-type:in-reply-to:message-id:date :to:content-transfer-encoding:mime-version:x-mailer; bh=+DS9mIuOE1SJTebKsWS4ZtsUy7ItbBhqqhUlINwcE3A=; b=uRAAGuYEmZS8T30oX5E/yJV3R5AOhzx39PCSRGkBC/ZJXDnyEp/oUnGq329KxKXqiC JnxSpvIccu5voshKQ/JapNqd9SWXa2mjgPw22tYNIANcECsxp8MkVK/mXIpzlrV8jFYT unUu3oWnYHD4YPXghbniqXlcZlrg7O1iESHHM= Received: by 10.204.135.215 with SMTP id o23mr653560bkt.164.1312021853062; Sat, 30 Jul 2011 03:30:53 -0700 (PDT) Received: from [10.101.1.222] (static-93.158.79.70.got.public.icomera.com [93.158.79.70]) by mx.google.com with ESMTPS id sz1sm788266bkb.25.2011.07.30.03.30.50 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 30 Jul 2011 03:30:51 -0700 (PDT) References: <8CC2315D-DAD1-4948-A014-FD36DC6BECE2@gmail.com> From: Paul Beaumont Content-Type: text/plain; charset=us-ascii In-Reply-To: Message-Id: <99CEA96E-ADBD-40C6-B37A-C80B3B3C5542@gmail.com> Date: Sat, 30 Jul 2011 10:34:57 +0100 To: "Rosen, Brian" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (iPad Mail 8J2) X-Mailer: iPad Mail (8J2) Cc: IETF - ECRIT Subject: Re: [Ecrit] Emergency Call On-Hook / Off-Hook Indication during Manual Hold Over SIP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 10:30:57 -0000 Hi Brian Thank you for your response. As a result of my posting I am becoming aware of the background and my apolo= gies to the community for not doing more research on this before posting to t= he list. However, I do see this as being important and it would appear some others re= gards it as requiring a solution too. The fact that it keeps getting raised a= nd across both legacy and evolved service platforms affirms this. I would see any potential RFC as being an adjunct to base RFC3261 SIP. Wheth= er to apply depends on the policy of each network operator. An MNO may choos= e not to*, based on established precedence and scarcity of radio resource, w= hilst an FNO may choose to, based on established precedence and compliance o= f providing primary line telephony. I view the logical SDO body to do this a= s being IETF; for the reason you state. Whether the number and profile of the individual supporters/objectors concer= ned is sufficient to make the prospect of "rough consensus" likely I cannot c= omment on, being so new to IETF. Thanks Paul Beaumont * With VoLTE being based on SIP there is an opportunity, should they want to= , for MNOs to support Called Party Control of the call. -- On 28 Jul 2011, at 19:40, "Rosen, Brian" wrote: > If I'm following this, you are talking about the ability of the PSAP to co= ntrol termination of the call, and be able to detect hook state while the ca= ll is being held up by the PSAP. > This is a long running discussion. This requirement is very firm for some= members of the work group, but has very strong opposition. Some of those o= bjecting believe that the mechanism the PSTN uses is inappropriate, and the p= roblem that the PSTN solution addresses is better obtained with user interfa= ce changes on IP devices. Other objectors believe that it should not be pos= sible for the PSAP to hold the call because it may use too many resources in= a network, especially a mobile network. >=20 > We have had numerous conversations. We could not converge on a problem st= atement, requirements or solutions. =20 >=20 > Given the IETF consensus process, I personally don't see a way forward on t= his requirement, although if there were significantly more participants who c= ame to the conclusion that the requirement is important, and solutions must b= e found, that could change. There have been discussions of doing this work o= utside the IETF, but that would violate the SIP change process. =20 >=20 > Brian > On Jul 28, 2011, at 2:20 PM, Paul Beaumont wrote: >=20 >> All >>=20 >> Apologies, being first time to IETF and its mailing lists, if this is not= the right mailing list to post this request to. >>=20 >> There does not appear to be a standardised means using SIP on emergency c= alls where B-Party Control [aka Manual Hold] to allow the Emergency Service o= perator to have visibility of the A-Party [who called 999/112/18000*] hook s= tate. This is something that is supported in circuit switched and is intrins= ic to Emergency Service bureau processes. To deal with young children playin= g with the phone, persons dialling hoax calls, persons incapacitated during t= he call, etc. Today this is done using SS7 ISUP SUSpend [on-hook cleared] an= d RESume [off-hook reanswer]. One possibility, although not specifically int= ended for this purpose - it's for ISDN Terminal Portability - is to formalis= e use of P-Service-Notification of "user-suspended" and "user-resumed" respe= ctively between Service Provider platforms. Currently the mechanism to achie= ve this capability is not consistent between IP interconnected operators and= also even in a SP's own network where interworking between SIP on Inter Mac= hin >> e Trunk and legacy SS7 ISUP InterConnect Trunks. >>=20 >> Please can you advise where I should submit this question or if this is t= he right forum then whether the above observation is correct and any supplem= ental information/comments you may have?=20 >>=20 >> Thanks >> Paul Beaumont >>=20 >> * PS I do not know if this would also be true in NA with 911 and for othe= r nations beyond UK >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 From paulbeaumont.ietf@gmail.com Sat Jul 30 04:08:46 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73ACB21F8841 for ; Sat, 30 Jul 2011 04:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfxCZRU2Drk4 for ; Sat, 30 Jul 2011 04:08:43 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8C121F883A for ; Sat, 30 Jul 2011 04:08:43 -0700 (PDT) Received: by fxe6 with SMTP id 6so3501684fxe.31 for ; Sat, 30 Jul 2011 04:08:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=4SFPDTNj+0aCeaw+5PGXeNdN2kRaTmYy/ebt0c64PxM=; b=mcU3WNYQZKfiNZJNT6byfJhhkRJftZ+U1VVRYHMGiySqJSXKX/5TMzz6taBi7YiDOa HXr5oMj0+Fv2X/bvow16udiOrqjJKC8tzz4mHvlE68BLdv42oX/Ultk/rbiOeecFQ5WF H03e/TikwHHxCq7y4KMzoM46T88tx9RIhFx9A= Received: by 10.204.50.4 with SMTP id x4mr699120bkf.323.1312024122986; Sat, 30 Jul 2011 04:08:42 -0700 (PDT) Received: from [10.101.1.222] (static-93.158.79.70.got.public.icomera.com [93.158.79.70]) by mx.google.com with ESMTPS id d10sm794791bkt.27.2011.07.30.04.08.41 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 30 Jul 2011 04:08:42 -0700 (PDT) References: <8CC2315D-DAD1-4948-A014-FD36DC6BECE2@gmail.com> <20110728233851.GA28008@openss7.org> In-Reply-To: <20110728233851.GA28008@openss7.org> Mime-Version: 1.0 (iPad Mail 8J2) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <64322E72-03E8-4A92-B220-51BDF27CDBF7@gmail.com> X-Mailer: iPad Mail (8J2) From: Paul Beaumont Date: Sat, 30 Jul 2011 12:09:22 +0100 To: "bidulock@openss7.org" Cc: IETF - ECRIT Subject: Re: [Ecrit] Emergency Call On-Hook / Off-Hook Indication during Manual Hold Over SIP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 11:08:46 -0000 Brian Thank you for the explanation and RFC references. I will go have a read. Paul -- On 29 Jul 2011, at 00:38, "Brian F. G. Bidulock" wrot= e: > Paul, >=20 > See RFC 3398 Section 9 for SIP in the core network (SIP to ISUP > interworking). This handles both ISUP terminal portability and > the equivalent POTS-based suspend/resume. For SIP at the access device, > there is not necessarily a hook-state, but if the UA wants to, it could > use equivalent re-INVITE or UPDATE (RFC 3311) methods. >=20 > The value to the PSAP is knowing why there is silence on the line. A > decent UA should never disconnect a 911 call in the first place, and > there is no need to disconnect the microphone and speakers regardless of > any physical positioning of the handset. This is something that is > only possible using metallic access in the PSTN. >=20 > --brian >=20 > On Thu, 28 Jul 2011, Paul Beaumont wrote: >=20 >> All >>=20 >> Apologies, being first time to IETF and its mailing lists, if this is >> not the right mailing list to post this request to. >>=20 >> There does not appear to be a standardised means using SIP on >> emergency calls where B-Party Control [aka Manual Hold] to allow the >> Emergency Service operator to have visibility of the A-Party [who >> called 999/112/18000*] hook state. This is something that is supported >> in circuit switched and is intrinsic to Emergency Service bureau >> processes. To deal with young children playing with the phone, persons >> dialling hoax calls, persons incapacitated during the call, etc. Today >> this is done using SS7 ISUP SUSpend [on-hook cleared] and RESume >> [off-hook reanswer]. One possibility, although not specifically >> intended for this purpose - it's for ISDN Terminal Portability - is to >> formalise use of P-Service-Notification of "user-suspended" and >> "user-resumed" respectively between Service Provider platforms. >> Currently the mechanism to achieve this capability is not consistent >> between IP interconnected operators and also even in a SP's own >> network where interworking between SIP on Inter Machine Trunk and >> legacy SS7 ISUP InterConnect Trunks. >>=20 >> Please can you advise where I should submit this question or if this >> is the right forum then whether the above observation is correct and >> any supplemental information/comments you may have?=20 >>=20 >> Thanks >> Paul Beaumont >>=20 >> * PS I do not know if this would also be true in NA with 911 and for >> other nations beyond UK >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 > --=20 > Brian F. G. Bidulock =C2=A6 The reasonable man adapts himself to the =C2= =A6 > bidulock@openss7.org =C2=A6 world; the unreasonable one persists in =C2= =A6 > http://www.openss7.org/ =C2=A6 trying to adapt the world to himself. =C2= =A6 > =C2=A6 Therefore all progress depends on the =C2= =A6 > =C2=A6 unreasonable man. -- George Bernard Shaw =C2= =A6 From paulbeaumont.ietf@gmail.com Sat Jul 30 04:17:53 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8162121F8569 for ; Sat, 30 Jul 2011 04:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iy1E05tSiSed for ; Sat, 30 Jul 2011 04:17:53 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id AE3A921F8548 for ; Sat, 30 Jul 2011 04:17:52 -0700 (PDT) Received: by fxe6 with SMTP id 6so3507454fxe.31 for ; Sat, 30 Jul 2011 04:17:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=F723FqmDGj9adF9mMdNfSormcKDGf2rE1dVTxRNOcHo=; b=TYsiWUDJ997cfYJ5ouvshFWAb1Ir7yrGRQbeACZu3mq4CxivqQA73ZeeXPVq6HmUpi PQ5NtIk/23tgYbyNsVZf2SbtM1umQ0OfLQ7We4rDq+W5xZyZKHGZcWKsMvwDu3Wjiai8 jpENNGlsETlFPZLmyYGKhKoNJqE8eCtUTgr6Y= Received: by 10.204.143.2 with SMTP id s2mr490436bku.298.1312024670978; Sat, 30 Jul 2011 04:17:50 -0700 (PDT) Received: from [10.101.1.222] (static-93.158.79.70.got.public.icomera.com [93.158.79.70]) by mx.google.com with ESMTPS id g11sm796970bku.16.2011.07.30.04.17.49 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 30 Jul 2011 04:17:50 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (iPad Mail 8J2) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (8J2) From: Paul Beaumont Date: Sat, 30 Jul 2011 12:18:07 +0100 To: Marc Linsner Cc: IETF - ECRIT Subject: Re: [Ecrit] Emergency Call On-Hook / Off-Hook Indication during Manual Hold Over SIP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 11:17:53 -0000 Marc Many thanks for the link to the draft. I will go have a read of it. Paul -- On 28 Jul 2011, at 19:46, Marc Linsner wrote: > Paul, > > Feel free to review the draft submission at: > > http://tools.ietf.org/html/draft-rosen-ecrit-premature-disconnect-rqmts-02 > > You may also find message threads on the topic in the list archives in the > early 2009 timeframe. > > -Marc- > > -----Original Message----- > From: Paul Beaumont > Date: Thu, 28 Jul 2011 19:20:31 +0100 > To: IETF - ECRIT > Subject: [Ecrit] Emergency Call On-Hook / Off-Hook Indication during > Manual Hold Over SIP > >> All >> >> Apologies, being first time to IETF and its mailing lists, if this is not >> the right mailing list to post this request to. >> >> There does not appear to be a standardised means using SIP on emergency >> calls where B-Party Control [aka Manual Hold] to allow the Emergency >> Service operator to have visibility of the A-Party [who called >> 999/112/18000*] hook state. This is something that is supported in >> circuit switched and is intrinsic to Emergency Service bureau processes. >> To deal with young children playing with the phone, persons dialling hoax >> calls, persons incapacitated during the call, etc. Today this is done >> using SS7 ISUP SUSpend [on-hook cleared] and RESume [off-hook reanswer]. >> One possibility, although not specifically intended for this purpose - >> it's for ISDN Terminal Portability - is to formalise use of >> P-Service-Notification of "user-suspended" and "user-resumed" >> respectively between Service Provider platforms. Currently the mechanism >> to achieve this capability is not consistent between IP interconnected >> operators and also even in a SP's own network where interworking between >> SIP on Inter Machin >> e Trunk and legacy SS7 ISUP InterConnect Trunks. >> >> Please can you advise where I should submit this question or if this is >> the right forum then whether the above observation is correct and any >> supplemental information/comments you may have? >> >> Thanks >> Paul Beaumont >> >> * PS I do not know if this would also be true in NA with 911 and for >> other nations beyond UK >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > >