Subject: [mediactrl] Naked SIP or Always Have Control?

From: "Burger, Eric" <[email-masked]>
Date: Fri, 23 Jun 2006 21:18:22 +0100

I think a little clarification could go a long way on whether the
control channel needs to be established before the first INVITE hits the
media server.

For enhanced conferencing, I would offer the control channel does need
to be established before the first INVITE.  However, for IVR or regular
RFC4240 services, clearly we don't need a control channel (possibly at
all).

Make sense?

--------------------------
Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications.
Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper.

---

From: <[email-masked]>
Date: Fri, 23 Jun 2006 21:50:39 +0100

Assuming the use of a control channel, I would offer that the
clarification is that it can work either way - control channel before or
after the first INVITE. Referring back to my June 7 email, I can at
least think of some kind of rationale why we'd want to keep it flexible.
I haven't yet heard any reason to *require* control channel first.

The second, parenthetical, part about whether a control channel is
needed for IVR or 4240 services is a different question. And I think a
good one.

Cheers,

Gary 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Burger,
Eric
Sent: Friday, June 23, 2006 4:23 PM
To: [email-masked]
Subject: [mediactrl] Naked SIP or Always Have Control?

Make sense?

--------------------------
Ubiquity Software does not control or endorse the content, messages or
information found in this mail list and it specifically disclaims any
liability with regard to these communications.
Ubiquity Software reserves the right the restrict access to any
communications in violation of the Terms and Conditions of Use for this
website or as otherwise deemed improper.

---

From: "Even, Roni" <[email-masked]>
Date: Sun, 25 Jun 2006 08:16:40 +0100

Hi,
I agree that those are two separate topics.
As for control channel first - either way will work. The point to notice
is that in order to associate a control request with a SIP user you need
the SIP dialog to be established. My view here is that since the control
channel can be used for multiple sessions and is not related to a
specific call it may make sense to establish the control channel
initially. If you want the whole AS to MS to work on ad-hoc bases then
it is fine to open the control channel when ever you want.

As for Eric point about working without a control channel, it is a good
point, but this will mean that we do not need the AS to MS protocol at
all so my view is that it is not relevant here

Roni Even

> From: [email-masked] [mailto:owner-
> [email-masked]] On Behalf Of [email-masked]
> Sent: Friday, June 23, 2006 11:53 PM
> To: [email-masked]; [email-masked]
> Subject: RE: [mediactrl] Naked SIP or Always Have Control?
>

---

From: "Burger, Eric" <[email-masked]>
Date: Mon, 26 Jun 2006 00:29:02 +0100

Back to one or many control channels:

My biggest problem with one control channel instead of one per
"conference" is the security aspect.

I am REALLY concerned about having a control session be able to
manipulate an existing session.  We need to think long and hard about
how to securely do that, considering that hijacking or listening in on a
conference is a high value target.

-----Original Message-----
From: Even, Roni [mailto:[email-masked]] 
Sent: Sunday, June 25, 2006 3:20 AM
To: [email-masked]; Burger, Eric; [email-masked]
Subject: RE: [mediactrl] Naked SIP or Always Have Control?

Hi,

Roni Even

---

From: "Chris Boulton" <[email-masked]>
Date: Mon, 26 Jun 2006 07:29:47 +0100

[Chris Boulton] Just to probe a bit further - is this an Authentication
or Authorization issue (or both)?  In other words, does this require the
actual control channel being secured (there is already an Editors Note
to add TLS support on the Control channel) or are you thinking that we
need a mechanism to authorize EACH command per conference/dialog.

Chris.

-----Original Message-----
From: Even, Roni [mailto:[email-masked]] 
Sent: Sunday, June 25, 2006 3:20 AM
To: [email-masked]; Burger, Eric; [email-masked]
Subject: RE: [mediactrl] Naked SIP or Always Have Control?

Hi,

Roni Even

Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation.  All unauthorized use, disclosure or distribution is strictly prohibited.  If you are not the addressee, please notify the sender immediately and destroy all copies of this email.  Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding.  Thank you.

---

From: "Even, Roni" <[email-masked]>
Date: Mon, 26 Jun 2006 07:38:56 +0100

Hi,
My view here is that we have one channel (secure) between the AS and MS
as for Eric point I think it applies to the connection between the
participants and the AS and that is where the authorization take place. 
Roni

