Subject: Re: [MEDIACTRL] Call for Consensus: Security Requirements

From: Spencer Dawkins <[email-masked]>
Date: Wed, 02 Jan 2008 09:15:42 -0600

Speaking as chair - 

My understanding from Vancouver was that Jon was not excited about having multiple transport options (between TCP and SCTP - I'm OK with "transport" and "same transport/TLS" options, I'm talking about support for both TCP and SCTP).

Speaking as individual - 

If we are picking between TCP and SCTP, I would prefer to specify SCTP because 

- SCTP supports multihoming at the transport protocol level, while TCP does not, and we seemed to want support for multihoming during our discussions in Vancouver - if we select TCP, applications have to manage multiple connection paths, and

- SCTP allows us to deliver requests "out of order" when a packet is lost - if we selected TCP, all subsequent requests, even independent requests, will not be delivered to an application until a lost packet is detected and retransmitted.

Could other individuals express an opinion about this, on-list? We needed to chat about this after Vancouver anyway - thanks, Scott, for jogging us at yearend.

Spencer
  ----- Original Message ----- 
  From: McGlashan, Scott 
  To: Steve Buko ; Chris Boulton ; Dan York 
  Cc: [email-masked] 
  Sent: Friday, December 21, 2007 9:14 AM
  Subject: RE: [MEDIACTRL] Call for Consensus: Security Requirements

  Yes, I agree. We need to provide TLS for the non-trusted scenarios, but allow bare TCP/SCTP for others.

  Scott

------------------------------------------------------------------------------
  From: Steve Buko [mailto:[email-masked]] 
  Sent: Friday, December 21, 2007 16:11
  To: Chris Boulton; Dan York
  Cc: [email-masked]
  Subject: RE: [MEDIACTRL] Call for Consensus: Security Requirements

  As you say, the majority of today's deployments are in a "trusted" environment and are not encrypted.

  My preference would be to use TCP as the default and if you want security go with TLS.  

  Enforcing TLS as the default is too restrictive IMO.

  Steve

  From: Chris Boulton [mailto:[email-masked]] 
  Sent: Friday, December 21, 2007 9:58 AM
  To: Dan York
  Cc: [email-masked]
  Subject: RE: [MEDIACTRL] Call for Consensus: Security Requirements

  In answer to your 'shall' versus 'will allow the use of some', the latter case ('will...') is really a variant of "should", isn't it? i.e. transport encryption is not mandatory but is allowed.

  [Chris Boulton] Yes - this is the crux of my question.  The current version of the Control Framework allows for TCP and TLS/TCP.

  Personally, I think this kind of communication between the AS and MS is potentially far too sensitive to NOT have transport protection, so my personal position would be "SHALL".   I think it should be mandatory.  If not, you just raise the number of ways that an attacker can attack these systems.  I am, of course, open to being convinced as to why securing the protocol in transit is not important. :-)

  [Chris Boulton] I totally agree with the security aspects.  I am currently on the fence about making something like TLS the default to implement.  This is probably historical in that currently media Servers use SIP INFO - and they not by default encrypted + the majority of today's deployments are in a 'trusted' environment and are not encrypted.

  So - in the Control Framework today we say use TCP and if you want security - go use TLS.  I was happy with that but now I am starting to doubt.

  I am interested in the thoughts of the other MS vendors out there.  The last thing we want to do is impose something that 'hurts' take-up by enforcing something that is not always used.

  Chris.

  My 2 cents,

  Dan

  -- 

  Dan York, CISSP, Director of Emerging Communication Technology

  Office of the CTO    Voxeo Corporation     [email-masked]

  Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com

  Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

  Bring your web applications to the phone.

  Find out how at http://evolution.voxeo.com

   

------------------------------------------------------------------------------

  _______________________________________________
  MEDIACTRL mailing list
  [email-masked]
  https://www1.ietf.org/mailman/listinfo/mediactrl
  Supplemental Web Site:
  http://www.standardstrack.com/ietf/mediactrl
_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "Chris Boulton" <[email-masked]>
Date: Wed, 2 Jan 2008 16:36:07 -0000

Speaking as chair - 

My understanding from Vancouver was that Jon was not excited about
having multiple transport options (between TCP and SCTP - I'm OK with
"transport" and "same transport/TLS" options, I'm talking about support
for both TCP and SCTP).

Speaking as individual - 

If we are picking between TCP and SCTP, I would prefer to specify SCTP
because 

- SCTP supports multihoming at the transport protocol level, while TCP
does not, and we seemed to want support for multihoming during our
discussions in Vancouver - if we select TCP, applications have to manage
multiple connection paths, and

- SCTP allows us to deliver requests "out of order" when a packet is
lost - if we selected TCP, all subsequent requests, even independent
requests, will not be delivered to an application until a lost packet is
detected and retransmitted.

Could other individuals express an opinion about this, on-list?

[Chris Boulton] I totally agree with Spencer's previous points but feel
uneasy about having SCTP as the default protocol.  It would be
interesting to know how many implementations TODAY support SCTP for SIP
(both MS and AS)?  I know for a fact that my AS does not.  I am also
guessing that the MS vendors that I have dealt with over the years also
do not (in fact I have seen more than one that does not support TCP).
While this is not a reason to justify TCP - real world implementation
suggests that we are more likely to get 'running code' and take-up of
this stuff by having TCP (+optional TLS) as the default.  The last thing
we would want is to create a road block on the long journey as soon as
you turn out from your driveway.  If I am a lone voice then fair enough.

Chris.

 We needed to chat about this after Vancouver anyway - thanks, Scott,
for jogging us at yearend.

Spencer

	----- Original Message ----- 

	From: McGlashan, Scott <mailto:[email-masked]>  

	To: Steve Buko <mailto:[email-masked]>  ; Chris Boulton
<mailto:[email-masked]>  ; Dan York <mailto:[email-masked]>  

	Cc: [email-masked] 

	Subject: RE: [MEDIACTRL] Call for Consensus: Security
Requirements

	Yes, I agree. We need to provide TLS for the non-trusted
scenarios, but allow bare TCP/SCTP for others.

	Scott

  _____  

	From: Steve Buko [mailto:[email-masked]] 
	Sent: Friday, December 21, 2007 16:11
	To: Chris Boulton; Dan York
	Cc: [email-masked]
	Subject: RE: [MEDIACTRL] Call for Consensus: Security
Requirements

	As you say, the majority of today's deployments are in a
"trusted" environment and are not encrypted.

	My preference would be to use TCP as the default and if you want
security go with TLS.  

	 

	Steve

	From: Chris Boulton [mailto:[email-masked]] 
	Sent: Friday, December 21, 2007 9:58 AM
	To: Dan York
	Cc: [email-masked]
	Subject: RE: [MEDIACTRL] Call for Consensus: Security
Requirements

	In answer to your 'shall' versus 'will allow the use of some',
the latter case ('will...') is really a variant of "should", isn't it?
i.e. transport encryption is not mandatory but is allowed.

	[Chris Boulton] Yes - this is the crux of my question.  The
current version of the Control Framework allows for TCP and TLS/TCP.

	Personally, I think this kind of communication between the AS
and MS is potentially far too sensitive to NOT have transport
protection, so my personal position would be "SHALL".   I think it
should be mandatory.  If not, you just raise the number of ways that an
attacker can attack these systems.  I am, of course, open to being
convinced as to why securing the protocol in transit is not important.
:-)

	[Chris Boulton] I totally agree with the security aspects.  I am
currently on the fence about making something like TLS the default to
implement.  This is probably historical in that currently media Servers
use SIP INFO - and they not by default encrypted + the majority of
today's deployments are in a 'trusted' environment and are not
encrypted.

	So - in the Control Framework today we say use TCP and if you
want security - go use TLS.  I was happy with that but now I am starting
to doubt.

	I am interested in the thoughts of the other MS vendors out
there.  The last thing we want to do is impose something that 'hurts'
take-up by enforcing something that is not always used.

	Chris.

	My 2 cents,

	Dan

	-- 

	Blogs: http://blogs.voxeo.com
http://www.disruptivetelephony.com

	 

  _____

---

From: Dan York <[email-masked]>
Date: Wed, 2 Jan 2008 11:56:11 -0500

I'll second Chris Boulton's statement here (embedded with "[Chris  
Boulton]...").    I am personally not aware of commercial  
implementations of SCTP.  On the other hand, TCP is well-understood  
and works with firewalls, routers, network equipment, etc.

If we specify SCTP are we then setting ourselves up for a situation  
in which we have to wait for vendors to implement SCTP?  Are we also  
opening a Pandora's box of networking issues?  (ex. corporate ACLs  
that restrict traffic between segments to only TCP and UDP)

My personal preference would be to stick with TCP (or more precisely  
TCP/TLS, but then, that's me as a security guy),
Dan

On Jan 2, 2008, at 11:36 AM, Chris Boulton wrote:

> having multiple transport options (between TCP and SCTP - I'm OK  
> with "transport" and "same transport/TLS" options, I'm talking  
> about support for both TCP and SCTP).
>
>
> Speaking as individual -
>
>
> - SCTP supports multihoming at the transport protocol level, while  
> TCP does not, and we seemed to want support for multihoming during  
> our discussions in Vancouver - if we select TCP, applications have  
> to manage multiple connection paths, and
>
>
> - SCTP allows us to deliver requests "out of order" when a packet  
> is lost - if we selected TCP, all subsequent requests, even  
> independent requests, will not be delivered to an application until  
> a lost packet is detected and retransmitted.
>
>
> [Chris Boulton] I totally agree with Spencer’s previous points but  
> feel uneasy about having SCTP as the default protocol.  It would be  
> interesting to know how many implementations TODAY support SCTP for  
> SIP (both MS and AS)?  I know for a fact that my AS does not.  I am  
> also guessing that the MS vendors that I have dealt with over the  
> years also do not (in fact I have seen more than one that does not  
> support TCP).  While this is not a reason to justify TCP – real  
> world implementation suggests that we are more likely to get  
> ‘running code’ and take-up of this stuff by having TCP (+optional  
> TLS) as the default.  The last thing we would want is to create a  
> road block on the long journey as soon as you turn out from your  
> driveway.  If I am a lone voice then fair enough.
>
>
>
> Chris.
>
>
>
>
>
>  We needed to chat about this after Vancouver anyway - thanks,  
> Scott, for jogging us at yearend.
>
>
> Spencer
>
> As you say, the majority of today’s deployments are in a “trusted”  
> environment and are not encrypted.
>
>
> In answer to your 'shall' versus 'will allow the use of some', the  
> latter case ('will...') is really a variant of "should", isn't it?  
> [Chris Boulton] Yes – this is the crux of my question.  The current  
> version of the Control Framework allows for TCP and TLS/TCP.
>
>
> Personally, I think this kind of communication between the AS and  
> MS is potentially far too sensitive to NOT have transport  
> should be mandatory.  If not, you just raise the number of ways  
> that an attacker can attack these systems.  I am, of course, open  
> to being convinced as to why securing the protocol in transit is  
> not important. :-)
>
>
> currently on the fence about making something like TLS the default  
> to implement.  This is probably historical in that currently media  
> Servers use SIP INFO – and they not by default encrypted + the  
> majority of today’s deployments are in a ‘trusted’ environment and  
> are not encrypted.
>
>
>
> So – in the Control Framework today we say use TCP and if you want  
> security – go use TLS.  I was happy with that but now I am starting  
> to doubt.
>
>
>
> I am interested in the thoughts of the other MS vendors out there.   
> The last thing we want to do is impose something that ‘hurts’ take- 
> up by enforcing something that is not always used.
>
>
>
> Chris.
>
>
>
>
> My 2 cents,
>
> Dan
>
>
> -- 
>

---

From: "Steve Buko" <[email-masked]>
Date: Wed, 2 Jan 2008 12:14:20 -0500

+1 from me.

Reiterating my previous post, my preference is for TCP to be default,
and TLS optional.

Steve Buko

From: Dan York [mailto:[email-masked]] 
Sent: Wednesday, January 02, 2008 11:56 AM
To: Chris Boulton
Cc: [email-masked]
Subject: Re: [MEDIACTRL] Call for Consensus: Security Requirements

I'll second Chris Boulton's statement here (embedded with "[Chris
Boulton]...").    I am personally not aware of commercial
implementations of SCTP.  On the other hand, TCP is well-understood and
works with firewalls, routers, network equipment, etc.

If we specify SCTP are we then setting ourselves up for a situation in
which we have to wait for vendors to implement SCTP?  Are we also
opening a Pandora's box of networking issues?  (ex. corporate ACLs that
restrict traffic between segments to only TCP and UDP)

Dan

 

Speaking as chair - 

Speaking as individual - 

 

Chris.

Spencer

	----- Original Message ----- 

	Cc: [email-masked] 

	Scott

________________________________

	 

	Steve

	 

	Chris.

	My 2 cents,

	Dan

	-- 

	 

________________________________

MEDIACTRL mailing list

[email-masked]

Supplemental Web Site:

--

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 2 Jan 2008 19:21:47 +0100

I can envisage this being used in parallel with a SIP environment where people have chose to run the SIP over SCTP, or over TCP, but not over both. Theat would seem to indicate the same customers wanting to do the same with this protocol.
 
Now in SIP we seem to have ended up with very little textual difference between TCP support and SCTP support. Could you identify why the situation would get any worse with control framework - or are you indicating that the SIP requirements in this are are deficient. Some of this is by specifying that certain flexibility in SCTP is not used, e.g. RFC 4168 specifies that the unordered delivery service is not used.
 
Maybe a quick summary of the requirements of TCP usage versus SCTP usage that we would have to put into the document depending on which was chosen would help this process of identifying whether we have significant differences to specify.
 
Note that my assumption is that whichever of SCTP and TCP get used, some support (and not necessarily usage) of TLS would still be mandatory over the top, as in SIP.
 
regards
 
Keith

	From: Spencer Dawkins [mailto:[email-masked]] 
	Sent: Wednesday, January 02, 2008 3:16 PM
	To: [email-masked]
	Subject: Re: [MEDIACTRL] Call for Consensus: Security Requirements

	Speaking as chair - 

	Speaking as individual - 

	 

	Spencer

		----- Original Message ----- 
		From: McGlashan, Scott <mailto:[email-masked]>  
		To: Steve Buko <mailto:[email-masked]>  ; Chris Boulton <mailto:[email-masked]>  ; Dan York <mailto:[email-masked]>  
		Cc: [email-masked] 
		Sent: Friday, December 21, 2007 9:14 AM
		Subject: RE: [MEDIACTRL] Call for Consensus: Security Requirements

		Scott

		 

		Steve

		 

		 

		Chris.

		My 2 cents,

		Dan

		--

---

From: [email-masked]
Date: Fri, 04 Jan 2008 14:13:26 +0100

I personally agree with Chris. BTW, why should the multiple transport  
options raise an issue?

Simon

-- 
                             _\\|//_
                             ( O-O )
    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                  Computer Science Department
         Phone: +39 081 7683823 -- Fax: +39 081 7684219
                 e-mail: [email-masked]

     <<Molti mi dicono che lo scoraggiamento è l'alibi degli
    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                          oooO
    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/

---

From: "Chris Boulton" <[email-masked]>
Date: Fri, 4 Jan 2008 14:06:27 -0000

[Chris Boulton] I knew there was something else I was going to ask.  So is Jon saying that the model adopted by SIP is wrong (in that they have a default protocol and others are supported)?  I would also like to know why this is such a bad model.  I can certainly see that if we pick one (TCP or SCTP) then someone will immediately start shouting and creating an extension.  It's not as if we are suggesting making UDP default which would just plain silly - imagine that in a protocol :-).

Chris.

Simon

---

From: Spencer Dawkins <[email-masked]>
Date: Fri, 04 Jan 2008 08:56:21 -0600

Since Simon asked ... Quoting from 
http://tools.ietf.org/wg/mediactrl/minutes

"Since Jon has also asked about transport independence. Spencer encouraged 
the group to consider SCTP to support redundent control channels (in 
contrast to "transport independence", which the draft currently specifies), 
but please "pick one way". Is everyone OK if we use SCTP for redundancy? 
(CHAIRS: to poll on-list).

Jon asked the working group to consider whether we NEED transport 
independence. (CHAIRS: to poll on-list)"

So we are...

Thanks,

Spencer

----- Original Message ----- 
From: <[email-masked]>
To: "Chris Boulton" <[email-masked]>
Cc: "Spencer Dawkins" <[email-masked]>; <[email-masked]>
Sent: Friday, January 04, 2008 7:13 AM
Subject: RE: [MEDIACTRL] Call for Consensus: Security Requirements

Simon

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 8 Jan 2008 08:41:35 +0200

Hi,

I support Chris, I think that the default should be TCP with TLS that
must be supported.  This does not mean that you MUST use TLS but you
must support.

My major reason is that we are tying to simplify the deployment. SIP is
using TLS and we should also take into account NAT traversal (ICE or
SBCs may not support SCTP, even TCP is a bit of a challenge)

Roni

From: Chris Boulton [mailto:[email-masked]] 
Sent: Wednesday, January 02, 2008 6:36 PM
To: Spencer Dawkins
Cc: [email-masked]
Subject: RE: [MEDIACTRL] Call for Consensus: Security Requirements

Speaking as chair - 

Speaking as individual - 

 

Chris.

Spencer

	----- Original Message ----- 

	Cc: [email-masked] 

	Scott

	 

	Steve

	 

	Chris.

	My 2 cents,

	Dan

	--

---

From: "Eric Burger" <[email-masked]>
Date: Tue, 8 Jan 2008 14:37:11 -0800

