Re: [Sip] Comment on DERIVE and B2BUAs

["Francois Audet" <audet at nortel.com>]

Guys,

Instead of using a SUBSCRIBE or even INFO, it seems appropriate
to use OPTIONS.

By definition, OPTIONS is intended to be routed the same way 
as an INVITE, and therefore would be more likly to end-up at the
right place.  

> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On 
> Behalf Of Dan Wing
> Sent: Tuesday, October 28, 2008 21:16
> To: 'Dean Willis'; 'Elwell, John'
> Cc: sip at ietf.org
> Subject: Re: [Sip] Comment on DERIVE and B2BUAs
> 
> > -----Original Message-----
> > From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On 
> Behalf Of 
> > Dean Willis
> > Sent: Tuesday, October 28, 2008 3:36 PM
> > To: Elwell, John
> > Cc: sip at ietf.org
> > Subject: Re: [Sip] Comment on DERIVE and B2BUAs
> > 
> > Elwell, John wrote:
> > > 
> > > IBC said:
> > >> Since the B2BUA has detailed info of both legs A and B, it is 
> > >> capable of doing needed changes, as replacing call-id 
> and to-tag in 
> > >> Event header. Also, the B2BUA could handle the SUBSCRIBE by its 
> > >> own, this is, becoming a dialog presence server instead of 
> > >> forwarding the SUBSCRIBE to the UA. B2BUA must handle all this 
> > >> stuff since they are, in fact, the end point, not the 
> UA's behind 
> > >> them.
> > >
> > > [JRE] This reduces it to transitive trust, i.e., no better than 
> > > P-Asserted-Identity. The UA that receives the INVITE 
> request has to 
> > > trust its local B2BUA to confirm that the INVITE request 
> really did 
> > > come from the wherever it claimed to have come from.
> > 
> > Since the INVITE is coming from the SBC (even though the SBC was 
> > influenced by something else to get it to send the INVITE), I don't 
> > see a problem with this.
> > 
> > Otherwise said, SBCs are always transitive trust unless we have 
> > end-to-end crypto, in which case we don't really have SBCs.
> > 
> > So?
> 
> I trust my post office to route a package to the "To:" 
> address much more than I trust the "From:" address of a 
> package on my doorstep.  I expect you do, too -- or do you 
> really believe those letters are from Ed McMahon?
> 
> An analogy:  DERIVE (and my old RRC draft) are looking at the 
> characteristics of that package on the doorstep (SIP INVITE), 
> and sending a letter to the "From:" address written on the 
> package, asking "Did you really send that?".  The post office 
> will route that letter correctly, and it will be opened by 
> the addressee, who will say "Yes, I sent you that package", 
> which is routed back to me.  I will *then* pick up the 
> package (the SIP INVITE).
> 
> For additional protection (as described in my RRC draft) from 
> the post office opening that letter and responding on behalf 
> of the addressee (which an SBC or B2BUA might be tempted to 
> do), we could require the addressee to use a wax seal on 
> their reply letter (a signature over their reply).
> 
> -d
> 
> _______________________________________________
> Sip mailing list  https://www.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
> 
_______________________________________________
Sip mailing list  https://www.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