On Apr 21, 2008, at 1:12 AM, Juha Heinanen wrote:

> Dean Willis writes:
>
>> How does the caller know that the callee has configured his proxy to
>> perform those actions and that the response isn't coming from  
>> somebody
>> else?
>
> dean,
>
> i didn't understand your question.  you mean 200 ok response?  it is
> coming from somebody else, for example, if callee has configured to
> forward requests to him to his voice mail.

Ideally we'd be talking about the 200 OK, but our identity assertion  
mechanism (FC 4474) currently doesn't work in the 200 OK, so we're  
really talking an RFC 4916 message in the other direction.

If you call me and I've forwarded those calls to voice mail, how do  
you know that I've authorized this forwarding and that it wasn't done  
by a MITM attacker? With our existing protocol set, you don't.

One possible workaround would be to handle the "forwarding" operation  
by having my bot accept your INVITE with a 200 OK, do an RFC 4916  
exchange, then do a REFER telling you to call my voice mail. Now you  
know "for sure" that I want you to talk to this other identity "my  
voicemail".

It would be much cleaner to allow RFC 4474 in a response, so that I  
could simply respond to your INVITE with a 302 pointing you at my  
voice mail. My signature (or that of my service provider, who we've  
agreed to trust) would assert that the retargeting to the voice mail  
platform is valid.

Where a 302 isn't ideal and it would be better to "proxy retarget" the  
request, we need a new mechanism -- we need a way for the proxy to  
send you something that explains that the request is being retargeted  
and who you should be looking to connect with. I've seen it proposed  
that we could use a new provisional (or reliable provisional) response  
to do this. And if RFC 4474 could be extended to cover this response,  
then this partiular problem would be solved.

--
Dean

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip

Reply via email to