<chair-hat off>
Saying we cannot do SCTP because no one does SCTP today is a total non
sequitur.  No one does mediactrl, either.  Bogus argument that carries
ZERO weight.

<chair-hat on>
Hey folks - let us do the path of least resistance.  TLS over TCP is a
real winner!!!  Go team, go!

From: Even, Roni [mailto:[email-masked]] 
Sent: Tuesday, January 08, 2008 1:42 AM
To: Chris Boulton; Spencer Dawkins
Cc: [email-masked]
Subject: RE: [MEDIACTRL] Call for Consensus: Security Requirements

Hi,

Roni

 

Speaking as chair - 

Speaking as individual - 

 

Chris.

Spencer

	----- Original Message ----- 

	Cc: [email-masked] 

	Scott

	 

	Steve

	 

	Chris.

	My 2 cents,

	Dan

	-- 

	 

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 08 Jan 2008 17:15:06 -0600

Just making sure that Eric and I understand...

:-)

> real winner!!!  Go team, go!

What I'm seeing stated support for, on-list, is TLS as MUST-implement and 
TCP as MAY.

Is there anyone who has either

(1) a requirement for transport-independence or

(2) a requirement for a different transport protocol?

Thanks,

Spencer, as co-chair

---

From: Dan York <[email-masked]>
Date: Tue, 8 Jan 2008 23:23:44 -0500

Spencer,

On Jan 8, 2008, at 6:15 PM, Spencer Dawkins wrote:

> What I'm seeing stated support for, on-list, is TLS as MUST- 
> implement and TCP as MAY.

Maybe I'm just too tired from watching too much NH Primary coverage  
tonight, but don't you have that backwards?

i.e. shouldn't it be TCP as MUST-implement and TLS as MAY?

Dan

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 9 Jan 2008 07:35:30 +0200

Dan,

There is a difference between implement or support and use. The idea is that TLS must be supported; deployments may chose to use TCP. 

BFCP has the same requirement.  BFCP also has an error code that says useTLS

Roni

From: Dan York [mailto:[email-masked]] 
Sent: Wednesday, January 09, 2008 6:24 AM
To: Spencer Dawkins
Cc: [email-masked]
Subject: Re: Call for Consensus: Transport Protocols (was: Re: [MEDIACTRL]Call for Consensus: Security Requirements)

Spencer,

What I'm seeing stated support for, on-list, is TLS as MUST-implement and TCP as MAY.

Maybe I'm just too tired from watching too much NH Primary coverage tonight, but don't you have that backwards?

Dan

--

---

From: Dan York <[email-masked]>
Date: Wed, 9 Jan 2008 08:06:09 -0500

Roni,

Ah... gotcha!  So the idea being that some (probably most)  
deployments might use TCP as the transport.  Others might use SCTP or  
something different.  Regardless, they all MUST use TLS.

Okay, as a "security guy", I *definitely* like this.

Thanks for clarifying,
Dan

On Jan 9, 2008, at 12:35 AM, Even, Roni wrote:

> Dan,
>
> There is a difference between implement or support and use. The  
> idea is that TLS must be supported; deployments may chose to use TCP.
>
> Subject: Re: Call for Consensus: Transport Protocols (was: Re:  
> [MEDIACTRL]Call for Consensus: Security Requirements)
>
>
>
> Spencer,
>
>
>

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 09 Jan 2008 07:35:47 -0600

Hi, Dan,

(1) What Roni said (thanks, Roni, for providing this explanation), and

(2) for the "Others might use SCTP or something different" - ideally you'd be able to plug devices from two different vendors in and have them talk to each other, so if we support multiple underlying-transports (say, TCP and SCTP), we'd also be picking a mandatory-to-implement between TCP and SCTP - again, so that there's a baseline functionality. What Jon was asking us to figure out was whether we have a requirement to support more than one underlying-transport - that's why I'm calling for the sense of the working group in this thread.

Thanks,

Spencer
  ----- Original Message ----- 
  From: Dan York 
  To: Even, Roni 
  Cc: Spencer Dawkins ; [email-masked] 
  Sent: Wednesday, January 09, 2008 7:06 AM
  Subject: Re: Call for Consensus: Transport Protocols (was: Re: [MEDIACTRL]Call for Consensus: Security Requirements)

  Roni,

  Ah... gotcha!  So the idea being that some (probably most) deployments might use TCP as the transport.  Others might use SCTP or something different.  Regardless, they all MUST use TLS.

  Thanks for clarifying,
  Dan

    Dan,

    Roni

----------------------------------------------------------------------------

    Spencer,

    Dan

    --

---

From: [email-masked]
Date: Wed, 09 Jan 2008 14:36:32 +0100

Hi Dan,

I think that what Roni meant is that unencrypted TCP may be used, even  
in TLS over TCP is (strongly) recommended, which is how BFCP works in  
fact: I'm not sure he also meant TLS over SCTP (Roni, please correct  
me if I'm wrong).

About SCTP, I agree with Eric that rejecting it only because it's not  
used yet is definitely a wrong motivation. My guess is that as long as  
all the WGs will think about it like that (and I assume most, if not  
all, WGs do), SCTP will never gather enough interest from deployers.  
My suggestion would be to allow both TCP and SCTP for MediaCtrl,  
*without* of course thinking about mechanisms to replicate on TCP what  
may come natively with SCTP. But if this is going to unbearably slow  
down our work in MediaCtrl, then sticking with TLS/TCP is not going to  
be a problem for me.

Lorenzo

Quoting Dan York <[email-masked]>:

> Roni,
>
> Ah... gotcha!  So the idea being that some (probably most)  deployments
> might use TCP as the transport.  Others might use SCTP or  something
> different.  Regardless, they all MUST use TLS.
>

-- 
Lorenzo Miniero, Junior Researcher
Dipartimento di Informatica e Sistemistica
Università degli Studi di Napoli "Federico II"
Via Claudio 21 -- 80125 Napoli (Italy)
Phone: +390817683821 - Fax: +390817683816
Email: [email-masked]

