RE: [Sip] Connected-identity and changing the To header field in aresponse

Yes, I was asked for clarification on this point after the meeting, and I'll be providing it here. As you surmised, it is not that RFC3261 relies on the addr-spec of the To or From header field for transaction identification, or something. In fact, I would have essentially the same concerns about any proposal that provided an additional header (say, a 'Connected-Party' header) in responses to dialog-forming requests which was understood to clobber the To header field and identify the AoR of the party who was reached after retargeting of the request took place.

Starting with the goals of this approach: what sort of UAC decisions or behavior do we hope to enable through sending a response with a modified To header field? As far as I can understand, we either want to render this AoR to the user of a UAC (so the user can react in one way or another), or input the AoR to some sort of policy manager (e.g. blacklist/whitelist) that might make a decision about whether or not the session should continue -prior- to session establishment. If we don't care about this occurring prior to session establishment, of course, then we could go with the connected-identity draft as it is written today.

A little refresher on my sipping-retarget draft: The core problem with any scheme for connected party is figuring out how you'd decide whether or not a particular respondent is authorized. This is the argument of 2.2.1 of sipping-retarget, the "unanticipated respondent" problem. When we think about what sorts of policy decisions we expect a human or automata to make when receiving a response with identity information, we have to acknowledge that the UAC has no way of knowing which respondents are or are not authorized to respond to the request in question. Since the UAC has no insight into any retargeting that has taken place, the UAC has to assume that virtually any response is a potentially legitimate one. As such, there is little room for any meaningful policy decision when receiving a response. This problem is further compounded by the fact that the UAS may have several possible legitimate AoRs it could claim (I have a UA that registers its contact address under 3 separate SIP services simultaneously), and of course the fact that AoRs may be pretty uninformative (e.g. sip:user31@freesipservice.example.com), all of which complicate authorization decisions. Solving this problem is on the same footing as solving the request-history problem set.

With that background, the problems with providing this connected party information in responses (via the To header or what have you) are roughly as follows:

a) The "unanticipated respondent" problem is especially an issue for response identity because not all responses are success responses. If you end up connecting to a party (receiving a 200), you can potentially rely on human factors to help you identify who you are talking to (after all, Carol can always answer Bob's phone regardless of who SIP thinks you connected to) and/or use the connected party information to change how you might address the party on the other side. With a 403 response, you are in a very different predicament - how is UAC or user behavior supposed to change based on the connected URI attributed to a 403, given the unanticipated respondent problem? For provisional responses, the issues become even worse - we then get into the wonders of forking, multiple provisional responses from multiple sources asserting different To header fields - in short, nothing which makes it any easier to render a "responding" AoR to a user, for example. Response identity, in so far as it deals with non-final, non-successful responses, opens up the "unconnected party" problem set. I think this is just the wrong framing of the problem. You want to know who you connected to, not who you didn't connect to.

b) Getting a signature over the To header field in responses would be difficult. In full awareness of Mr. Elwell's note below that certain parties are interested in "(unauthenticated) identity in a response", if this information is going to be put to any purpose, cause any change in human or UAC behavior, I have a hard time seeing how anyone could defend it being unsecured. If you want a human or an automata to make a policy decision based on the AoR in the To header field of the response, some sort of response identity signature would be necessary to prevent obvious impersonation attacks designed to thwart authorization decisions. With all due respect to the authors of draft-cao-sip-response-identity/auth, I'm not sure this problem is readily solved. Making sure that an appropriate authentication service is in the path of responses is problematic, since responses must traverse exactly the same path as requests. I played around with this a lot in the early phases of SIP identity, and at the end of the day, I had to conclude that the only way to make this work was to eliminate retargeting. Since providing connected-identity in responses assumes that retargeting has taken place, it wouldn't exactly be getting off on the right foot. Constraining inbound request routing to a domain such that responses will traverse an authentication service, or forcing a UAS to participate in the Identity scheme, is likely to require mandatory option-tags or comparable mechanisms that will limit the applicability of response identity and more or less eliminate its opportunistic use.

c) The inability to reject a response. Take the easiest case - let's say that the UAC receives a final success response, say a 200 response, with a modified To header field from a party that is blacklisted by UAC policy. What exactly is the UAC supposed to do? Send a 403? One cannot reject responses. Maybe a CANCEL? As section 9.1 of RFC3261 says, CANCEL "has no effect on requests that have already generated a final response." Drop the request on the floor? You'll just receive retransmissions. All you can do is ACK it, since the dialog has already been formed, and then send a BYE. In other words, a session -will- be established, there simply isn't an opportunity for policy to be put into effect prior to session establishment. Also, consider the need for the new responses defined in the sip-identity draft, like say the 438 response - if the UAC receives a 200 response with a potentially repairable error in the Identity header, how can it express that error to the UAS, since it can't send responses to a response?

Given the above, why does the UAC need to know who has been reached in the response, rather than in a request after the dialog has been formed? As (c) illustrates, in the 200 response case a session will be established anyway, so sharing the identity of the connected party after session establishment doesn't actually miss some opportunity for applying policy - moreover, an UPDATE or similar request that provides the connected-identity information could be rejected by the session-originating UA in a manner that is helpful to the session-terminating UA (e.g., a 438 response could be sent). If we go with the mechanism in the connected-identity draft, problem (b) disappears, since request routing is far more malleable than response routing. Additionally, the connected-identity draft wisely does not attempt to solve "unconnected party" problems from (a), which are the least tractable of the unanticipated respondent problems. Rather, connected-identity provides an indication more along the lines of, "your dialog was established, however that might have happened, and this is who is on the other side".

Furthermore, any solution that tried to put the connected-identity information into responses would be providing an imprimatur of legitimacy to those responses - presuming they had a signature, UACs would validate it, and provided it checked out, they would be tempted say "this is a legitimate response." Nothing could be further from the truth, as sipping-retarget illustrates. Legitimacy of responses cannot be determined by UACs in the absence of something like request-history.

Finally, I like having one Identity header, and for the meaning of that Identity header to *always* be that it is a signature over the From header field issued by the domain identified by the host portion of the addr-spec of the From header field. The current connected-identity header draft provides that property.

Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Elwell, John [mailto:john.elwell@siemens.com]
Sent: Monday, April 03, 2006 11:46 PM
To: sip@ietf.org
Subject: [Sip] Connected-identity and changing the To header field in aresponse

During discussion of draft-elwell-connected-identity in Dallas, somebody put forward the opinion that it would be dangerous to change the To header field URI in a response (i.e., make it different from the From header field URI in the request). My assumption at the time was that it would undermine the transaction concept in SIP, yet reading what RFC3261 has to say about transactions, the value of the To header field URI in a response does not appear to be involved in coupling a response to a request. Therefore I assume the person who indicated the danger (which was not challenged at the meeting) has other reasons in mind. I would greatly appreciate opinions on the wisdom or otherwise of allowing the To header field URI to change. It seems that from discussion of connected-identity there is a desire from some parts of the community to include an (unauthenticated) identity in a response.

John 