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

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 20 Sep 2013 11:30:50 -0500

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.

  The second paragraph of S5.2 constitutes a separate requirement.

  Is it worth spelling these out explicitly as requirements?

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

  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.

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

- S3.1: s/synchronized as to state/synchronized,/
  This improves readability since the text as it currently stand is hard
  to parse.

- S3.3, second paragraph: s/Similarly to/Similar to/

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

Thanks,

- 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

---

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:

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

> presence of the callback marking with this state and override local UA

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.

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

> outbound emergency call placed earlier./
Fixed.

> This improves readability since the text as it currently stand is hard
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

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 26 Sep 2013 11:18:46 -0500

> thanks for reviewing the document.

Hannes: No problem, thanks for considering my comments.

Please see inline.

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

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

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

> 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 [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: 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

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 27 Sep 2013 14:17:19 -0500

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

---

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:

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