---

From: Dan York <[email-masked]>
Date: Wed, 9 Jan 2008 08:37:05 -0500

Eric,

> > sequitur.  No one does mediactrl, either.  Bogus argument that  

Respectfully I must disagree. You are mixing apples and oranges.   
mediactrl is essentially an application-layer protocol that rides on  
top of a transport protocol (TCP or SCTP).  SCTP is a transport  
protocol.  They are very different beasts at a network layer.   
Everyone and their brother, sister, mother, father and uncles and  
aunts are creating and implementing application protocols.  But  
pretty much all of them use either TCP or UDP.  To my knowledge there  
are extremely few people *in common usage* implementing new transport  
protocols.

To look at it a different way, if I have a business and want to ship  
boxes from my building out to customers, I can choose to put those  
boxes in cars or vans and have drivers drive them individually to the  
customers.  Or to be more efficient, I can load up a tractor-trailer  
truck and have it drive around. We're use to having both around. The  
roads are built for them. Laws allow them, etc.

So now I have the bright idea that I could get *more* boxes in one  
truck if I used one of those tandem trailer trucks.  Now if I live in  
Texas or Montana with big wide open roads, maybe I can do this.  But  
if I'm here in New England where we took cow paths and turned them  
into streets, I have a serious problem.  The physical infrastructure  
simply won't let me get those long trucks through some of our  
streets.  Above and beyond that, state and local governments have  
made rules that said point-blank that I *can't* have tandem trailer  
trucks on the roads in my state.

If I absolutely want tandem trailer trucks, I have to go on a  
campaign to do three things: 1) educate people and lawmakers about  
the value in tandem trailer trucks and why they would be excellent  
for transporting goods; 2) get them to change the rules; and 3) get  
the physical infrastructure around me upgraded to support the usage  
of tandem trailer trucks. All of this will take time, energy and  
money - and may not ever be widely implemented.  Meanwhile, all my  
products are sitting on the loading dock waiting to be shipped. (And  
since I live in Vermont where we have strong environmental laws, even  
if I wanted either of these ideas (which I don't), they would go  
nowhere.)

Switching to our world...  the network infrastructure, firewall  
rules, router ACLs, etc. are all set for TCP, UDP and ICMP.    
Application-layer protocols that use those transports will generally  
work fine in whatever infrastructure is out there today. Yes, you may  
have to get stricter firewalls or ACLs to open up the necessary  
ports, but it's all well-understood and well-used technology.

If an application protocol were ONLY to use a new transport protocol  
like SCTP, in many (most?) places you would have to: 1) educate the  
firewall and network admin people about what this protocol is, why  
they should allow it, etc., and 2) get them to change their firewall  
rules, router ACLs, etc.; and 3) upgrade some or all of the network  
infrastructure, at least in software, to support SCTP.  In some  
cases, software updates may be available. In other cases you may have  
to wait for vendors to update it.  All of this takes time, energy and  
money... and meanwhile our shiny new application protocol is sitting  
there not being used.

Personally, I think the goal of the IETF should be to develop  
protocols that are going to be actually widely used and deployed. In  
order to do that, we need to look at barriers to deployment - and  
remove them.  Requiring a transport protocol that is not widely  
available yet seems a pretty huge barrier to me.  I think it's  
perfectly fine to mention that SCTP "may" be supported and is better  
for the following reasons... x, y, z... but I don't think it should  
be a requirement.

So, obviously, I *don't* think it's a bogus argument. :-)

My 2 cents,
Dan

---

From: Dan York <[email-masked]>
Date: Wed, 9 Jan 2008 08:49:11 -0500

Lorenzo,

> I think that what Roni meant is that unencrypted TCP may be used,  
> even in TLS over TCP is (strongly) recommended, which is how BFCP  
> works in fact: I'm not sure he also meant TLS over SCTP (Roni,  
> please correct me if I'm wrong).

DY> Ah, yes... I missed Roni's point about "implemented" versus  
"supported".  So TLS *MUST* be *supported* by an implementation of  
the mediactrl protocol, even if it may not in fact be *used* in a  
particular instance.  The MCP implementation must be able to use TLS,  
even if the choice is not to turn it on.  Do I have this correct?

DY> In the meantime, TCP is a MAY because the MCP implementation  
"may" use TCP or it "may" use SCTP.  Got it.  Thanks.
>
> About SCTP, I agree with Eric that rejecting it only because it's  
> not used yet is definitely a wrong motivation. My guess is that as  
> long as all the WGs will think about it like that (and I assume  
> most, if not all, WGs do), SCTP will never gather enough interest  
> from deployers. My suggestion would be to allow both TCP and SCTP  
> for MediaCtrl, *without* of course thinking about mechanisms to  
> replicate on TCP what may come natively with SCTP. But if this is  
> going to unbearably slow down our work in MediaCtrl, then sticking  
> with TLS/TCP is not going to be a problem for me.

DY> You've seen (or will see) my separate reply on the topic.  It  
sounds to me like what is really needed is almost a "marketing  
campaign" for SCTP to convince people involved with networks and  
network equipment about why they should be supporting SCTP.  I will  
admit that in all my work with networks, applications, etc. over the  
past 10-15 years, I'd honestly never really heard of SCTP until  
getting back involved in IETF circles late last year. Admittedly, I  
haven't been working with network infrastructure equipment, but in  
all the various discussions I've been in related to application  
protocols, the requirement to use SCTP has *never* come up.  I was in  
fact surprised to learn that its been around since 2000.

Thanks,
Dan

---

From: "Chris Boulton" <[email-masked]>
Date: Wed, 9 Jan 2008 14:34:20 -0000

[Chris Boulton] Just to make sure we are all on the same page.  It had
never been the intention of the SIP Control Framework to pick 'one'.
Sure, the current draft talks about defaults and it used to have Editors
notes talking about SCTP support.  Lets remember that this discussion
was triggered by our AD saying pick one.  I believe that we have
questioned that decision and all agree that while default support needs
to be stipulated - we should also cover SCTP.  Up until Vancouver - this
has never been in doubt and the intended direction.

