Re: [Ecrit] issues in draft-ietf-ecrit-data-only-ea-06 and draft-rosen-ecrit-addldata-subnot-00 (was RE: Question to draft-ietf-ecrit-data-only-ea-05)

Ivo Sedlacek <ivo.sedlacek@ericsson.com> Wed, 11 September 2013 11:49 UTC

Return-Path: <ivo.sedlacek@ericsson.com>
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 B15AA11E8197 for <ecrit@ietfa.amsl.com>; Wed, 11 Sep 2013 04:49:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.649
X-Spam-Level:
X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrZPg5Cv81i1 for <ecrit@ietfa.amsl.com>; Wed, 11 Sep 2013 04:49:14 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4786721E80B8 for <ecrit@ietf.org>; Wed, 11 Sep 2013 04:49:12 -0700 (PDT)
X-AuditID: c1b4fb30-b7f9a8e000005620-2e-523058b744a8
Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id A2.24.22048.7B850325; Wed, 11 Sep 2013 13:49:11 +0200 (CEST)
Received: from ESESSMB301.ericsson.se ([169.254.1.119]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0328.009; Wed, 11 Sep 2013 13:49:11 +0200
From: Ivo Sedlacek <ivo.sedlacek@ericsson.com>
To: Brian Rosen <br@brianrosen.net>
Thread-Topic: issues in draft-ietf-ecrit-data-only-ea-06 and draft-rosen-ecrit-addldata-subnot-00 (was RE: [Ecrit] Question to draft-ietf-ecrit-data-only-ea-05)
Thread-Index: AQHOg7VmdEODvcAym0aNkVJ0+Et/Y5nAwWfQ
Date: Wed, 11 Sep 2013 11:49:10 +0000
Message-ID: <39B5E4D390E9BD4890E2B3107900610113A826@ESESSMB301.ericsson.se>
References: <39B5E4D390E9BD4890E2B310790061010F7E49@ESESSMB301.ericsson.se> <670140B0-DC31-4922-82EF-45CAF73772F8@brianrosen.net>
In-Reply-To: <670140B0-DC31-4922-82EF-45CAF73772F8@brianrosen.net>
Accept-Language: en-US, cs-CZ
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.18]
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyM+Jvje72CIMgg63TLS2e3p/GZtG46Cmr A5PH/W9/2T2WLPnJFMAUxWWTkpqTWZZapG+XwJVxdNJhloLHlRXLdrazNzCuT+xi5OSQEDCR 6N7/jAXCFpO4cG89WxcjF4eQwGFGibVzPkE5Sxgljky8yQRSxSagJzFxyxFWEFtEQFli561O dhCbWUBV4lzjYxaQBmGBxYwSzc8esYM4IiDdn9veMkN0GEl0fuoC62YB6ug/9BtsN6+At8Tf 2bMYIdY1M0rsf3GTESTBKeAksfHPBzYQm1FAVuLqn15GiHXiEreezGeCOFxAYsme88wQtqjE y8f/WCFsRYmPr/ZB1etJPDs1iwXC1pZYtvA1M8RiQYmTM5+wTGAUm4Vk7CwkLbOQtMxC0rKA kWUVI3tuYmZOern5JkZgrBzc8ttgB+Om+2KHGKU5WJTEeTfrnQkUEkhPLEnNTk0tSC2KLyrN SS0+xMjEwSnVwGgp3GCrOJNFw32NK4vrfKljd25x+JiuvqG0e7PeQ3smqbBHfKZ1Hk9/Zu3n 4BS25OGTKY8xvXnnR9XlWbPMpRuO/N7pIPF3wSdfN7f5xv35NS8vrPolyuemwvLyvVj2q+Vz pC+8bXBvX6zTcDXun/PG3Su33+JZeS8lgUEiLp3HL2+unT37GyWW4oxEQy3mouJEACGaB+Bj AgAA
Cc: "ecrit@ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] issues in draft-ietf-ecrit-data-only-ea-06 and draft-rosen-ecrit-addldata-subnot-00 (was RE: Question to draft-ietf-ecrit-data-only-ea-05)
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ecrit>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Sep 2013 11:49:19 -0000

Hello Brian,

you stated below that you were going to note the limitations in ISSUE 1 and ISSUE 2 in the next edition of the draft.

Has this already been done? Thanks for clarification.

Kind regards

Ivo Sedlacek

