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 [email protected] 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
--
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 protected]
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
