Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-psap-callback-10

[Hannes Tschofenig <[e-mail]>]

Hi Vijay,

I updated the draft to take your remarks into account.

I liked the security requirements text to the security threats section, 
as you suggested.

I believe you have a point regarding the remark about the security 
solution. The current description focuses on the PSAP but not on the UA. 
I assumed that we essentially inherit the functionality from the 
PhoneBCP document but that should be expressed somewhere.

So, I added the following section to the draft:

----

    The approach for dealing with implementing the security requirements
    described in Section 5.2 can be differentiated between the behavior
    applied by the UA and by SIP proxies.  A UA that has made an
    emergency call will keep state information so that it can recognize
    and accepted a callback from the PSAP if it occurs within a
    reasonable time after an emergency call was placed, as described in
    Section 13 of [RFC6443].  Since UA considerations are described
    already in [RFC6443] as well as in [RFC6881] the rest of this section
    focuses on the behavior of SIP proxies.

-----

What do you think about that addition? Do you think it addresses your 
concern?

Ciao
Hannes

On 26.09.2013 19:18, Vijay K. Gurbani wrote:
> On 09/26/2013 08:22 AM, Hannes Tschofenig wrote:
>> Hi Vijay,
>>
>> thanks for reviewing the document.
>
> Hannes: No problem, thanks for considering my comments.
>
> Please see inline.
>
>> Section 5.1 describes the security threat. It is actually quite simple:
>> Imagine you have a mechanism that allows you to bypass blacklists.
>>
>> The psap-callback is such a mechanism.
>>
>> So, the threat is that someone could misuse the psap-callback procedure
>> to bypass blacklists (etc.) to send you unwanted traffic.
>>
>> The first requirement says that the developed mechanism has to provide
>> some protection against it.
>
> I understand the threat implicit in S5.1, but that threat and the
> opening paragraph of S5.2 do not correlate for me when I read the draft.
> The opening paragraph of S5.2 starts with,
>
> "The requirement is to ...",
>
> I am unable to tell exactly *which* requirement are you talking about
> by using the definite article ("The"). One way to fix this is to simply
> start S5.2 by saying "The security threat discussed in Section 5.1 leads
> to the requirement to ensure that ..."
>
> Phrased as such, the cause and effect between S5.1 and first paragraph
> of S5.2 are much more clear.
>
>>> The second paragraph of S5.2 constitutes a separate requirement.
>>
>> Yup.
>>
>> Note that both requirements aren't written with RFC 2119 requirements
>> language but I believe that's fine in this case.
>>>
>>> Is it worth spelling these out explicitly as requirements?
>>
>> I don't think it will get any easier to read.
>
> I am not as much worried about phrasing these using rfc2119-type
> language as much as I am worried about ensuring that the intent of
> what you write shows through. And the small modification I proposed
> above allows you do not spell out these as normative requirements
> but still impart to the reader the gravity of them.
>
>>> - S5.3, last paragraph: It seems to me that the SIP UA is the authority
>>> insofar as it can maintain state that an emergency call was made a
>>> short while ago. Consequently, it would seem beneficial to couple the
>>> presence of the callback marking with this state and override local UA
>>> behaviour.
>>
>> This works at the UA and only if the callback reaches the same UA.
>
> I don't think we are on the same page.
>
> S5.3 is attempting to use the identity of the PSAP to determine whether
> to honor the callback marking. I have no problem with this.
>
> The point I am trying to make is to allow the UA itself to be the judge
> on whether or not to honor the callback marking (i.e., endpoint
> intelligence). A UA knows it made an SOS call, therefore, it seems
> that *it* should be allowed a role in the decision making on whether to
> accept an incoming call that has callback marking.
>
> If the UA made an SOS call and hung up (for whatever reason), AND it
> gets an incoming call with the callback marking, it overrides local
> filters and behaviour to simply accept the call.
>
> If the UA gets an incoming call with callback marking, AND the UA has
> not made an outgoing SOS call, then clearly this incoming call is spam.
>
>> However, as the scenarios outline in the beginning of the draft we are
>> also talking about intermediaries and we have to consider more complex
>> deployments where the signaling path of the original emergency call is
>> not the same as the reversed signaling path of the callback.
>
> Except for the PSTN interworking case (S3.5), I don't see that the
> remaining complex deployments hinder you in delivering the call from
> the PSAP to the same UA that originated the call.
>
>  From my analysis, in Section 3.1 when the ESRP makes a call back to the
> UA and this call goes through the inbound proxy, the GRUU in the call
> will ensure that the same UA receives the inbound call.
>
> In Section 3.2, the callback from [e-mail] may get normal treatment
> from the VoIP provider's inbound proxy, but assuming that the inbound
> proxy preserves the callback markings (which it should), then the UA
> can uses the knowledge that it made an outbound SOS call to receive the
> incoming call. Here, even a malicious actor (spammer) in the VoIP
> provider's network somehow manages to inject calls with the "Priority:
> psap-callback" header then the UA can reject these calls as spam since
> it knows that it never made an SOS call.
>
> In Section 3.3, the callback originates from police-town.org and the
> intermediaries/caller's UA have saved state.org. Again, assuming that
> the intermediaries are able to deliver the callback to the UA, the UA
> can accept the call simply based on the fact that it made an outbound
> SOS call!
>
> Same logic applies in Section 3.4. The UA knows it made an SOS call,
> therefore, at a later time if it gets a incoming call with the callback
> marking, it can accept it.
>
> In short, what I am arguing for is for the UA be allowed to be an actor
> in the decision on accepting an incoming call with callback markings
> simply because the UA has the authoritative answer on whether it made an
> outgoing emergency call. Assuming that the intermediaries are able to
> deliver the callback from the PSAP to the UA, it is easy for the UA to
> decide to accept it or not: If the UA never made an outgoing emergency
> call, then any incoming call with callback marking is treated as spam.
> If the UA made an outgoing emergency call, then an incoming call with
> callback marking is accepted.
>
> Please let me know what you think.
>
> Thanks,
>
> - vijay