Subject: Re: [Ecrit] Ben Campbell's Yes on draft-ietf-ecrit-additional-data-34: (with COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Fri, 02 Oct 2015 16:38:30 -0500

Oops, I just ran across this going back over old messages. I don't think 
I responded; apologies for that. Comments inline. I deleted sections 
that don't seem to need further discussion.

Thanks!

Ben.

On 13 Sep 2015, at 18:51, Randall Gellens wrote:

[...]

>>>
>> [Edit: I asked a question below about what happens if you dereference 
>> a
>> block, and find the URL points to something other than what you 
>> expected.
>> On reflection, I should expand that  to ask how dereferencing errors
>> should be handled in general.]
>
> In general, since this is an emergency call, we want the call to go 
> through even if there are errors.  It's better that the call go 
> through with some data blocks missing or unusable than for the call to 
> fail.

That makes sense--is there any text that says that? If not, it might be 
worth adding.

[...]

>>> This draft implicitly assumes that the emergency calls are signaled 
>>> with
>> SIP. I don't dispute that assumption, but I think it should it's 
>> worth a
>> paragraph stating it explicitly.
>
> The Introduction says:
>
> This document extends the basic set of data communicated with an IP-
> based emergency call, as described in [RFC6443] and [RFC6881]
>
> Both those RFCs are explicitly SIP-based.  However, I'd be happy to 
> change the text from "IP-based" to "SIP-based" if people feel it would 
> add clarity.  E.g., to:
>
> This document extends the basic set of data communicated with a SIP-
> based emergency call, as described in [RFC6443] and [RFC6881]
>
> Or perhaps to:
>
> This document extends the basic set of data communicated with a
> Session Initiation Protocol (SIP) based emergency call, as
> described in [RFC6443] and [RFC6881]
>
> Let me know if you feel this change would be helpful.

I think the second version would be helpful.

[...]

>
>> -- 3:
>> Is there a critical need for the bit about "certain private-use
>> situations"? That seems like license for abuse, without more 
>> elaboration
>> about "prexisting relationship" and "privacy issues addressed".
>
> The reason for that text is to permit re-use of the mechanisms within 
> private telematics calls between a vehicle and a telematics service 
> center (which in turn simplifies the use of the mechanisms when such 
> calls are emergency calls from the telematics service center to a 
> PSAP).  The text appears as an exception to a ban on using the 
> mechanisms outside of an emergency call, so without it, such use would 
> be violating the RFC.  I thought the text was pretty restrictive, 
> since it says:
>
> certain private-use situations where the endpoints
> have a preexisting relationship and privacy issues are addressed
> within the relationship or do not apply because of it
>
> If you still feel this text is a "license for abuse" I'd be open to 
> tightening it, but it seems pretty limited to me.

Thanks for the explanation. I can live with what's there.

[...]

>
>> -- 4.1.5:
>> Do you intend 24x7 support to be a prerequisite to be a data
>> provider?
>
> It's not within scope of the IETF to make this requirement, but the 
> expectation is that calls will be processed by mainstream providers 
> who have 24/7 support for PSAPs.

The descriptions says "...information MUST be a URI to a 24/7 support 
organization..." That sounds like the IETF is making the requirement.

I'd be happy to have a non-normative statement that this is expected by 
the community to be a 24/7 support organization, but the MUST doesn't 
seem to fit.

>> Also, it seems like there are vcard fields that are not useful to 
>> this
>> purpose and might still have privacy implications. Do we really need
>> people
>> to send everything?
>
> The text does not mandate which fields to send.  It encourages sending 
> all fields because there are some unusual circumstances where a 
> seemingly irrelevant field might be useful to a call-taker (e.g., 
> anniversary might conceivably be useful with a suicidal caller) and 
> suggests a minimum set.

I think there needs to be a balance between "conceivably useful" and 
"likely to be privacy-sensitive". But IIRC, this discussion is happening 
separately, isn't it?

[...]

