[Sip] Preventing unanticipated respondent syndrome when retargeting

[Dean Willis <dean.willis at softarmor.com>]

I define "unanticipated respondent syndrome" as the sense of surprise  
Alice gets when she calls Bob, only to have the call answered by  
Charlie. This is especially problematic if the sorts of security  
operations that depend on Alice having some sort of keying  
relationship with Charlie become important.

Alice is expecting:

Alice--1-->Proxy--2-->Bob

but instead she gets:

Alice--1-->Proxy--2-->Charlie

because Bob forwarded his phone to Charlie, or because Charlie, who is  
authorized to do so, registered as a contact for Bob, and Bob didn't  
answer (or has a lwoer qvalue, or whatever)

RFC 4916 lets Alice find out who answered the phone in the most  
difficult of cases, and other techniques like P-Asserted-Identity in a  
response address simpler cases (or we can use endpoint- asserted RFC  
4474 Identity when the keys are known or discoverable). So that's not  
a problem. Alice can figure out that she's talking to Charlie, once  
they get connected.

The only problem is cluing in Alice that she's about to be talking to  
Charlie instead of Bob.

In the cases I've identified above, the proxy knows that it is  
retargeting the request to Charlie, not rerouting the request to Bob.  
How does it know this? It either a) knows that the Call Forwarding  
feature has been activated, and that's always a retarget, or b) knows  
that the contact for Bob was registered by Charlie, who isn't Bob (but  
that Charlie is authorized to register for Bob's AOR). In fact, if  
this the case, it knows both Charlie's authentication identity and his  
contact.

Since the proxy knows, it should be able to inform Alice.

I therefore propose a provisional response from Proxy to Alice, which  
I'll provisionally call "121 (Retargeting)"

A proxy executing a retargeting operation (by which we mean an  
operation that replaces the request URI such that the authenticated  
identity of the new request URI is different from the authenticated  
identity of the old one) SHOULD return a 121 (Retargeting) provisional  
response. The 121 response contains a Contact header field, the value  
of which is the new identity being targeted. Optionally, we might  
include some sort of "cause" parameter, explaining why the request is  
being retargeted (like "Bob's dead, talk to Charlie").

If a proxy doesn't know whether it is rerouting or retargeting, it  
SHOULD assume that it is retargeting, and send the appropriate 121  
response.

In conclusion, this preserves the proxy-mediated functionality  
required for draft-ietf-sip-outbound, while giving us the I-know-who-I- 
expect-to-reach function of a 302 (Redirect).

Yeah, this should be an I-D. I'm now accepting volunteer co-authors to  
do the dirty work, assuming this idea gets any traction.

--
Dean

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip