Re: sipping-retarget (was RE: [Sip] RE: Question to Identity draf t)

[Paul Kyzivat <[e-mail]>]

While I think there are many cases where redirection is the best way to 
do retargetting, I fear that *forcing* the use of redirection may be 
counterproductive. Such a requirement seems likely to encourage the 
introduction of B2BUAs so that forwarding may be done without disclosing 
the identity of the new target.

	Paul

Francois Audet wrote:
> It looks like this time, we are going somewhere.
> 
> See below.
> 
>     -----Original Message-----
>     *From:* Peterson, Jon [mailto:[e-mail]]
>     *Sent:* Wednesday, April 20, 2005 17:12
>     *To:* Audet, Francois [SC100:9T51:EXCH]; Fries Steffen; [e-mail]
>     *Cc:* IETF SIP List
>     *Subject:* RE: sipping-retarget (was RE: [Sip] RE: Question to
>     Identity draft)
> 
>      
>     The idea of providing a 'Connected' header and signing it is the
>     subject of 2.2.1 of sipping-retarget. It was in fact the strawman
>     against which the unanticipated respondent problem was defined.
>     Namely, 2.2.1 is concerned with the fact that impersonation is
>     difficult to even define when it comes to response identity, because
>     there is no concept of a unique impersonatable respondent, and
>     consequently it is impossible for the UAC to know who is actually
>     authorized to respond - it must assume that virtually anyone could
>     legitimately be answering. It is possible to detect an impersonation
>     of a particular someone; very difficult, and most likely
>     self-defeating, to try to detect the impersonation of virtually
>     anyone. I'm not sure how your points below (in the first part)
>     provide us with any traction on this issue.
> 
> I think the solution to this is to have a redirection to the ultimate 
> retargeting endpoint. Let me get to that at the end of the email.
> 
>     Regarding your flow for sipping-certs, a few comments. First of all,
>     yes, Alice could include her certificate in an INVITE, thereby
>     obviating 4 and 5 (and 11 and 12). I don't think sipping-certs meant
>     to rule that out; the point is, before one sends a request, it is
>     useful to be able to look up the cert in a repository rather than
>     just sending an INVITE without SDP or something - the same
>     principle clearly does not apply to receiving a request, wherein the
>     request itself can always provide the caller's cert.  
> 
> Good. That's exactly what I wanted to hear.  This idea of having 
> SUBSCRIBEs sent at session setup by the responder (before sending a 
> response) was bothering me quite a bit.
>  
> Of course, having them available already through Certs, because Bob or 
> Carol already know Alice, is even better.
> 
>     More importantly, I think the promise of a certs-like approach lies
>     in what happens in step 2. If the cert store has access to Bob's
>     location service, the cert store may be able to anticipate that
>     Alice needs to talk to Carol right now, not Bob. If that's the case,
>     maybe sending back a NOTIFY with Bob's cert isn't the right thing to
>     do in this instance.
> 
> In certain cases, perhaps Bob could send his own certificate, plus 
> Carol's and any other's it might forward to in the immediate future.
> But, this is not applicable to all scenarios. I can see a lot of cases 
> where this is just plain impossible, and we need a solution for those 
> cases too.
>  
> Imagine that Bob is a service (like a group list) that dispatches to 
> many different individuals, randomly, or to a bunch of agents that do 
> not share the same cert (e.g., a bunch of insurance company agents, a 
> group of geographically dispersed people in a virtual call center for 
> customer support, etc.). These call center applications will happen all 
> the time, in fact, it seems to me to be a prime candidate to moving from 
> PSTN to SIP because of the increase flexibility in customizing their 
> application (and for reducing cost). Their requirement will often be "I 
> need to encrypt media" and "I need to authenticate the originator". Now, 
> I know you will respond that you could try to anticipate who will 
> respond, but this is just not the way these services operate. The 
> routing decision is made real-time (seconds count) based on the status 
> of the agents (when they hang-up). With forking, it is even worst.
>  
> To add even more complexity, imagine that Carol is a PSTN user. The 
> network may be using a bunch of PSTN gateways. It may even use a bunch 
> of different service providers to terminate PSTN calls. The algorithm 
> for distributing the calls is their own. It will again not be possible 
> to predict who will answer.
>  
> This the types of scenarios that I want to make sure we support, and why 
> I think we must have some sort of connected identity.
> 
>     The whole point of having things like SUBSCRIBE/NOTIFY in the SIP
>     protocol is to allow the network to adapt to changing conditions in
>     real time. If Bob is no longer the person that you're going to reach
>     when you call Bob, and your request will only work for Bob (e.g.,
>     you're going to encrypt it with Bob's public key), the cert store
>     should be able to tell you that this isn't going to work, and
>     potentially give you some idea of who you will reach. To be clear,
>     I'm not suggesting that sipping-certs provides a mechanism for this
>     today - but I am arguing that the fundamental -approach- of
>     sipping-certs allows for this sort of functionality, and that this
>     could potentially eliminate surprise 493 responses.
> 
> Yes: sometimes it will work. Other times it won't, as you point out 
> below and as I did above.
> 
>     Of course, even if a cert store has access to a location service, it
>     may be in no position to tell you who is going to pick up the call.
>     It may be that Bob has populated his location service with 5
>     different URIs, targeting any one of which might result in a
>     completed call or not. In these cases we are in a genuine quandry.
>     Encrypting an SDP body five different times, and including all five
>     in a message, is no fun, let alone discovering the certificates of
>     the five targets. This is a generic forking problem, though, and it
>     taps into the heart of the question of whether or not redirection or
>     retargeting is preferable architecturally. Encrypting to multiple
>     targets has always been one of forking's known drawbacks.
> 
> Sequential forking is also quite problematic. You could imagine doing 
> these certificate fetching many times before finding the right one.
>  
> I don't understand what is wrong with "forcing" a redirection at the end 
> of many retargetings. It seems to me that retargeting in the network is 
> here to stay. But, we have the power to force a redirection for the 
> unanticipated respondent problem, at least in the context of identity. 
> When the respondent figures out that he wants its identity to be known 
> to the initiator regardless of retargeting, he could force this 
> redirection. Incidently, this is why I tought that a 3XX response code 
> would be more appropriate than a 493: the reason is that he wants to 
> session to be reinitiated/redirected directly to itself, not through a 
> bunch of retargeting entities.
>  
> Now, of course, the sender also needs to be able to not go through with 
> a call if the unanticipated answerer is not the suitable.  If we mandate 
> the use of 3XX/493 (by the responder) for retargeting when identity is 
> required, then we avoid the problem of the unanticipated responder 
> accepting the call (followed by the sender clearing it after answer 
> which is quite ugly). That 3XX would have an identity and the cert. I 
> like the fact that this solution works well with both the connected 
> identity problem and with the sRTP & S/MIME problem.
>  
>  
>  
>  
> 
>     Jon Peterson
>     NeuStar, Inc.
> 
>         -----Original Message-----
>         *From:* Francois Audet [mailto:[e-mail]]
>         *Sent:* Tuesday, April 19, 2005 5:43 PM
>         *To:* Peterson, Jon; 'Fries Steffen'; '[e-mail]'
>         *Cc:* 'IETF SIP List'
>         *Subject:* RE: sipping-retarget (was RE: [Sip] RE: Question to
>         Identity draft)
> 
> 
>         OK, forget about the idea I was proposing, and instead let's
>         try to achieve it using the something along the lines of the
>         identity draft.
> 
>         What about the connected number information being essentially
>         the same mechanism as what you have for the Calling identity,
>         but provided in the response?
> 
>         Something like a new "Connected header" (or perhaps Contact
>         would be sufficient, I'm not sure), followed by the
>         Identity and Identity-Info? The Identity-Info header could
>         have something like https://biloxy.example.com.
> 
>         The unanticipated respondent problem would be easier to deal
>         with because:
>         - In a lot of case, Bob and Carol (the retargetter and retargettee)
>           could have the same certification authority, so Alice's
>         decision to
>           proceed or not with the call may not require going fetching the
>           yet another certificate.
>         - Maybe we have "Require: connected-identity" header if we need the
>           identity.
>         - Yes, if the SDP was encrypted (because of sRTP or whatever),
>         it would
>           cause another session to be re-established because of the 493 (or
>           other appropriate rejection code).
> 
>         Would that be a good way to solve the Connected number problem?
> 
>         Now, moving to the next problem, the encrypted SDP.
> 
>         Alice wants to call Bob and have secure media (because she is
>         afraid of hackers
>         tapping in).  In fact, she essentially wants all her media
>         encrypted, regardless of
>         who she talks too, even strangers. She does not have Bob in her
>         contact list, as she
>         is calling him for the first time. She also doesn't know Carol,
>         his assistant to whom the
>         call will be retargetted.
> 
>         In the example above, the sequence would be this:
> 
>         1 - Alice sends SUBSCRIBE to Bob to fetch his certificate
>         because she doesn't have it.
>         2 - Bob sends NOTIFY to Alice with his certificate.
>         3 - Alice sends INVITE to Bob, with SDP encrypted using Bob's
>         key, along with her Identity
>         4 - Bob doesnt' have Alice's certificate, so he sends SUBSCRIBE
>         to Alice to fetch her cert.
>         5 - Alice sends NOTIFY to Bob with her certificate.
>         6 - Bob retargets to Carol (forwards the INVITE to Carol).
>         7 - Carol responds with 493, since she can't decode the SDP, and
>         includes her Contact
>             and her Identity.
>         8 - Alice sends SUBSCRIBE to Carol to get her cert.
>         9 - Carol sends NOTIFY to Alice with her cert.
>         10 - Alice sends INVITE to Alice with her Identity, encrypted
>         with Carol's key.
>         11 - Carol sends Alice a SUBSCRIBE to get her certificate.
>         12 - Alice sends NOTIFY to Carol with her certificate.
>         13 - Carol sends 200 OK to Alice, with SDP encrypted using
>         Alice's key.
> 
>         This is way too complicated and will take forever to complete a
>         call. And in my mind,
>         lots (if not the majority) of calls would look like this in
>         environments where
>         unanticipated respondents are typical (which is the case for a
>         lot of
>         businesses).
> 
>         Couldn't this be avoided if not only was Identity used in both
>         directions
>         (solving the unanticipated respondent problem), and if Alice and
>         Carol also
>         included their user certificate (for the purposed of sRTP) in
>         the INVITE and
>         493? Instead of a 10 roundtrip session setup, it would be a 2
>         roundtrip
>         session setup.
> 
>         Of course, in the case of people who know each other, Alice
>         would have subscribed to
>         Bob and Carol's certificate, so none of this would happen: it
>         would be a 1 round-trip
>         session setup. In other words, I DO like the Certs draft, and it
>         should be used
>         whenever possible.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments on the application of sip

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