Subject: [Sip] B2B-UA's provide an unsolveable identity problem (was RE: submission of a new I-D: "Dialog Event foRIdentityVErification")

From: "Attila Sipos" <[email-masked]>
Date: Fri, 31 Oct 2008 07:33:52 -0000

>>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-masked] [mailto:[email-masked]] On Behalf Of
Juha Heinanen
Sent: 31 October 2008 06:31
To: Elwell, John
Cc: [email-masked]; 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-masked] for questions on current sip Use
[email-masked] 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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Fri, 31 Oct 2008 11:30:07 +0100

>  > [JRE] I agree. This must include networks that contain B2BUAs/SBCs.

A B2BUA is a man-in-the-middle, there's no feasible end-to-end scenario here.
-- 
Victor Pascual Ávila

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 31 Oct 2008 09:21:21 -0700

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

> From: Attila Sipos [mailto:[email-masked]] 
> Sent: Friday, October 31, 2008 12:34 AM
> To: Juha Heinanen; Elwell, John
> Subject: B2B-UA's provide an unsolveable identity problem 
> (was RE: [Sip] submission of a new I-D: "Dialog Event 
> foRIdentityVErification")
>

---

From: "Attila Sipos" <[email-masked]>
Date: Fri, 31 Oct 2008 21:06:46 -0000

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.
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.
 
>>designed solution.  Spam won't wait for the IETF.

Agreed.  And finding a solution will take even longer if we have to consider B2BUAs.
 
Regards,
Attila
 
PS Don't get me wrong, I don't hate B2BUA's, I just think they should fix their own issues.

________________________________

From: Dan Wing [mailto:[email-masked]]
Sent: Fri 31/10/2008 16:21
To: Attila Sipos; 'Juha Heinanen'; 'Elwell, John'
Cc: [email-masked]
Subject: RE: B2B-UA's provide an unsolveable identity problem (was RE: [Sip] submission of a new I-D: "Dialog Event foRIdentityVErification")

-d

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 31 Oct 2008 14:42:50 -0700

> Sent: Friday, October 31, 2008 2:07 PM
> To: Dan Wing; Juha Heinanen; Elwell, John
> Cc: [email-masked]
> Subject: RE: B2B-UA's provide an unsolveable identity problem 
> 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.
>

RFC4474 works UA-to-UA.  As would mutually-authenticated
TLS between those UAs.

> Agreed.  And finding a solution will take even longer if we 

With few exceptions, all large ITSPs have SBCs and B2BUAs.

> 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

> Subject: RE: B2B-UA's provide an unsolveable identity problem 
> .

---

From: Dean Willis <[email-masked]>
Date: Fri, 31 Oct 2008 17:02:15 -0500

> A B2BUA is a man-in-the-middle, there's no feasible end-to-end  

One might argue that we could define a "standard B2BUA function for  
optimal transparency". We would then add "Considerations at the  
Standard B2BUA" into every SIP extension.

Would this change what SBCs do to make them application transparent?

I rather doubt it. My sense is that the SBCs do what they do for  
reasons that are not dictated by our specifications, but from the  
valid or invalid perceptions of network operators and the business  
decisions they make in response to those perceptions.

We can tell them that not beating their heads on the wall will reduce  
their cranial pain, but it is entirely possible that they're beating  
their heads because they enjoy it, feel that it will scare away the  
bogeyman, are using it to distract themselves from other self- 
inflicted wounds, don't have anything better to do with their money,  
or have found that ritual head-beating sedates the liability vultures  
and auditing zombies.

Happy Halloween!

--
Dean