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

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.

Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Francois Audet [mailto:audet@nortel.com]
Sent: Tuesday, April 19, 2005 5:43 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)

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 <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. 