But maybe the INVITE could contain minimal information, e.g., an SDP offer with no media. Note that METHOD/Replaces cannot be sent to a UAS during an early dialog, so CONNECT/Replaces would have to be sent in the backwards direction.
Also we would need to consider what happens if the regular INVITE arrives at a proxy or UAS that does not support sipsec. May need to use Require/Proxy-Require, or maybe we could achieve some sort of best effort security by not requiring sipsec support. John > -----Original Message----- > From: Francois Audet [mailto:[EMAIL PROTECTED] > Sent: 19 June 2007 23:59 > To: Paul Kyzivat; Elwell, John > Cc: IETF SIP List; Dean Willis > Subject: RE: [Sip] draft-gurbani-sip-sipsec-01 > > Yeah, we tought about that. > > The problem is that the INVITE is loaded with too much > information that > would then > leak. > > The idea of the CONNECT is that it would have the bare > minimum to route. > Then the full > blown end-to-end secure INVITE (with the SDP) could be exchanged. > > > -----Original Message----- > > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, June 19, 2007 15:52 > > To: Elwell, John > > Cc: Vijay K. Gurbani; Audet, Francois (SC100:3055); IETF SIP > > List; Dean Willis > > Subject: Re: [Sip] draft-gurbani-sip-sipsec-01 > > > > > > > > Elwell, John wrote: > > > Vijay, > > > > > > This deals with straightforward forking scenarios. What > > about a proxy > > > that is scripted to fork in parallel to two destinations, > > and then, if > > > they both fail to answer, fork to a third destination? Or a > > proxy that > > > is scripted to forward to one destination, and then, if > it fails to > > > answer after a certain time, fork to a second location without > > > cancelling the request at the first destination? > > > > Some of these cases can be handled by attaching q-values to > > the contacts in the 3xx, if the UA cooperates by doing the > > ones with equal q-value in parallel and the ones with > > different q-values in descending q-value order. > > > > But it doesn't deal with more complex policy. And of course > > if this is done by the callee's home proxy then it can be > > certain the policy is followed. If it is deferred to the > > caller then you can't be sure. > > > > Of course this is to some extent a battle over who's policy > > should be followed, and there is no single right answer here. > > But its probably safe to assume that many callee's won't want > > to give up control over this. > > > > An alternative I suggested earlier, that nobody commented on, > > is to start out with a regular INVITE, which can potentially > > fork. After a dialog is established, do a CONNECT/Replaces to > > establish a secure session to the target. This could be done > > during an early dialog, or after the final dialog is > > established. This could be triggered by presence of > > "Supported:sipsec" in the response. > > > > Paul > > > > > John > > > > > >> -----Original Message----- > > >> From: Vijay K. Gurbani [mailto:[EMAIL PROTECTED] > > >> Sent: 19 June 2007 17:35 > > >> To: Francois Audet > > >> Cc: IETF SIP List; Paul Kyzivat; Dean Willis; Elwell, John > > >> Subject: Re: [Sip] draft-gurbani-sip-sipsec-01 > > >> > > >> Francois Audet wrote: > > >>> Agreed. > > >>> > > >>> Basically, say the "CONNECT" ended up in 3 different > > >> directions after > > >>> a 3XX with 3 contacts. The UAC would set up the end-to-end TLS > > >>> connections from the UAC to the 3 contacts. > > >>> > > >>> Then the INVITEs have no intermediaries, so they can't fork. > > >> OK; returning a 3xx seems to be preferred. Then, so that we can > > >> update the next revision appropriately, here is some rough text: > > >> > > >> A proxy that accesses a location service to route a CONNECT > > >> request and discovers more than one contact bound to that > > >> AoR MUST format a 3xx-class response with the contacts > > discovered > > >> from the location service. This response is subsequently > > >> sent upstream. > > >> > > >> A proxy that receives a 3xx-class response as a result of > > >> proxying a CONNECT request downstream MUST NOT recurse on the > > >> receipt of the 3xx-class response. Instead, it MUST send the > > >> response upstream. > > >> > > >> When a user agent receives a 3xx-class response from its > > >> downstream server with multiple Contact headers, it MAY decide > > >> to fork in parallel or in serial depending on its software > > >> capabilities and configuration policies. Alternatively, it > > >> MAY analyze the received Contact headers and choose to send it > > >> to a particular destination that it suspects would stand the > > >> best chance of eliciting a successful response. > > >> > > >> OK? > > >> > > >> - vijay > > >> -- > > >> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > > >> 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > > >> Email: [EMAIL PROTECTED],bell-labs.com,acm.org} > > >> WWW: http://www.alcatel-lucent.com/bell-labs > > >> > > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
