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

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 26 Sep 2013 16:22:33 +0300

Hi Vijay,

thanks for reviewing the document.

I have a few remarks below:

On 20.09.2013 19:30, Vijay K. Gurbani wrote:
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
> Document: draft-ietf-ecrit-psap-callback-10
> Reviewer: Vijay K. Gurbani
> Review Date: Sep-20-2013
> IETF LC End Date: Sep-27-2013
> IESG Telechat date: Unknown
>
> This draft is basically ready for publication, but has a couple of
> minor issues that should be fixed (or at least looked at) before
> publication.
>
> Major: 0
> Minor: 2
> Nits: 4 (to improve readability)
>
> Minor:
> - S5.2: Maybe I am missing something here, but I did not see any
> proposed requirement as I read the text until this point. At least I
> do not see a explicit requirement.
>
> The text in S5.1 constitutes an implicit requirement in that it asks
> the SIP UA to override user interface configurations when an incoming
> call has "Priority: psap-callback" header AND the SIP UA has recently
> placed a call to an emergency service. Is this the requirement you
> allude to in the first sentence of S5.2? If so, may be better to
> explicitly pose this as a requirement.

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.

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

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

>
> At least, this alleviates the eventuality that somehow the VoIP
> provider forgot to scrub the marking AND the UA never made an emergency
> call (thereby allowing spam through).
>
> Now, if it is your intent to keep the UA as stateless as possible, then
> overriding local UA behaviour based on solely the callback marking is
> fine. But I do not know what your assumptions are here with respect to
> state maintained in the UA. So please determine if this approach of
> asking UA to couple state information with the marking makes sense or
> not. If not, feel free to disregard, but I did want to point it out.

Keeping state information for this purpose is already part of the 
referenced PhoneBCP solution and does not require any new functionality 
in this document. We mention this specific procedure in Section 1. 
Unfortunately, it does not work in all scenarios (as Section 3 explains).

Have a look at Section 1 (and maybe Section 3) again to double-check 
whether the story gets across.

>
> Nits:
> - S3, first paragraph: "As explained in Section 1 a SIP entity examines
> an incoming PSAP callback by comparing the domain of the PSAP with the
> destination domain of the emergency call."
>
> Here, I would suggest adding a small phrase as follows:
>
> s/destination domain of the emergency call./destination domain of the
> outbound emergency call placed earlier./
>
Fixed.

> - S3.1: s/synchronized as to state/synchronized,/
> This improves readability since the text as it currently stand is hard
> to parse.
OK.
>
> - S3.3, second paragraph: s/Similarly to/Similar to/

OK.

>
> - S3.5, first paragraph: s/later does leave/later leaves/

Ok.

Thanks for the feedback.

Ciao
Hannes

> Thanks,
> - vijay

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 27 Sep 2013 21:48:42 +0300

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,
>>
> Hannes: No problem, thanks for considering my comments.
>
> Please see inline.
>
> 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.
>
> 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.
>
> 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.
>
> 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 [email-masked] 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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 27 Sep 2013 19:15:58 +0000

Hi,

Thanks for your comments, Vijay!

Regards,

Christer

________________________________
From: [email-masked] [[email-masked]] on behalf of Vijay K. Gurbani [[email-masked]]
Sent: Friday, 27 September 2013 10:17 PM
To: Hannes Tschofenig
Cc: [email-masked]; [email-masked]; [email-masked]; Richard Barnes; General Area Review Team; [email-masked]
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-ecrit-psap-callback-10

Hannes:

I am happy with the changes outlined below.  I am convinced they
make the document better.  Thank you for attending to my comments.

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

Cheers,

- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq
_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 29 Sep 2013 18:16:44 +0300

Hi Vijay,

thanks for the time to review the document so carefully.

I have just submitted an updated version and I indeed think that your 
review feedback has improved the quality of the document.

Ciao
Hannes