>> -- 5, list item 1: "The "purpose" parameter also indicates the kind 
>> of
>> data
>> (by its MIME subtype) that is available at the URI"
>> What happens if the URL points to something other than the indicated
>> thing?
>
> Then the PSAP doesn't get what it expects, and likely will ignore the 
> retrieved data, and the call will be processed as if the block wasn't 
> provided at all.  The PSAP will likely file a discrepancy report with 
> the provider, which is done out of band.  If the information in the 
> block is potentially urgent for handling the call, the call-taker or a 
> supervisor might contact the provider's PSAP support line.

That's probably fine, although I wonder if there might be room for 
guidance that the PSAP shouldn't just load arbitrary data if it gets 
something unexpected.

[...]
>> -- 8:
>> It might be worth discussing the potential harm done by a malicious
>> proxy
>> modifying a data element, or a compromised data source return 
>> incorrect
>> information when dereferencing a URL.
>
> If an element in the call path is compromised and under the control of 
> an attacker, it can wreak havoc, but this is generally true for any 
> system that isn't using end-to-end protection, and even then is true 
> if an endpoint is compromised.  I'm not sure what would be helpful to 
> say about this in the Security Considerations section.

I'm not going to push the point--but keep in mind the "compromised data 
source" case involves something _not_ in the call path.

[...]

---

From: Gunnar Hellström <[email-masked]>
Date: Sat, 3 Oct 2015 14:10:23 +0200

A comment on the 24/7 discussion on section 4.1.5:
Relay services are supposed to be data providers.
Sadly, the deployment of relay services is very slow in some regions, 
and if they exist, they often operate limited hours.
This is of course a problem when making emergency calls, but the wording 
in 4.1.5 should not discourage relay services from registering and 
providing data because they currently have limited opening hours.
----------------
Another issue around relay services: It would be good to get a URI that 
can be used for bridging in the relay service together with a call-back. 
This is because the relay service might have been invoked in a way so 
that the call-back address to the original caller does not automatically 
invoke the relay service. None of the provided data seem to specify that 
kind of URI.
----------------

/Gunnar Hellstrom