Chris.

---

From: "Eric Burger" <[email-masked]>
Date: Wed, 9 Jan 2008 06:42:52 -0800

SCTP, available on:
MacOS
Linux
Windows XP
Windows Vista
Solaris
FreeBSD
NetBSD
AIX (limited)

So, where do you need it that it is not available?

From: Dan York [mailto:[email-masked]] 
Sent: Wednesday, January 09, 2008 8:37 AM
To: Eric Burger
Cc: [email-masked]
Subject: Non non sequiturs... Re: [MEDIACTRL] Call for Consensus:
Security Requirements

Eric, 

Respectfully I must disagree. You are mixing apples and oranges.
mediactrl is essentially an application-layer protocol that rides on top
of a transport protocol (TCP or SCTP).  SCTP is a transport protocol.
They are very different beasts at a network layer.  Everyone and their
brother, sister, mother, father and uncles and aunts are creating and
implementing application protocols.  But pretty much all of them use
either TCP or UDP.  To my knowledge there are extremely few people *in
common usage* implementing new transport protocols.

To look at it a different way, if I have a business and want to ship
boxes from my building out to customers, I can choose to put those boxes
in cars or vans and have drivers drive them individually to the
customers.  Or to be more efficient, I can load up a tractor-trailer
truck and have it drive around. We're use to having both around. The
roads are built for them. Laws allow them, etc.

So now I have the bright idea that I could get *more* boxes in one truck
if I used one of those tandem trailer trucks.  Now if I live in Texas or
Montana with big wide open roads, maybe I can do this.  But if I'm here
in New England where we took cow paths and turned them into streets, I
have a serious problem.  The physical infrastructure simply won't let me
get those long trucks through some of our streets.  Above and beyond
that, state and local governments have made rules that said point-blank
that I *can't* have tandem trailer trucks on the roads in my state.

If I absolutely want tandem trailer trucks, I have to go on a campaign
to do three things: 1) educate people and lawmakers about the value in
tandem trailer trucks and why they would be excellent for transporting
goods; 2) get them to change the rules; and 3) get the physical
infrastructure around me upgraded to support the usage of tandem trailer
trucks. All of this will take time, energy and money - and may not ever
be widely implemented.  Meanwhile, all my products are sitting on the
loading dock waiting to be shipped. (And since I live in Vermont where
we have strong environmental laws, even if I wanted either of these
ideas (which I don't), they would go nowhere.)

Switching to our world...  the network infrastructure, firewall rules,
router ACLs, etc. are all set for TCP, UDP and ICMP.   Application-layer
protocols that use those transports will generally work fine in whatever
infrastructure is out there today. Yes, you may have to get stricter
firewalls or ACLs to open up the necessary ports, but it's all
well-understood and well-used technology.

If an application protocol were ONLY to use a new transport protocol
like SCTP, in many (most?) places you would have to: 1) educate the
firewall and network admin people about what this protocol is, why they
should allow it, etc., and 2) get them to change their firewall rules,
router ACLs, etc.; and 3) upgrade some or all of the network
infrastructure, at least in software, to support SCTP.  In some cases,
software updates may be available. In other cases you may have to wait
for vendors to update it.  All of this takes time, energy and money...
and meanwhile our shiny new application protocol is sitting there not
being used.

Personally, I think the goal of the IETF should be to develop protocols
that are going to be actually widely used and deployed. In order to do
that, we need to look at barriers to deployment - and remove them.
Requiring a transport protocol that is not widely available yet seems a
pretty huge barrier to me.  I think it's perfectly fine to mention that
SCTP "may" be supported and is better for the following reasons... x, y,
z... but I don't think it should be a requirement.

My 2 cents,
Dan

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 9 Jan 2008 16:46:27 +0200

Eric,
Availability of SCTP stack does not give a solution. If I need a full
environment that will include SBCs I will hope that they support TCP I
do not think that they will support SCTP
Roni

> -----Original Message-----
> From: Eric Burger [mailto:[email-masked]]
> Sent: Wednesday, January 09, 2008 4:43 PM
> To: Dan York
> Cc: [email-masked]
> Subject: RE: Non non sequiturs... Re: [MEDIACTRL] Call for Consensus:
> SecurityRequirements
> 
> SCTP, available on:
> MacOS
> Linux
> Windows XP
> Windows Vista
> Solaris
> FreeBSD
> NetBSD
> AIX (limited)
> 
top
> boxes from my building out to customers, I can choose to put those
boxes
> So now I have the bright idea that I could get *more* boxes in one
truck
> firewall and network admin people about what this protocol is, why
they
> Personally, I think the goal of the IETF should be to develop
protocols
> Notice:  This email message, together with any attachments, may
contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and
affiliated
> entities,  that may be confidential,  proprietary,  copyrighted
and/or
> legally privileged, and is intended solely for the use of the
individual
> or entity named in this message. If you are not the intended
recipient,
> and have received this message in error, please immediately return
this by
> email and then delete it.
> 
>

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 9 Jan 2008 15:52:23 +0100

I still se no reason to deviate from much of what SIP has done, except in the area of UDP. So I would summarise as:

-	MUST support and use a reliable transport protocol
-	MUST support TCP, may use TCP or SCTP
-	MUST support TLS.

Note if using SCTP does not use unordered delivery.

Regards

Keith 

> Sent: Tuesday, January 08, 2008 11:15 PM
> To: [email-masked]
> Subject: Call for Consensus: Transport Protocols (was: Re: 
> [MEDIACTRL] Call forConsensus: Security Requirements)
>

---

From: Dan York <[email-masked]>
Date: Wed, 9 Jan 2008 09:55:55 -0500

Eric,

> > <snip>

DY> Nice to know it's in operating systems. (Thanks, I didn't know  
that.) But how about:

- routers
- firewalls
- SBCs
- LAN switches (ex. the ones that do "layer 3 switching")

DY> Both in the operating system/stack level of those devices as well  
as perhaps more importantly in the GUI/administration interfaces.

DY> Key test: You go to a firewall or router administrator and say  
that you need the fw/router ACL changed to allow SCTP to flow between  
box A and box B.  Can he or she pop open their admin screen and  
simply and easily add the rule allowing SCTP?

DY> For instance, is it supported in the GUI of Checkpoint's Firewall-1?

Dan

---

From: "Eric Burger" <[email-masked]>
Date: Wed, 9 Jan 2008 07:14:24 -0800

Checkpoint: no
F5: yes
ACME: no
Cisco: yes
Alcatel-Lucent: too hard to tell if they even do TCP
Nortel: too hard to tell if they even do TCP

What does this mean?

1. If mediactrl is ready RIGHT NOW, then I would buy the argument.

2. Since it looks like at least half the market has SCTP, and *IF* SCTP
is the right thing (interesting we are not discussing that point...),
then mandating SCTP would be a *good* thing, as it would accelerate the
market.

The argument "it isn't deployed" or "it is hard to get through
firewalls" means that MEDIACTRL should be an XML body carried over HTTP
over port 80.

From: Dan York [mailto:[email-masked]] 
Sent: Wednesday, January 09, 2008 9:56 AM
To: Eric Burger
Cc: [email-masked]
Subject: Re: Non non sequiturs... Re: [MEDIACTRL] Call for Consensus:
Security Requirements

Eric, 

- routers
- firewalls
- SBCs

DY> Both in the operating system/stack level of those devices as well as
perhaps more importantly in the GUI/administration interfaces.

DY> Key test: You go to a firewall or router administrator and say that
you need the fw/router ACL changed to allow SCTP to flow between box A
and box B.  Can he or she pop open their admin screen and simply and
easily add the rule allowing SCTP?

Dan

---

From: "MUNSON, GARY A (GARY A)" <[email-masked]>
Date: Wed, 9 Jan 2008 10:58:48 -0500

I think that Keith's summary below is the right essence of what should
be captured (security section or otherwise).

cheers,

Gary

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: Wednesday, January 09, 2008 9:52 AM
To: Spencer Dawkins; [email-masked]
Subject: RE: Call for Consensus: Transport Protocols (was: Re:
[MEDIACTRL]Call forConsensus: Security Requirements)

I still se no reason to deviate from much of what SIP has done, except
in the area of UDP. So I would summarise as:

Regards

Keith

---

From: "Chris Boulton" <[email-masked]>
Date: Wed, 9 Jan 2008 16:06:49 -0000

[Chris Boulton]MediaCtrl over Skype - I like it :-).

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 09 Jan 2008 10:12:12 -0600

From: "Eric Burger" <[email-masked]>

>From Spencer, as co-chair,

I believe Eric was speaking as an individual in this posting.

As an individual, I happen to agree with much of what's been said in this 
thread (and not just on one side of the conversation), but as co-chairs, 
Eric and I are charged with determining what working group consensus *is*, 
not what it *should be*.

Also from Spencer, as co-chair,

Jon has corrected me in private e-mail - he's not asking us to "pick one", 
he's asking if we really need transport independence, because this does show 
up in the protocol.

If you know you MUST be running over SCTP, for instance, you can assume your 
transport protocol would manage multihoming for you. If you know you MAY be 
running over TCP, then you can't assume that the transport protocol will 
handle multihoming, etc. so your application needs to detect and recover 
from path failures.

As Eric pointed out, it would also be useful to have some discussion of 
whether we need anything that SCTP offers, or whether (TLS over) TCP would 
be sufficient for anything we are likely to do anytime soon.

>From Spencer, as individual,

> firewalls" means that MEDIACTRL should be an XML body carried over HTTP

I found this point in Eric's note delightful, of course. But back to your 
regularly scheduled exploration of this topic ;-)

Thanks,

Spencer

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 9 Jan 2008 18:28:52 +0200

I support this!!!!
Roni

> Sent: Wednesday, January 09, 2008 4:52 PM
> I still se no reason to deviate from much of what SIP has done, except in
> the area of UDP. So I would summarise as:
>

---

From: "Tim Melanchuk" <[email-masked]>
Date: Wed, 9 Jan 2008 09:27:09 -0800

and i second this support!!

On Jan 9, 2008 8:28 AM, Even, Roni <[email-masked]> wrote:

> in

---

From: Dan York <[email-masked]>
Date: Wed, 9 Jan 2008 12:30:58 -0500

Eric,

> Nortel: too hard to tell if they even do TCP

DY> (Perhaps that Alcatel-Lucent and Nortel need to get better  
marketing data sheets? ;-)

> > 1. If mediactrl is ready RIGHT NOW, then I would buy the argument.

DY> Agreed.

> is the right thing (interesting we are not discussing that point...),

DY> That actually *is* where the discussion should be. My apologies  
for helping take it down a rat hole.

> then mandating SCTP would be a *good* thing, as it would accelerate  

DY> Perhaps we can agree to disagree on this point.  Well, sort of.   
I don't disagree that mandating SCTP *might* accelerate the market. I  
think there's a couple of variants. If we were to mandate SCTP *only*  
(which it's clear there is little interest in), I think the mediactrl  
protocol would have very little pickup and deployment.  If we mandate  
SCTP *support* but allow the use of TCP, we *might* drive deployment  
of SCTP. Or, we might see people decide that they don't want to  
implement our mediactrl program because their developers don't have  
time to learn about SCTP.  Or they might just ignore our mandate and  
only implement the TCP side.

DY> The key might really be whether or not vendors believe our media  
control protocol is something that they really need to implement  
because it will make their products so much easier, better, etc.  If  
they do, they might be willing to implement SCTP to get the MCP.

> firewalls" means that MEDIACTRL should be an XML body carried over  

DY> Best comment I've seen in this thread!  (Although Chris' add-on  
about Skype was cute, too.)

Regards,
Dan

---

From: "McGlashan, Scott" <[email-masked]>
Date: Wed, 9 Jan 2008 17:32:10 +0000

And I'll third it!

[SCTP is allowed but optional was in an editor's note at some point in the draft].

Scott

________________________________
From: Tim Melanchuk [mailto:[email-masked]]
Sent: Wednesday, January 09, 2008 18:27
To: Even, Roni
Cc: [email-masked]
Subject: Re: Call for Consensus: Transport Protocols (was: Re: [MEDIACTRL]Call forConsensus: Security Requirements)

On Jan 9, 2008 8:28 AM, Even, Roni <[email-masked]<mailto:[email-masked]>> wrote:
I support this!!!!
Roni

> From: DRAGE, Keith (Keith) [mailto:[email-masked] <mailto:[email-masked]> ]
> To: Spencer Dawkins; [email-masked]<mailto:[email-masked]>

---

From: "Adnan Saleem" <[email-masked]>
Date: Wed, 9 Jan 2008 09:48:06 -0800

and I third this support.
 
Adnan

From: Tim Melanchuk [mailto:[email-masked]] 
Sent: January 9, 2008 9:27 AM
To: Even, Roni
Cc: [email-masked]
Subject: Re: Call for Consensus: Transport Protocols (was: Re:
[MEDIACTRL]CallforConsensus: Security Requirements)

	I support this!!!!
	Roni

	> From: DRAGE, Keith (Keith) [mailto:[email-masked] ]

---

From: "Asher Shiratzky" <[email-masked]>
Date: Wed, 9 Jan 2008 19:52:49 +0200

Support with one exception "MUST support TCP, may use SCTP" (remove the
redundant TCP)
 
Asher

From: Adnan Saleem [mailto:[email-masked]] 
Sent: Wednesday, January 09, 2008 7:48 PM
To: Tim Melanchuk; Even, Roni
Cc: [email-masked]
Subject: RE: Call for Consensus: Transport Protocols (was:
Re:[MEDIACTRL]CallforConsensus: Security Requirements)

Adnan

	I support this!!!!
	Roni

---

From: Dan York <[email-masked]>
Date: Wed, 9 Jan 2008 13:18:38 -0500

I support this as well, including Asher's grammatical update.

Dan

On Jan 9, 2008, at 12:52 PM, Asher Shiratzky wrote:

> Support with one exception "MUST support TCP, may use SCTP" (remove  
> the redundant TCP)
>
> Asher
>

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 9 Jan 2008 19:45:19 +0100

What I wrote down was not the specification text, which will presumably be a few more words than this, and I will not be drafting them anyway.

But I am not convinced that what I wrote was grammatically wrong, or that the words were superfluous.

The essence is that all implementations support TCP, and therefore if one entity would normally use SCTP, but the other normally uses TCP and indeed only supports TCP, then the mechanism of communication that is always possible is TCP.

However if I am communication in a relatively closed environment where I know everyone else uses SCTP (which are the examples where SCTP seems to be being deployed on other protocols at the moment), then I know that I will always be able to use SCTP, even if I still have to support TCP.

Regards

Keith 

	From: Dan York [mailto:[email-masked]] 
	Sent: Wednesday, January 09, 2008 6:19 PM
	To: Asher Shiratzky
	Cc: [email-masked]
	Subject: Re: Call for Consensus: Transport Protocols (was:Re:[MEDIACTRL]CallforConsensus: Security Requirements)

	Dan

		Support with one exception "MUST support TCP, may use SCTP" (remove the redundant TCP)
		 
		Asher

		From: Adnan Saleem [mailto:[email-masked]] 
		Sent: Wednesday, January 09, 2008 7:48 PM
		To: Tim Melanchuk; Even, Roni
		Cc: [email-masked]
		Subject: RE: Call for Consensus: Transport Protocols (was: Re:[MEDIACTRL]CallforConsensus: Security Requirements)

		Adnan

		From: Tim Melanchuk [mailto:[email-masked]] 
		Sent: January 9, 2008 9:27 AM
		To: Even, Roni
		Cc: [email-masked]
		Subject: Re: Call for Consensus: Transport Protocols (was: Re: [MEDIACTRL]CallforConsensus: Security Requirements)

			I support this!!!!
			Roni

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 9 Jan 2008 23:40:09 +0200

Asher,

There is a difference between support and use. Support means you must
support it even if you would like to do SCTP. Now when you establish
connection you may use TCP or SCTP

Roni

From: Asher Shiratzky [mailto:[email-masked]] 
Sent: Wednesday, January 09, 2008 7:53 PM
To: Adnan Saleem; Tim Melanchuk; Even, Roni
Cc: [email-masked]
Subject: RE: Call for Consensus: Transport Protocols (was:
Re:[MEDIACTRL]CallforConsensus: Security Requirements)

Asher

Adnan

I support this!!!!
Roni

in

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 9 Jan 2008 23:41:27 +0200

Yes,
You are better with words than me
Roni

> Sent: Wednesday, January 09, 2008 8:45 PM
> To: Dan York; Asher Shiratzky
> Cc: [email-masked]
> Subject: RE: Call for Consensus: Transport
> Protocols(was:Re:[MEDIACTRL]CallforConsensus: Security Requirements)
> 
> What I wrote down was not the specification text, which will presumably be
> a few more words than this, and I will not be drafting them anyway.
> 
> The essence is that all implementations support TCP, and therefore if one
> entity would normally use SCTP, but the other normally uses TCP and indeed
> only supports TCP, then the mechanism of communication that is always
> possible is TCP.
> 
> However if I am communication in a relatively closed environment where I
> know everyone else uses SCTP (which are the examples where SCTP seems to
> be being deployed on other protocols at the moment), then I know that I
> will always be able to use SCTP, even if I still have to support TCP.
> 
> Regards
> 
> Keith
> 
> 
> 	Subject: Re: Call for Consensus: Transport Protocols
> (was:Re:[MEDIACTRL]CallforConsensus: Security Requirements)
> 
>