The advantage of the CONNECT method is that we don't have to change the behavior associated with INVITE. And we don't have to change what is the mandatory content of INVITE either. (It's not just the SDP).
For example, with CONNECT we want to mandate "no proxy forking". > -----Original Message----- > From: Elwell, John [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 20, 2007 01:07 > To: Audet, Francois (SC100:3055); Paul Kyzivat > Cc: IETF SIP List; Dean Willis > Subject: RE: [Sip] draft-gurbani-sip-sipsec-01 > > 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
