Subject: Re: [Ecrit] Question to draft-ietf-ecrit-data-only-ea-05

From: Ivo Sedlacek <[email-masked]>
Date: Mon, 15 Jul 2013 11:23:09 +0000

Any comments to the issues 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 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ivo Sedlacek
Sent: 26. června 2013 8:26
To: [email-masked]
Subject: [Ecrit] Question to draft-ietf-ecrit-data-only-ea-05

Hello,

draft-ietf-ecrit-data-only-ea-05 states:

   This document does not define a mechanism for updates to the data
   contained in data-only emergency calls.

Is there another I-D describing how to provide the updates of the data to the PSAP? I saw some post suggesting that a SUBSCRIBE/NOTIFY mechanism could be used where the PSAP is subscriber and the UA is notifier, however I have not found such draft.

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.

Issue 2: How to send the update of the data __triggered by the UA__? Do we assume that if the PSAP subscription is not available, the PSAP prevents the UE from sending further information?
            If so, assuming PSAP is interested in any information available, PSAP will need to subscribe in every single case of MESSAGE with CAP where UA can potentially provide the update of the data.
            If not, do we assume that the UE would send updates of data triggered by UE using other mechanism (MESSAGE?) than updates of data requested by PSAP (NOTIFY)?

Issue 3: In some architectures (like 3GPP), signalling path for inital request for dialog from the PSAP to the UA is different than signalling path for the emergency request from the UA to the PSAP. If the UA has subscription from network in country X and roams in country Y, there is likelyhood that information that request comes from the PSAP is lost due to missing trust among PSAP (in country Y), transit networks (in country Y and X and possibly other transit countries), network of registrar and proxy of the UA (in country X), transit networks (in country X and Y and possibly other transit countries) and network of edge proxy serving the UA (in country Y) . If so, the UA would then handle the inital request for dialog as coming from an attacker UE and possibly reject it.

Is draft-ietf-ecrit-data-only-ea-05 supposed to be a  base for future solution where updates of the data to the PSAP are sent? I do not think it would work due to issues above.

If the UA ever wants to provide the updates of the data to the PSAP, either triggred by the UA or requested by the PSAP, it would be better to establish a dialog from beginning, e.g. send the initial data in INVITE and updates (from UE) and requests for updates (from PSAP) in INFOs.

Kind regards

Ivo Sedlacek 

Ericsson
Mobile +420 608 234 709
[email-masked]
www.ericsson.com 

This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer _______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 15 Jul 2013 13:44:01 +0200

Hi Ivo, 

sorry for the delay and for the quick response. A more detailed response will follow tomorrow. 

We have worked on a subscribe/notify document (that also works with this document) in the past and the initial plan was to go through it in ATOCA (because it was perceived to be  the fastest route). Obviously that did not turn out to be correct. 

Maybe we should consider it in this working group. 

Here is the document: 
http://tools.ietf.org/html/draft-rosen-sipping-cap-04

We would be happy to get help (=co-authorship) from you (or anymore else) to progress the document. 

Ciao
Hannes

On Jul 15, 2013, at 1:23 PM, Ivo Sedlacek wrote:

> _______________________________________________
> Ecrit mailing list
> [email-masked]

---

From: Brian Rosen <[email-masked]>
Date: Mon, 15 Jul 2013 08:52:15 -0400

See comments inline

> 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…
I think the combination of missing credentials, and data updates is so unlikely that the problem of PSAP control of updates dwarfs it.
I think that in many cases where the DEVICE as a opposed to a  service supplies updates, it will employ a server somewhere and publish its updates to the server, which can allow PSAP subscriptions.  That's primarily because the device doesn't want or need much mechanism.  I probably should mention that idea in the draft.

>             If not, do we assume that the UE would send updates of data triggered by UE using other mechanism (MESSAGE?) than updates of data requested by PSAP (NOTIFY)?
The source is the server (unless a device uses another server, see above).  Updates will always be triggered by the source.  The destination (PSAP) can ask for filtering, but updates would not be sent unless the source wanted to send one.

The mechanism the draft I created included an explicit mechanism to tell the PSAP that updates may be available.  If the source won't update, then it would not send the URI for subscriptions.  The PSAP can then decide if it wants to subscribe.  It would have, at most, as many subscriptions as it can handle calls (one per call taker).

> Issue 3: In some architectures (like 3GPP), signalling path for inital request for dialog from the PSAP to the UA is different than signalling path for the emergency request from the UA to the PSAP…
In such circumstances, you INCREASE the probability of success by requesting the PSAP contact the device without any of the networks in the path (possibly other than the home network).

The request is coming to a URI that is contained in the outgoing message, which is supposed to be protected the entire path with TLS (to avoid observation).  The attacker would have to be in the path of the call to get the URI, unless it's guessable.  This isn't very strong security, but it's something.

PSAPs have credentials, and the device or server can check them.

> If the UA ever wants to provide the updates of the data to the PSAP, either triggred by the UA or requested by the PSAP, it would be better to establish a dialog from beginning, e.g. send the initi…
I don't think it is acceptable to have the device in control of the rate of updates, which is the entire reason I suggest using SUBSCRIBE.  Unless we recreate the entire filtering mechanism, I don't think in-band updates work.

Brian

---

From: Brian Rosen <[email-masked]>
Date: Mon, 15 Jul 2013 08:54:54 -0400

