RE: sipping-retarget (was RE: [Sip] RE: Question to Identity draft)

Francois, 
Definitely agreed that we are converging, here. I substantially concur with all that you say pretty much up to the last couple paragraphs. 
If Bob is actually a group list, I would note that for certain kinds of call center applications and so on, it actually -does- make sense for the group to share a cert. No question, though, that for a large group like that where a common cert cannot be used, it would be very difficult for a location service to anticipate precisely who is going to answer. 
Regarding forcing redirection in order to prevent the unanticipated respondent problem - well, that was the proposal of sip-identity-02. At the time, that made a lot of people very nervous, although to some degree I think it was an overreaction (sip-identity-02 didn't propose eliminating retargeting from SIP, it proposed limiting the cases in which an entity which acted as an auth service would be eligible to retarget requests), I think that conceptually there were problems with the approach. We really don't have the fundamental apparatus in SIP to be able to make intelligent decisions about when retargeting should and should not occur, largely because the distinction between AoRs and other types of URIs is merely a conceptual distinction, and not something that a location service could distinguish programmatically. 
Moreover, how would a respondent 'force' a redirection, I wonder? If the redirection actually comes from the respondent, I submit that we're no better off in solving the unanticipated respondent problem than we are if the respondent sends a 200, or a 604. The UAC still has no way to tell if the response (success, failure, or redirection) is coming from an authorized respondent. Moreover, how would a respondent know that it is necessary to force a redirection? 
Finally, let me say a couple more things about redirection and the SUB/NOT model. I think you and I at least agree that many of the sipping-retarget problems start to go away if Bob's location service exposes the route target list associated with Bob to Alice. The more information the UAC gets, the less 'unanticpated' these respondents become. Redirection is of course one way that the route target list can be given to the UAC for its own use. Lately, though, I've been giving a lot of thought to what sip-events might be able to do for us here. Assuming something like reg-event, say, or maybe even just presence, the UAC can receive an up-to-the-minute picture of what sorts of services and URIs are associated with Bob. Presence can provide a menu of services, different URIs with different capabilities, associated with a particular user from which prospective callers can actually choose. If, when Alice subscribes to Bob's reg-events, say, she was able to see that Carol is a potential contact for Bob, then Alice wouldn't be surprised if, when she sent an INVITE to Bob, Carol answered. Potentially, exposing route target sets ahead of time could let Alice even choose from among the possible alternative contacts (to avoid people she wouldn't want to talk to anyway). If Alice sees that Carol is a contact for Bob, Alice could even fetch Carol's reg-event and learn that Ted is a contact for Carol, and thus be able to anticipate Ted, and so and so forth. The interesting thing about this approach is, of course, that we get to keep retargeting. What it further demonstrates is that it is possible for a UAC to get the information it needs to be able to anticipate retargeting even the UAC does not control call routing - I think this separation is critical to retargeting advocates. One can even imagine that presence-style policies, XCAP and so on, could be used to govern how much information the UAC gets about Bob's contacts for callee privacy purposes. 
My point here is not, of course, to make a concrete proposal, but just to say that there are ways other than redirection that we might approach the unanticipated respondent problem, that there are clear tradeoffs, and that we can get some pretty interesting capabilities if we go down one path instead of another. Ultimately, I think we still have a long road ahead of us, in terms of understanding the problem we want to solve and understanding what is the best approach to a solution. 
Jon Peterson 
NeuStar, Inc. 
	-----Original Message-----
	From: Francois Audet [mailto:audet@nortel.com]
	Sent: Wednesday, April 20, 2005 9:36 PM
	To: Peterson, Jon; 'Fries Steffen'; 'fluffy@cisco.com'
	Cc: 'IETF SIP List'
	Subject: RE: sipping-retarget (was RE: [Sip] RE: Question to Identity draft)
	
	It looks like this time, we are going somewhere. 

	See below. 
	-----Original Message-----
	From: Peterson, Jon [mailto:jon.peterson@neustar.biz] 
	Sent: Wednesday, April 20, 2005 17:12
	To: Audet, Francois [SC100:9T51:EXCH]; Fries Steffen; fluffy@cisco.com
	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.