This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer 

-----Original Message-----
From: Brian Rosen [mailto:br@brianrosen.net] 
Sent: 18. července 2013 14:51
To: Ivo Sedlacek
Cc: ecrit@ietf.org
Subject: Re: issues in draft-ietf-ecrit-data-only-ea-06 and draft-rosen-ecrit-addldata-subnot-00 (was RE: [Ecrit] Question to draft-ietf-ecrit-data-only-ea-05)

Hi Ivo

I will note this limitations in the next edition of the draft.

The working group can decide if they think they are more important than I think they are.  I will raise the issue when I discuss the draft in Berlin.

Brian

On Jul 18, 2013, at 3:12 AM, Ivo Sedlacek <ivo.sedlacek@ericsson.com> wrote:

> Hello Brian,
> 
> my conclusions of the discussion:
> 
> ISSUE 1:
> --------------------------
> if the UA and the PSAP wish to provide updates, the solution in the drafts requires UA to provide a URI which  PSAP uses to send out-of-dialog SUBSCRIBE request to the UA. This URI needs to be a globally routable URI. 
> Since UAs are normally behind SBG/firewall and do not have globally routable URI, this requires UA to be registered to get a globally routable URI. 
> If the UA does not have valid credentials, the registration will fail.
> 
> In contrast, INFO based solution would not suffer from this problem as everything is sent within dialog of emergency call.
> --------------------------	
> 
> PROPOSAL 1:
> --------------------------
> Record in the drafts that if the UA and the PSAP wish to provide updates, when the UA does not have a globally routable URI (e.g. due to not having valid credentials which would enable registration providing GRUU to the UA), then solution in the drafts does not work.
> --------------------------
> 
> 
> ISSUE 2:
> --------------------------
> The drafts do not solve how the UA is able to detect whether the subscriber is an authorized entity or man-in-the-middle intercepting the MESSAGE or the previous SUBSCRIBE. Roaming UAs (e.g. in cars) are not aware of identities of PSAPs or responders in visited country.
> 
> In contrast, INFO based solution would not suffer from this problem as everything is sent within dialog of emergency call.
> --------------------------	
> 
> PROPOSAL 2:
> --------------------------
> Record this security issue in the drafts.
> --------------------------
> 
> 
> On:
> 
>> What I'm proposing doesn't require trust between networks, it requires trust between the device that sent the alert and the PSAP or responders that get it. 
> 
> The UA, particularly UA roaming to a different country (common for UAs in cars), does not know the PSAP or responder identity.
> 
>> And will INFO pass through IMS networks? Or will it be blocked by those SBCs?
> 
> INFO is an in-dialog request. Moreover, it would be sent within an emergency call. It would be passed.
> 
>> SUBSCRIBE is like any other SIP transaction.  If you want to send them all the way through the same path, you can.  
>> I think that is more fragile, but you can do it.  
>> The PSAP sends the SUBSCRIBE to the visited network that sent it the alert, which sends it to any transit networks enroute to the home network that originated the alert.
> 
> The visited network does not provide globally routable URI to the UA. It is the registrar in the home network which provides GRUU during registration.
> 
> So, the SUBSCRIBE from PSAP will traverse: PSAP (African country) - network serving PSAP (African country) - transit network (any country) - home operator (US) - visited network (African country) - UA. 
> 
> In comparison, emergency requests sent by UA or exchanged in the 
> emergency dialogs initiated by UA will traverse: UA - visited network 
> (African country) - PSAP (African country)
> 
> In the latter case, it is much easier to ensure trust for the "this-is-sent-by-PSAP" information or resource priority as one regulatory body governs the whole signalling path. 
> 
> Kind regards
> 
> Ivo Sedlacek
> 
> This Communication is Confidential. We only send and receive email on 
> the basis of the terms set out at www.ericsson.com/email_disclaimer
> 
> 
> -----Original Message-----
> From: Brian Rosen [mailto:br@brianrosen.net]
> Sent: 17. července 2013 20:21
> To: Ivo Sedlacek
> Cc: ecrit@ietf.org
> Subject: Re: [Ecrit] Question to draft-ietf-ecrit-data-only-ea-05
> 
> Hi Ivo
> 
> See inline.
> 
> On Jul 17, 2013, at 11:13 AM, Ivo Sedlacek <ivo.sedlacek@ericsson.com> wrote:
> 
>> please see below. Kind regards Ivo Sedlacek
>> 
>> This Communication is Confidential. We only send and receive email on 
>> the basis of the terms set out at www.ericsson.com/email_disclaimer
>> 
>>>>>> Issue 1: If SUBSCRIBE/NOTIFY mechanism is used, the PSAP is the subscriber and the UA is the notifier, this would require reachability of UA for initial request for dialog (i.e. SUBSCRIBE). However, when the UA is not registered e.g. due to missing credentials, the UA is normally not reachable for SIP requests other than those sent within the dialog of the emergency call.
>>>>> 
>>>>> I think the combination of missing credentials, and data updates is so unlikely that the problem of PSAP control of updates dwarfs it.
>> 
>> The issue above was related to UA not being reachable for incoming requests due to __UA__ not having its credentials. 
>> 
>> Networks (like 3GPP IMS) enable UA without valid credentials to only send emergency requests and requests sent within dialogs created by emergency request. 
>> To receive requests sent outside of dialog created by emergency requests, the UA needs to be registered.
>> To be registered, the UA needs to have valid credentials.
> I misunderstood
>> 
>> Note that some countries require UAs to be able to make voice emergency call even if the UA does not valid credentials. 
> Yeah, but none of them require devices to be able to send data updates if they are not registered.
> 
>> 
>> Why should that be not be required as well for data only emergency requests?
> Personal opinion - because it's a DDoS attack opening towards a PSAP.  I would prohibit it.  All the PSAPs I am in discussion with are afraid of such problems.    As an example, in the U.S., in most cases, alarm systems are not permitted to connect directly to a PSAP - they must connect through a "Central Alarm Monitoring" service.  We hope to change that, but only if we can guarantee that the PSAP is protected, and they believe they are protected.
> 
>> 
>>> Because PSAPs will have credentials, and most sensor based devices where it's the device making the call don't update fast enough to be interesting.  I also think in most cases, devices will publish to a server, and the server will send the alert.
>> 
>> The above describes some particular architecture where SIP and non SIP signalling is mixed, or perhaps server acts as SIP B2BUA, not sure. Which entity is the SIP UA - the "server" or the "device" or both?
> The above assumes the device is registered to a service that aids it.  Most devices that have this kind of capability do that, but not all.
> If there is a service, the service has a server, the UA publishes updates to the server, the PSAP subscribes to the server.
> 
> If there is no service, the device UA is the server, and the PSAP subscribes to it.
> 
>> 
>> Why would the UA not be able to provide updates fast enough? Even if the UAs are not able to do it today, why shouldn't they be able to do it in future?
> Not a matter of able to, it's just that the data on such devices doesn't change enough over the course of a call to be interesting.  Once a car crashes, it has crash data, but it doesn't change.  If a fire starts, the fire could go out on it's own, but usually the fire brigade goes out anyway - updates aren't interesting.
> 
> Same with burglar alarms.
> 
> It's only a device like a heart monitor that would have updates that would be interesting, but in my experience, such devices have services that interpret the raw data from the sensor into more useful data for responders.
> 
> 
>> 
>>>> If PSAP accepts unauthenticated one short emergency requests, the PSAP will likely be interested in any data updates which the UA is able to provide. E.g. fire detection sensor could provide updates of the temperature in the building.
>>> Poor example.  The way we intend to determine temperatures in a building is the "additional location data" mechanism, which would probably (no details have been worked out yet) have a portal access to the building control system.
>> 
>> Abstract of draft-ietf-ecrit-data-only-ea-06 states: 
>> 
>> Examples of such environments include a  __temperature sensors 
>> issuing alerts__, or vehicles sending crash data.
> I can change the example.  Issuing the alert is one thing, monitoring the HVAC system is another.
> 
>> 
>> Is the Abstract is wrong?
> It's just that a typical building has a wide variety of sensors and actuators that are of interest to a responder.  A good example is the state of the water system or the air handing equipment, the elevators and the door sensors.  None of those are the ones that trigger the alert.  We're thinking about a portal to the building monitoring system that let's a responder connect to the portal and get all the data, and maybe even control aspects of it, if building management lets them.
> 
> You also typically have more than one call about an incident, and you need the same data whether you got a data-only alert or a telephone call.
> 
>> 
>>> The usual case where it is a device that has updates is that it uses the credentials of the PSAP to allow subscription.  Since the URL is something it supplies, it can include a token, good for a small window around the MESSAGE it sends.  
>> 
>> The UA normally do not know the identity of the PSAP and cannot authenticate PSAP. This was discussed quite a lot in draft-ietf-ecrit-psap-callback. The result is that just indication is provided and UA needs to rely on network to assert it. 
>> 
>>> We want to ALLOW direct from the device messages, and we have a way to do that.  A way the PSAP controls, which I think is important.
>> 
>> I understand the PSAP control is wished. This could be provided in INFO package mechanism as well.
>> 
>>> If the UA doesn't intend to provide updates, it doesn't offer a SUBSCRIBE URI.  If one is offered, and the PSAP wants updates, it will subscribe.
>> 
>> The point is that UA may be able and may want to allow PSAP to request the updates in every single request. 
>> Similarly, PSAP may want to decide that it wants the updates for every single request. 
>> If this is the most common case, the MESSAGE + SUBSCRIBE/NOTIFY is suboptimal.
> First of all, I think this is an uncommon case.  The common cases I know about have a service and it's not the device that the emergency authorities connect to.
> 
> Second of all, the MESSAGE goes to the PSAP, which usually only cares about dispatching a responder.  It is the responder who cares about the data after that.  Updates nearly always are of interest to responders and not PSAPs.  By sending a URI, we allow the responder to subscribe, not just the PSAP.  If we create a session, it's with the PSAP, not the responder.  We would have to transfer the session to the responder.
> 
>> 
>>> For one thing devices that do this tend to move.  MESSAGE does not create a session.  Sending updates requires a session where the routing wouldn't change within the session.  You can't send individual MESSAGE transactions, because each one may route differently.  That means we would need for the initial alert to be in an INVITE, create a session with no media, then send INFOs.  Not a whole lot different.
>> 
>> Updates sent using subscription will require dialog as well so there is really no difference related to UE movement.
> Agree, no difference.  But we have a mechanism much better suited to asynchronous notification in SUB/NOT vs INVITE/INFO.
> 
>> 
>> IMO, the solution using INVITE (containing the 1st shot) followed by INFOs would be simpler and (in comparision to MESSAGE+SUBSCRIBE/NOTIFY solution):
>> 1) would enable updates sent by UA without credentials
>> 2) would not need to rely on trust between networks to preserve information that SUBSCRIBE is sent by PSAP.
> As above, I don't think allowing devices without credentials to send alerts is a good idea at all.  I would prohibit it.
> What I'm proposing doesn't require trust between networks, it requires trust between the device that sent the alert and the PSAP or responders that get it.  MITM is an issue if the signaling is observable however.
> 
>> 
>> 
>>>> Thus the risk of missing trust between the networks is high - e.g. when UA with US subscription is an african country, sends emergency request to african PSAP, will the US home network of the UA trust the african network claiming that SUBSCRIBE comes from PSAP?
>>> No network is involved.  The question you are asking is will a US device visiting Africa trust an African PSAP.  When the MESSAGE is sent the URI for the subscribe is that of the device, not the home or visited network of the device.
>> 
>> 1) In normal SIP environment (like 3GPP IMS), PSAP will need to involve some network to reach UA. If UA includes IP address and port in the URI included in the MESSAGE, and PSAP sends SUBSCRIBE directly to that IP address and port, the SUBSCRIBE will likely be blocked by a firewall/SBC.
> And will INFO pass through IMS networks? Or will it be blocked by those SBCs?
> 
>> 
>> 2) US device trusts that the emergency message/call is delivered to african PSAP since the UA set the Request-URI to the emergency URN. But when SUBSCRIBE is received, how does the UA know that that SUBSCRIBE was really sent by PSAP and not by malicious UE? Normally, the UA trusts its home network to assert this, and its home network trusts the transit networks, and the transit networks checks that message comes from PSAP. So, there is chain of trust which is however difficult to achive if several countries are involved.
> SUBSCRIBE is like any other SIP transaction.  If you want to send them all the way through the same path, you can.  I think that is more fragile, but you can do it.  The PSAP sends the SUBSCRIBE to the visited network that sent it the alert, which sends it to any transit networks enroute to the home network that originated the alert.
> 
>> 
>>> So you propose to recreate RFC6446 and 6447 in an INFO package?
>> 
>> Not sure if all of that is needed, but possibly. 
> It would be necessary I think.
> 
>