> http://tools.ietf.org/html/draft-rosen-ecrit-addldata-subnot-00
Simpler, more direct update (sends the blocks in the same way that the original source did.

Using CAP for updates isn't particularly helpful - none of the CAP information is useful.  All you want is the blocks that were in the original INVITE/MESSAGE with updated content.

Brian

On Jul 15, 2013, at 7:44 AM, Hannes Tschofenig <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> Hi Ivo, 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> 
> iQEcBAEBCgAGBQJR4+CCAAoJEGhJURNOOiAt50IH/1r04pjqikpsvo+Mb7uExHWJ
> dM4zjOWZarOLyhglCcXddCi5EgaeIJ0myYhtc2qcJ9aCHqs7m5c5pfn0M9EZogUO
> PHd0uT4d4a5aXr0eBFhva6W4t4j/aLGHBiVrpakX3hIveVYBfKNnwC1yMxgO1BUs
> otCOmFjnEcykLe8ko6JRVRrHR7vEtYGltMR8IierpHap8C5zkXDB+NpdinCKNkeO
> wHJZ72HD2sQi9qHYCI/VvgyMxkrCg05BvspixEkA4cIUL5lqeR4VIgENngofJ76f
> Ub6mwtRgFNORRI3Tw2GJsM3RRg0zxrCh5Iv98DOmxsCeL6JdtSGYkLxm0Nj3qCU=
> =FcHc
> -----END PGP SIGNATURE-----

---

From: Ivo Sedlacek <[email-masked]>
Date: Wed, 17 Jul 2013 09:51:19 +0000

See comments inline. Kind regards Ivo Sedlacek

> I think the combination of missing credentials, and data updates is so unlikely that the problem of PSAP control of updates dwarfs it.

Why do you believe it is unlikely?

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.

> I think that in many cases where the DEVICE as a opposed to a  service supplies updates, it will employ a server somewhere and publish its updates to the server, which can allow PSAP subscriptions.…

Lost on what this means. I thought we are discussing UA providing data only emergency request to PSAP.

> The mechanism the draft I created included an explicit mechanism to tell the PSAP that updates may be available.  If the source won't update, then it would not send the URI for subscriptions.  The…

So, if updates are possible, PSAP would be required to subscribe whenever UA is able to provide the updates (even if the UA will not provide any updates at the end). Right?

UA ----> MESSAGE ---> PSAP

UA <---- 2xx for MESSAGE <--- PSAP

if PSAP is interested in updates (very likely):

UA <---- SUBSCRIBE <--- PSAP

UA ----> 2xx for SUBSCRIBE ---> PSAP

UA ----> NOTIFY (initial) ---> PSAP

UA <---- 2xx for NOTIFY <--- PSAP

if update is to be sent:

UA ----> NOTIFY (with update) ---> PSAP

UA <---- 2xx for NOTIFY <--- PSAP

when subscription expires:

UA ----> NOTIFY (final) ---> PSAP

UA <---- 2xx for NOTIFY <--- PSAP

IMO, this is suboptimal.

For single shot, the MESSAGE based mechanism is OK.

Whenever updates are possible, MESSAGE together with SUBSCRIBE/NOTIFY from PSAP to UA is rather bad as it requires additional messages to set up subscription which may not be used at the end for any update.

So, it boils down to - do we expect the UAs will be able to provide updates often or rarely?

> PSAPs have credentials, and the device or server can check them.

The issue was about trust between countries and MESSAGE going via a lot more networks and more countries than pure dialog of the emergency call.

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?

> I don't think it is acceptable to have the device in control of the rate of updates, which is the entire reason I suggest using SUBSCRIBE.  Unless we recreate the entire filtering mechanism, I don'…

The rate of the updates could be controlled by the INFO package parameters or by the information exchanged by the INFOs.

---

From: Brian Rosen <[email-masked]>
Date: Wed, 17 Jul 2013 09:35:56 -0400

Responses inline
On Jul 17, 2013, at 5:51 AM, Ivo Sedlacek <[email-masked]> wrote:

> This Communication is Confidential. We only send and receive email on the basis of the terms set out atwww.ericsson.com/email_disclaimer
>  
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.

> 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 update…
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.

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.  
> Lost on what this means. I thought we are discussing UA providing data only emergency request to PSAP.
Nearly every device I know about that would do this has some associated service.  The device itself doesn't do all the work, there is a service involved.  Maintaining 
state, verifying credentials, etc requires work.  Usually, the device offloads this to a service.  So the device publishes it's sensor data to the service and the service provides the emergency message and updates.

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.

> So, if updates are possible, PSAP would be required to subscribe whenever UA is able to provide the updates (even if the UA will not provide any updates at the end). Right?
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.

> So, it boils down to - do we expect the UAs will be able to provide updates often or rarely?
You seem to think there is a substantially simpler way.  There isn't.

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.
> 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 tr…
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.

> The rate of the updates could be controlled by the INFO package parameters or by the information exchanged by the INFOs.
So you propose to recreate RFC6446 and 6447 in an INFO package?

---

From: Ivo Sedlacek <[email-masked]>
Date: Wed, 17 Jul 2013 15:13:57 +0000

please see below. Kind regards Ivo Sedlacek

> > > 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.

Note that some countries require UAs to be able to make voice emergency call even if the UA does not valid credentials. 

Why should that be not be required as well for data only emergency requests?

> 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 publis…

 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?

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?
 
> 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…

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.

Is the Abstract is wrong?

> 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 s…

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.
 
> 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 indivi…

Updates sent using subscription will require dialog as well so there is really no difference related to UE movement.

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.

> 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 ho…

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.

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.
 
> So you propose to recreate RFC6446 and 6447 in an INFO package?

Not sure if all of that is needed, but possibly.

---

From: Brian Rosen <[email-masked]>
Date: Wed, 17 Jul 2013 14:20:48 -0400

Hi Ivo

See inline.

> 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.

> 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"…
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.

>   __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.

> 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.

> 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.

> 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.

> 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 dir…
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 tha…
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.

> Not sure if all of that is needed, but possibly. 
It would be necessary I think.