Re: concrete proposal (was RE: third alternative (was RE: [Sip] RE: I dentity after reinvite))

[Paul Kyzivat <pkyzivat at cisco.com>]

I generally agree with Jon and Dave. I've snipped to something I want to 
comment on.

	Paul

David R Oran wrote:
> On Nov 22, 2004, at 8:28 PM, Peterson, Jon wrote:
>
> > We add some text about dialogs, and about the use of the Identity header
> > during a dialog. Obviously, the use of identity for dialog-forming 
> > requests
> > is a no-brainer (this is the standard 'caller-ID' assurance). Futhermore,
> > point out that if the intended second party is actually the connected 
> > party,
> > identity can be supplied normally in requests in the backwards direction.
> > Stipulate that an auth service instantiated in a proxy MUST Record-Route
> > itself in a dialog-forming request, so that the auth service can 
> > recognize a
> > mid-dialog request.
> I think I understand what you mean here, but the words could be better. 
> I think you are saying that "if a sip server acts as an auth service and 
> proxies a request that it auth'ed itself, it MUST record route".

In the general case the two ends of the call are in different domains, 
and so there need to be two auth servers. The initial call setup (from 
Alice to Bob) presumably transits Alice's auth server so that it can be 
signed. Jon's requirement above would require *it* to record route. That 
might be a good thing, so that subsequent requests from Alice can also 
be signed. But that does nothing for requests from Bob to Alice.

There is no guarantee that Bob's auth server is in the path for incoming 
requests from Alict to Bob. Based on the needs of Identity-03 there is 
no need for it to be. If it happened to be, then the requirement that it 
record-route might be helpful in giving it the opportunity to sign 
future outbound requests in the dialog.

If it wasn't in the path initially, then Bob will have to add a Route 
header, in addition to what is received in Record-Route, to involve it 
when sending subsequent requests within the dialog.

It seems to me that depending on how the network components are 
constructed, either the auth server will be collocated with a component 
that is naturally on the path, or else each end will have to manipulate 
the Route headers to ensure it is. (It would naturally be on the path if 
 it was collocated with teh proxy managing the user's AOR and the user 
uses a GRUU managed by the same proxy for contacts.)

	Paul


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip