Subject: RE: [Sipping] comments on draft-peterson-sipping-retarget

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 4 Mar 2005 15:41:29 -0500

Because the 3xx response comes directly from that intermediary to the UAC. The UAC can form a direct TLS connection, say, to the redirecting host, and use the certificate passed by TLS as the authentication of the sender of the 3xx. The only reason why 3xx responses would not be sent directly from the intermediary to the UAC in this fashion is, of course, because of trapezoid-ish retargeting architectures. 

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Friday, March 04, 2005 11:53 AM
> To: Peterson, Jon
> Cc: Jonathan Rosenberg; sipping
> Subject: Re: [Sipping] comments on draft-peterson-sipping-retarget
> 
> 
> 
> 
> Peterson, Jon wrote:
> 
> >>The introduction also talks about the primary problem being 
> that you 
> >>can't trust the intermediaries to properly retarget. 
> However, if you 
> >>can't trust the proxies, you can't trust them to redirect 
> instead of 
> >>retarget...
> > 
> > The differences are enormous, actually, in so far as you 
> can actually see -which- intermediary redirects, but you 
> cannot determine which intermediary retargets. Because you 
> can see which intermediary it is, you can determine whether 
> or not they are actually authorized to change the target of 
> the request. I don't think you can be said to trust an entity 
> taking an action during routing the call if you don't even 
> know who that entity is...
> 
> How is it that the UAC can *see* which intermediary redirected?
> 
> 	Paul
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 04 Mar 2005 15:53:35 -0500

> Because the 3xx response comes directly from that intermediary to the UAC. The UAC can form a direct TLS connection, say, to the redirecting host, and use the certificate passed by TLS as the authe…

So you are excluding even the explicit introduction of intermediaries by 
the UAC - forcing the UAC to go direct to the proxy authoritative for 
the target. That seems to be throwing out the baby with the bath water.

Proxies that don't retarget - that are visited because of Route headers 
- are quite valuable. It isn't going to be very appealing if every phone 
that wants to make a call has to extablish a new TLS connection.

	Paul