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

[Paul Kyzivat <[e-mail]>]

On 10/3/15 8:10 AM, Gunnar Hellström wrote:
> 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.
> ----------------

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

> /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.
>>
>> 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.
>>
>> [...]
>>
>> _______________________________________________
>> Ecrit mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ecrit
>
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit
>