RE: [Sip] RE: Identity after reinvite

["Peterson, Jon" <[e-mail]>]

Paul,

I think we're mostly agreed here, but a couple of small points.

> > - I also question whether or not the callee UA will even know which
identity
> > it needs to stick in the From header of requests in the backwards
direction:
> > after all, if the UA is registered under multiple AoRs, what exactly
about
> > the dialog-forming request will tell it definitively which identity it
is
> > supposed to use? While in some cases, this could be inferred from the
> > Request-URI of the dialog-forming requests, it won't be sufficient in
all
> > cases, I think.  The previous hop (last proxy server to handle the
request)
> > might also be a hint. Now, it could be that there's a good answer to
this
> > question, but if so, we need to know that answer.
> 
> There are many reasons why a UA with multiple registrations needs to 
> know which one was the source of an incoming call. And the UA can easily 
> achieve this by using distinct contacts in the registrations. I don't 
> think we need to lose sleep over those that choose not to do so.

I agree that what you say above is the right overall strategy for SIP
deployments, but I also believe that retargeting would not occur in the case
you describe above. Retargeting occurs when some circumstance like this
prevails: My AoR is [e-mail], and for some reason my current
UA can only register at, say, chicago.example.com, and accordingly I am
forced to put a contact in biloxi.example.com for [e-mail].
In that case, I can't differentiate whether a request I receive had
originally been sent through biloxi.example.com or chicago.example.com from
anything other than the To header. In that case, it's not clear what the
"actual" identity of the UA would be, other than just what it sees in the To
header. This is significant, given the original proposal on which I was
commenting:

>>>The solution, which rfc3261 warns of, is that a UA has to put its actual
>>>identity in the From field URI, not what it saw in the To field of the 
>>>original request.

My point is that this is less useful, if not circular, in cases of
retargeting, and the retargeting cases are the ones we are trying to solve.
There's no reason, just because of some transitive registrations, that the
chicago URI is any more "actual" than the biloxi URI; I see an equally good
argument that the biloxi URI is my actual AoR. UAs and their users don't
have unique "actual" identities in SIP.

> > - Retargeting is inherently insecure, and no amount of wiggling with the
> > sip-identity mechanism will repair this. If Alice sent a request to Bob,
and
> > a new request in the backwards direction comes from Edgar, I think there
is
> > -no- circumstance in which Alice should not view this as a potential
> > security risk, regardless of the presence or absence of an Identity
header,
> > SIPS, or what have you. Trying to explain this aware flies in the face
of
> > common sense, and will be incomprehensible to actual users who will need
to
> > make security decisions based on the evidence collected from the
protocol by
> > their user agent.
> 
> Of course it is a potential security risk, which is why it is good to 
> report that it happened. (A good UA will hopefully note that the 
> connected party is not the called party and make a big fuss at its UI.) 
> But it is still good to know who in fact you ended up talking to.

Speaking strictly to request identity for a moment, it is of course possible
that a dialog will pass without any requests being sent in the backwards
direction. So certainly we can't rely on request identity to tell you who
you ended up talking to. If connected-party is a property we want, we should
be getting it from responses - well, more to the point, I think we should be
getting it by eliminating retargeting in favor of redirection, but let's not
go there now. :)

> This is however not in any way a surprising event. It happens all the 
> time for a variety of reasons. Usually it is detected because the voice 
> you hear isn't the one you expected to hear. The fact that we can do 
> better than that is itself of value. But I don't think we need to 
> deprecate the call any further. While it would be good to know more 
> about why the retargetting occured, in most cases people will do fine 
> without that.

I have never found this line of argument very persuasive, but perhaps that's
because I'm less concerned about success cases than failure cases. It's
useful to look at this for a moment as a response identity problem: if the
response you receive does not lead to you hearing a voice (i.e., it's a 604,
or a 301, or something), then you want to know at a protocol level who sent
that response. The reason why we need to do better than the PSTN is not
because the success case is very different from a security perspective
(after all, in the PSTN we just throw calls over the wall and have no
insight into retargeting/security whatsoever, and rely on human voice
identitification as you suggest), it's because the failure case is very
different from a security perspective (because the untrusted Internet is
delivering us these responses rather than a private telephony signaling
network).

Now, all that said, I don't think this is limited to response identity, in
the sense that new requests in the backwards direction (like BYE) have a
serious denial-of-service potential comparable to the use of something like
604 in response identity. So I think there is a clear motivation to do
better than the PSTN. In order to make a reasonable authorization decision
about handling a BYE request in the backwards direction, Alice needs to be
able to anticipate who should be authorized to send such a request. My gut
tells me that Bob should be the person so authorized, and that anyone else
sending such requests should be extremely suspect, if not discarded out of
hand without human oversight.

> >>>This will break all compatibility with rfc2543, but
> >>>will work with other rfc3261 compliant endpoints, since the URI is no 
> >>>longer used for dialog identification.
> >>
> >>If we were going to switch to this, then it could begin with the first 
> >>response to the invite. That would be the first step to really solving 
> >>the connected-partiy-id problem.
> > 
> > Not just 'could begin' but 'should begin'. If the identity you see in
the
> > response to the INVITE does not equal the identity you see in requests
in
> > the backwards direction, I believe that is extremely problematic. Yes,
this
> > is what I mean by solving the response identity problem.
> 
> The 'could' was a response to Jonathan, who didn't seem to have that in 
> mind.
> 
> Re having the identity in a subsequent request differ from the one in 
> the response to the invite: I'm not sure it is so problematic. The 
> identity can change in mid call, and that will then probably first 
> manifest itself in the first message sent following the identity change. 
> This could happen if one party is a B2BUA or gateway. 

So far, I haven't incorporated the idea that the identity can change
mid-call into my requirements space. I am extremely skeptical that this is
an achievable requirement if we cast it as something that the originating
user and the original target don't explicitly sanction. It brings Alice back
to the case of wondering if this guy Edgar can actually tell her to tear
down her call with Bob or not. I really don't see how we can expect users to
understand this.

Now, with some kind of explicit Replaces-style operation that Alice must
authorize, originating from Bob, telling her that Edgar is now in charge, I
believe Alice can make a reasonable decision, and an identity can change
mid-call. But the idea that she is just going to start receiving BYE
messages from some guy named Edgar and just assume that he's in charge;
well, that's tough for me to swallow. Hence I support roughly the strawman
you sketch in the following sentence, and that's why I see this idea of
dissonance between the identities in requests and responses as a problem.

> Perhaps it would be more problematic if the change was first seen in 
> some random message (e.g. INFO or OPTIONS) rather than in a message 
> intended to change dialog state (e.g. INVITE or UPDATE). But it is only 
> problematic if we enact some rule that says changes in identity must be 
> formally announced.
> 

Jon Peterson
NeuStar, Inc.

_______________________________________________
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