> [email-masked]] On Behalf Of Chris Boulton
> Sent: Monday, June 26, 2006 9:32 AM
> To: Burger, Eric; [email-masked]
> > clarification is that it can work either way - control channel
before
> or
> Information contained in this e-mail and any attachments are intended
for
> the use of the addressee only, and may contain confidential
information of
> Ubiquity Software Corporation.  All unauthorized use, disclosure or
> distribution is strictly prohibited.  If you are not the addressee,
please
> notify the sender immediately and destroy all copies of this email.
> Unless otherwise expressly agreed in writing signed by an officer of
> Ubiquity Software Corporation, nothing in this communication shall be
> deemed to be legally binding.  Thank you.
> 
>

---

From: "Burger, Eric" <[email-masked]>
Date: Mon, 26 Jun 2006 10:51:37 +0100

Each conference.

Trusted AS 'A' has customer 'a'.  Trusted AS 'B' has customer 'b'.  'b'
gets 'B' to tap into 'a's conference.  TLS doesn't help at all, as 'B'
is trusted.

-----Original Message-----
From: Chris Boulton [mailto:[email-masked]] 
Sent: Monday, June 26, 2006 2:32 AM
To: Burger, Eric; [email-masked]
Subject: RE: [mediactrl] Naked SIP or Always Have Control?

Chris.

-----Original Message-----
From: Even, Roni [mailto:[email-masked]] 
Sent: Sunday, June 25, 2006 3:20 AM
To: [email-masked]; Burger, Eric; [email-masked]
Subject: RE: [mediactrl] Naked SIP or Always Have Control?

Hi,

Roni Even

Information contained in this e-mail and any attachments are intended
for the use of the addressee only, and may contain confidential
information of Ubiquity Software Corporation.  All unauthorized use,
disclosure or distribution is strictly prohibited.  If you are not the
addressee, please notify the sender immediately and destroy all copies
of this email.  Unless otherwise expressly agreed in writing signed by
an officer of Ubiquity Software Corporation, nothing in this
communication shall be deemed to be legally binding.  Thank you.

---

From: "Chris Boulton" <[email-masked]>
Date: Mon, 26 Jun 2006 11:04:31 +0100

Each conference.

[Chris Boulton] Yes - I agree - just wanted to make sure that I was
'getting' the exact requirement.  As you have already pointed out - this
could be very important from a security point of view as well as having
useful SLA properties for policy enforcement between customers.

I wonder exactly where this would fit into the current structure of the
framework.  It seems to fit well at the Framework level (as opposed to
package level) so that it could be leveraged by any 'usage'.  I suppose
it would also be an optional feature - for those deployments that simply
don't care.

Chris.

-----Original Message-----
From: Chris Boulton [mailto:[email-masked]] 
Sent: Monday, June 26, 2006 2:32 AM
To: Burger, Eric; [email-masked]
Subject: RE: [mediactrl] Naked SIP or Always Have Control?

Chris.

-----Original Message-----
From: Even, Roni [mailto:[email-masked]] 
Sent: Sunday, June 25, 2006 3:20 AM
To: [email-masked]; Burger, Eric; [email-masked]
Subject: RE: [mediactrl] Naked SIP or Always Have Control?

Hi,

Roni Even

---

From: "Chris Boulton" <[email-masked]>
Date: Mon, 26 Jun 2006 12:41:58 +0100

Simple question:

Assuming that all the AS and MS are in the Secure Trusted domain of our
network, how does 'b get to tap into 'a's conference??? 

[Chris Boulton] Two companies services MIGHT be hosted on a single AS
e.g. could be a web service.  I think Eric just wants to make sure that
company A does not have the ability to issue a valid command on the
control channel for a conference that has been explicitly created by
company B.  All that the secure connection (TLS) provides you with is an
assertion that the connection entity is valid - not who is issuing
commands.

Chris.

---

From: "Chris Boulton" <[email-masked]>
Date: Mon, 26 Jun 2006 13:00:28 +0100

Certainly that happens.  I would expect the majority of policy
enforcement to be carried out by the application server.  I'm not
advocating - just looking at it from Eric's perspective and trying to
understand the requirement + if it exists.

Chris.