Den 2015-10-02 kl. 23:38, skrev Ben Campbell:
> Oops, I just ran across this going back over old messages. I don't 
> think I responded; apologies for that. Comments inline. I deleted 
> sections that don't seem to need further discussion.
>
> Thanks!
>
> Ben.
>
>>> [Edit: I asked a question below about what happens if you dereference a
>> through with some data blocks missing or unusable than for the call 
>> to fail.
>
> That makes sense--is there any text that says that? If not, it might 
> be worth adding.
>
> [...]
>
>> change the text from "IP-based" to "SIP-based" if people feel it 
>> would add clarity.  E.g., to:
>>
>> mechanisms outside of an emergency call, so without it, such use 
>> would be violating the RFC.  I thought the text was pretty 
>> restrictive, since it says:
>>
> I'd be happy to have a non-normative statement that this is expected 
> by the community to be a 24/7 support organization, but the MUST 
> doesn't seem to fit.
>
>>> Also, it seems like there are vcard fields that are not useful to this
>> The text does not mandate which fields to send.  It encourages 
>> sending all fields because there are some unusual circumstances where 
>> a seemingly irrelevant field might be useful to a call-taker (e.g., 
> "likely to be privacy-sensitive". But IIRC, this discussion is 
> happening separately, isn't it?
>
> [...]
>
>>> -- 5, list item 1: "The "purpose" parameter also indicates the kind of
>>> data
>> block is potentially urgent for handling the call, the call-taker or 
>> a supervisor might contact the provider's PSAP support line.
>
>>> modifying a data element, or a compromised data source return incorrect
>> If an element in the call path is compromised and under the control 
>> of an attacker, it can wreak havoc, but this is generally true for 
>> any system that isn't using end-to-end protection, and even then is 
>> true if an endpoint is compromised.  I'm not sure what would be 
>> helpful to say about this in the Security Considerations section.
>
> I'm not going to push the point--but keep in mind the "compromised 
> data source" case involves something _not_ in the call path.
>
> [...]
>
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 3 Oct 2015 14:51:46 -0400

> providing data because they currently have limited opening hours.

If the relay service was included in such a way that callbacks don't 
bring it back in, then having the URL of the relay service won't 
necessarily mean that the entity doing the callback will be authorized 
to obtain relay services on the callback call.

I don't see a good way to solve that except for the relay service to be 
authorized based on whichever end of the call desires/needs the relay 
service.

	Thanks,
	Paul

---

From: Gunnar Hellström <[email-masked]>
Date: Sat, 3 Oct 2015 23:58:07 +0200

Den 2015-10-03 kl. 20:51, skrev Paul Kyzivat:
> I don't see a good way to solve that except for the relay service to 
> be authorized based on whichever end of the call desires/needs the 
> relay service.
Yes, that would be included in a recommendation for how to use a URL 
field in Additional-Data.
A region could have requirements that the relay services who are 
registered as data providers also authorize calls from the region.
But it would be equally good if you can propose another field to convey 
such an URL in. It does not seem to be the intention of Additional-Data 
to provide operational information.

---

From: Randall Gellens <[email-masked]>
Date: Sun, 4 Oct 2015 14:12:10 -0700

Hi Ben,

At 4:38 PM -0500 10/2/15, Ben Campbell wrote:

>>>  block, and find the URL points to something other than what you expected.
>>  In general, since this is an emergency call, we want the call to 
>> go through even if there are errors.  It's better that the call go 
>> through with some data blocks missing or unusable than for the 
>> call to fail.
>
>  That makes sense--is there any text that says that? If not, it 
> might be worth adding.

Seems reasonable.  I added the following at the end of Section 6 
(which introduces the transport mechanisms):

    Note that, as with any mechanism, failures are possible.  For
    example, a block (provided by value or by reference) might not be the
    type indicated by the "purpose" parameter, or might be badly formed,
    etc.  The general principle that applies to emergency calls is that
    it is more important for the call to go through than for for
    everything to be correct.  Thus, most PSAPs will process a call if at
    all possible, even if data is missing or other failures occur.

>
>  [...]
>
>>>>  This draft implicitly assumes that the emergency calls are signaled with
>>>  SIP. I don't dispute that assumption, but I think it should it's worth a
>>  Both those RFCs are explicitly SIP-based.  However, I'd be happy 
>> to change the text from "IP-based" to "SIP-based" if people feel 
>> it would add clarity.  E.g., to:
>>

OK, added.

...

>>  It's not within scope of the IETF to make this requirement, but 
>> the expectation is that calls will be processed by mainstream 
>> providers who have 24/7 support for PSAPs.
>
>
>  The descriptions says "...information MUST be a URI to a 24/7 
> support organization..." That sounds like the IETF is making the 
> requirement.
>
>  I'd be happy to have a non-normative statement that this is 
> expected by the community to be a 24/7 support organization, but 
> the MUST doesn't seem to fit.

I changed the "MUST" to "is expected to be".

...

>>  Then the PSAP doesn't get what it expects, and likely will ignore 
>> the retrieved data, and the call will be processed as if the block 
>> wasn't provided at all.  The PSAP will likely file a discrepancy 
>> report with the provider, which is done out of band.  If the 
>> information in the block is potentially urgent for handling the 
>> call, the call-taker or a supervisor might contact the provider's 
>> PSAP support line.
>
> guidance that the PSAP shouldn't just load arbitrary data if it 
> gets something unexpected.

The document already says

        A PSAP or emergency responder is able to examine the
        type of data provided and selectively access the data it is
        interested in

I think that makes the point that PSAPs will only access the data 
they decide they want, and hence, if data turns out to be of a 
different type, they will likely ignore it.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Vital papers will demonstrate their vitality by spontaneously moving
from where you left them to where you can't find them.

---

From: Randall Gellens <[email-masked]>
Date: Sun, 4 Oct 2015 14:14:33 -0700

Hi Gunnar,

At 2:10 PM +0200 10/3/15, Gunnar Hellström wrote:

>  Sadly, the deployment of relay services is very 
> slow in some regions, and if they exist, they 
> often operate limited hours.
>  This is of course a problem when making 
> emergency calls, but the wording in 4.1.5 
> should not discourage relay services from 
> registering and providing data because they 
> currently have limited opening hours.

The text in question says "When provided by a 
service provider or an access network provider" 
so I think small relay operations are OK, and 
anyway, the MUST was changed to "is expected to 
be".

>  ----------------
>  Another issue around relay services: It would 
> be good to get a URI that can be used for 
> bridging in the relay service together with a 
> call-back. This is because the relay service 
> might have been invoked in a way so that the 
> call-back address to the original caller does 
> not automatically invoke the relay service. 
> None of the provided data seem to specify that 
> kind of URI.

This should be done in SLIM, not here.

-------------- Randomly selected tag: ---------------
Political T.V. commercials prove one thing: some candidates can
tell all their good points and qualifications in just 30 seconds.

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 5 Oct 2015 00:10:48 +0200

Den 2015-10-04 kl. 23:14, skrev Randall Gellens:
>>  Sadly, the deployment of relay services is very slow in some 
>> regions, and if they exist, they often operate limited hours.
>>  This is of course a problem when making emergency calls, but the 
>> wording in 4.1.5 should not discourage relay services from 
>> registering and providing data because they currently have limited 
>> opening hours.
>
> The text in question says "When provided by a service provider or an 
> access network provider" so I think small relay operations are OK, and 
> anyway, the MUST was changed to "is expected to be".
OK ,fine, accepted.
>
>
>>  ----------------
>>  Another issue around relay services: It would be good to get a URI 
>> that can be used for bridging in the relay service together with a 
>> call-back. This is because the relay service might have been invoked 
>> in a way so that the call-back address to the original caller does 
>> not automatically invoke the relay service. None of the provided data 
>> seem to specify that kind of URI.
>
Yes, at least not here, since the intention here seems to not be to 
provide operational data in Additional-Data.
/Gunnar

---

From: "Ben Campbell" <[email-masked]>
Date: Sun, 04 Oct 2015 23:56:03 -0500

> all possible, even if data is missing or other failures occur.

That works for me.

[...]

> I think that makes the point that PSAPs will only access the data they 
> decide they want, and hence, if data turns out to be of a different 
> type, they will likely ignore it.

Ah, sorry, I forgot about that. I think that covers things well enough.

Ben.

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 5 Oct 2015 15:48:06 +0000

What is the PSAP supposed to do with this URL?  Create a bridge and bridge in the URL?

Brian
> On Oct 3, 2015, at 4:58 PM, Gunnar Hellström <[email-masked]> wrote:
> 
>> If the relay service was included in such a way that callbacks don't bring it back in, then having the URL of the relay service won't necessarily mean that the entity doing the callback will be authorized to obtain relay services on the callback call.
>> 
>> I don't see a good way to solve that except for the relay service to be authorized based on whichever end of the call desires/needs the relay service.
> Yes, that would be included in a recommendation for how to use a URL field in Additional-Data.
> A region could have requirements that the relay services who are registered as data providers also authorize calls from the region.
> But it would be equally good if you can propose another field to convey such an URL in. It does not seem to be the intention of Additional-Data to provide operational information.
>> 
>>    Thanks,
>>    Paul
>> 
>>> /Gunnar Hellstrom
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 5 Oct 2015 13:13:08 -0400

> What is the PSAP supposed to do with this URL?  Create a bridge and bridge in the URL?

This all makes little sense to me. It seems there are two cases:

1) on original call, some agent acting for the caller bridged in a relay.

2) on the original call, some agent acting for the callee (the PSAP) 
bridged in a relay.

ISTM that in the case of a callback, the relay should again be bridged 
in by an agent for the end that got the relay originally. It makes 
little sense to me, when the caller originally bridged in the relay, for 
the PSAP to attempt to bridge in the same relay on a callback.

So in case (1), making a callback call to the callback URI (probably the 
contact from the original call) should implicitly cause the relay to be 
brought back in. Hence there would be no need to pass a URI for the 
relay to the PSAP.

	Thanks,
	Paul