> -----Original Message----- > From: Attila Sipos [mailto:[EMAIL PROTECTED] > Sent: Friday, October 31, 2008 2:07 PM > To: Dan Wing; Juha Heinanen; Elwell, John > Cc: [email protected] > Subject: RE: B2B-UA's provide an unsolveable identity problem > (was RE: [Sip] submission of a new I-D: "Dialog Event > foRIdentityVErification") > > Yes, you are right, there are "end-to-end" solutions. > I take back the comment about unsolveable. > > My comments were a bit extreme but I guess I was trying to > say you are always at the mercy of the B2BUA.
Yes, of course. We are also at the mercy of the postal service, IP providers (to forward IP packets), telephone companies to send our tones without interfering with them (remember how their echo cancellers interfered with 9600bps and higher modems?), and all other intermediaries. This is not something new, or unique, to SIP or to B2BUAs/ SBCs. It is an engineering challange to work through. > As we know, the problems with B2BUAs are not because of > problems with UA-to-UA SIP but with the fields and bodies > that B2BUA's change. So, for me, it should be the B2BUA > makers who fix those problems. > > So, in conclusion I would prefer that UA-to-UA works first. RFC4474 works UA-to-UA. As would mutually-authenticated TLS between those UAs. > >>designed solution. Spam won't wait for the IETF. > > Agreed. And finding a solution will take even longer if we > have to consider B2BUAs. With few exceptions, all large ITSPs have SBCs and B2BUAs. > Regards, > Attila > > PS Don't get me wrong, I don't hate B2BUA's, I just think > they should fix their own issues. We need to provide the necessary guidance to what they need to do -- while still allowing them to provide the primary functions for which they are operated. -d > > ________________________________ > > From: Dan Wing [mailto:[EMAIL PROTECTED] > Sent: Fri 31/10/2008 16:21 > To: Attila Sipos; 'Juha Heinanen'; 'Elwell, John' > Cc: [email protected] > Subject: RE: B2B-UA's provide an unsolveable identity problem > (was RE: [Sip] submission of a new I-D: "Dialog Event > foRIdentityVErification") > > > > B2BUAs, and SBCs, need to provide their features to their > customers (service providers), and can *also* provide end-to- > end identity. The two requirements are not mutually exclusive, > and I don't understand what causes that argument to persist. > Please talk to your favorite SBC vendor and ask them. > > And when SIP spam becomes a problem (do you doubt it will?) > it will be much easier if we have a specification that can > solve the problem -- otherwise, vendors will be rushed to > create something that may not work as well as an IETF- > designed solution. Spam won't wait for the IETF. > > -d > > > > > -----Original Message----- > > From: Attila Sipos [mailto:[EMAIL PROTECTED] > > Sent: Friday, October 31, 2008 12:34 AM > > To: Juha Heinanen; Elwell, John > > Cc: [email protected]; Dan Wing > > Subject: B2B-UA's provide an unsolveable identity problem > > (was RE: [Sip] submission of a new I-D: "Dialog Event > > foRIdentityVErification") > > > > >>i strongly disagree. b2bua is just an ua. if you you > > build or deploy > > >>such boxes, it is your headache, not sip wg's. > > > > I agree with Juha here. > > > > Every attempt at fixing identity problems (and they have been clever > > solutions) has been hindered with the "but it won't work > with B2BUAs" > > argument. > > > > The problem is not "it won't work with B2BUAs" - the > problem is that > > B2BUA identity and security problems are unsolveable anyway. A B2BUA > > cannot be forced to do anything because even if you said "it must do > > this and that", a B2BUA can do what it wants anyway (I'm sure > > we've all > > seen this). Even if B2BUAs agreed to do certain things, one would > > always enf up with something else that gets B2B'ed. > > > > It is no different to trying to solve the problem of 2 > > telephones taped > > together. > > > > You can only trust things up to a certain boundary. And the > > boundaries > > of SIP are the UAs. The best that SIP can do is to control > > what happens > > between a UA and another UA (and proxies in between) and that's it. > > > > Regards, > > > > Attila > > > > > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of > > Juha Heinanen > > Sent: 31 October 2008 06:31 > > To: Elwell, John > > Cc: [email protected]; Dan Wing > > Subject: Re: [Sip] submission of a new I-D: "Dialog Event > > foRIdentityVErification" > > > > Elwell, John writes: > > > > > > I support draft-kuthan-sip-derive-00, and hope the WG > > can devote > > > > time and energy to improving and standardizing it to work > well > > > > across a variety of networks. > > > [JRE] I agree. This must include networks that contain > B2BUAs/SBCs. > > > > i strongly disagree. b2bua is just an ua. if you you > build or deploy > > such boxes, it is your headache, not sip wg's. it is > enough that this > > work is based on rfc3261 components. > > > > -- juha > > > > > > _______________________________________________ > > Sip mailing list https://www.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://www.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