-----Original Message-----
From: Dolly, Martin C, ALABS [mailto:[email-masked]] 
Sent: 26 June 2006 12:57
To: Even, Roni; Chris Boulton; Burger, Eric;
[email-masked]
Subject: RE: [mediactrl] Naked SIP or Always Have Control?

Roni, 

I agree,

Martin 

-----Original Message-----
From: Even, Roni [mailto:[email-masked]] 
Sent: Monday, June 26, 2006 7:47 AM
To: Chris Boulton; Dolly, Martin C, ALABS; Burger, Eric;
[email-masked]
Subject: RE: [mediactrl] Naked SIP or Always Have Control?

Chris,
I understand this, but isn't it the Application server problem to
prevent it in the first place and not the protocol.
Roni

> Sent: Monday, June 26, 2006 2:44 PM
> To: Dolly, Martin C, ALABS; Even, Roni; Burger, Eric;
> [email-masked]
for
information of
please

---

From: "Burger, Eric" <[email-masked]>
Date: Mon, 26 Jun 2006 13:30:24 +0100

That's the point: B is *not* allowed access to A's conferences.  B is
owned by SP B; A is owned by SP A; the MS is owned by Operator M.  No
trust between A and B, even though there is trust between M and A and M
and B.

-----Original Message-----
From: Even, Roni [mailto:[email-masked]] 
Sent: Monday, June 26, 2006 6:20 AM
To: Chris Boulton; Burger, Eric; [email-masked]
Subject: RE: [mediactrl] Naked SIP or Always Have Control?

Eric,
I understand the requirement for securing the access to resources on the
MS. In the example you gave there are two separate connections one from
AS 'A' and the other from AS 'B'. The first security point should be on
the AS preventing user 'b' from getting any information about
conferences for which he is not authorized by AS 'B' to access. My
assumption is that AS 'B' was authenticated by the MS and may be
authorized to access and control the conference of 'a'.

Roni

> Sent: Monday, June 26, 2006 1:06 PM
before

---

From: "Burger, Eric" <[email-masked]>
Date: Mon, 26 Jun 2006 13:30:53 +0100

They are NOT in the Secure Trusted domain - this is the Internet, not
the Intranet.

-----Original Message-----
From: Dolly, Martin C, ALABS [mailto:[email-masked]] 
Sent: Monday, June 26, 2006 6:25 AM
To: Even, Roni; Chris Boulton; Burger, Eric;

Simple question:

-----Original Message-----
[mailto:[email-masked]] On Behalf Of Even,

Eric,

Roni

before

---

From: "Burger, Eric" <[email-masked]>
Date: Mon, 26 Jun 2006 13:35:41 +0100

If this is not a requirement, then we are not working on an Internet
protocol, which means it doesn't belong in the IETF.

The *protocol* has to ensure that the activities of one AS do not
interfere with the activities of another, because we do NOT know they
are in the same administrative domain.  If they are, then we are talking
about creating a protocol that happens to run on IP, but that is NOT an
Internet protocol.

Why do we care?  All we are doing is recreating SS7, with all of the
built-in security flaws that comes with assuming we are all in one,
happy Bell System.  We lost the Bell System forever twenty years ago.
We have to make the Internet assumption that everyone is evil unless
they can prove otherwise.

By the way, do we care about getting our work published?  The Security
AD's will have a field day slicing and dicing an insecure protocol
proposal.

-----Original Message-----
From: Chris Boulton [mailto:[email-masked]] 
Sent: Monday, June 26, 2006 8:03 AM
To: Dolly, Martin C, ALABS; Even, Roni; Burger, Eric;

Chris.

-----Original Message-----
From: Dolly, Martin C, ALABS [mailto:[email-masked]] 
Sent: 26 June 2006 12:57
To: Even, Roni; Chris Boulton; Burger, Eric;

Roni, 

I agree,

Martin 

-----Original Message-----
From: Even, Roni [mailto:[email-masked]] 
Sent: Monday, June 26, 2006 7:47 AM
To: Chris Boulton; Dolly, Martin C, ALABS; Burger, Eric;

Chris,

for
information of
please

---

From: "Chris Boulton" <[email-masked]>
Date: Mon, 26 Jun 2006 16:16:28 +0100

[Chris Boulton] Agreed.