Re: [Sip] Preventing unanticipated respondent syndrome when retargeting

[Hadriel Kaplan <HKaplan at acmepacket.com>]

Howdy,
Can you describe more succinctly why this is a problem that needs fixing?  (not that I don't think it would be - I'm just low on caffeine and can't grasp the issue being solved)  I guess I don't get why Alice needs to know this before getting a 200? (or before a 180/183)

Also, how would this "work" with forking?

-hadriel


> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of Dean
> Willis
>
> 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
_______________________________________________
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