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

[Hannes Tschofenig <[e-mail]>]

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