Subject: [p2p-sip] SIP, ICE, and an Overlay Network

From: slavitch at objectworld.com (Michael Slavitch)
Date: Thu, 16 Mar 2006 20:20:20 -0500

I'm not sure how limited WebDAV is.  An entire industry is built around
it.

It gives me encrypted r/w access to a whole file system with local
security credentials, replacing the need for a VPN or configuring NAT
firewalls as long as I have accessed to a common server. No more worry
about NFS, SMB, whatever. All I need is WEBDAV and credentials. This is
a good thing.  A Mac that doesn't run SMB can get data from an XP box if
it can log in. No more futzing or fussing or configuring. It is
automatic. 

It allows a company in Cupertino to actually make money selling music by
making it easier to buy than steal.

My local university uses Webdav to offer video archives to its students
so they can catch up on lectures.

Whiteboard collaboration, remote terminals, database read/write, all can
and is being done with WEBDAV, which is RFC status.  WEBDAV is hardly
trivial because it allows you to do pretty well anything over port 443,
except for real-time streaming media.  

That it cannot do, for real time media doesn't work with get/put except
at teletype rates. 

P2PSIP adds media, once done an entire Internet experience can be
encapsulated using two IETF standard protocols.  

All over a single port that is secured and well understood with a
well-described and well-respected protocol, something so well respected
it is used for financial transactions by big conservative banks.   

"I don't know why you're so against it."

Because in practise it no longer exists. It existed in an ancient static
internet that didn't have session establishment protocols and protocol
overloading. Fixed ports were needed pre-SIP and pre-HTTP because there
was no better alternative.  Applications decide on content, not the
protocol.

If the argument is that it cannot be done then the WEBDAV RFC must be
deprecated. There is no alternative.

If WebDav is allowed to remain then P2PSIP should be allowed to follow
its lead. You just can't say yes to one and no to another, especially
when the truth in the field is that well-known numbering no longer
exists in practise except for DNS, SMTP, and HTTP/HTTPS.  

M

Michael Slavitch           Lead, Strategic Initiatives 
slavitch at objectworld.com   Objectworld Communications Corp. 
+1.613.599.9698 .225       Ottawa, Ontario, Canada

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Greg Daley
Sent: March 16, 2006 2:27 PM
To: Michael Slavitch
Cc: P2P-SIP
Subject: Re: [p2p-sip] SIP, ICE, and an Overlay Network

Hi Michael,

Michael Slavitch wrote:
> If WebDav passed security AD's, so must P2PSIP/HTTPS.
> 
> E-commerce occurs using WebDav so security is I assume under control 
> in the application layer.

You've essentially picked a limited, assymmetric application which
requires a server to illustrate how security will work in a P2P network.
Sure it's fine for file storage.  There are only a finite number of
operations you can do.

Saying something is possible doesn't mean it's a good match, though.

Providing explicit protocol/port identification allows straightforward
troubleshooting and control.  Sure it doesn't always work, but it's the
principle that most firewalls are based upon today, and matches the
paradigm.

I don't know why you're so against it. Perhaps you have an esoteric
reason you could reveal to the group?

Greg

_______________________________________________
p2p-sip mailing list
p2p-sip at cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip

--

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

This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. 

Any views, opinions and content presented in this e-mail are solely those of the author and may not represent those of Objectworld Communications Corp.

---

From: slavitch at objectworld.com (Michael Slavitch)
Date: Thu, 16 Mar 2006 20:24:17 -0500

"We're going to have to allow inbound traffic.  Why not have a well
known port?" 

Because we have to also deal with RTP. We already have to do NAT
traversal. 
By definition if there is NAT traversal well-known ports go out the
window.
Symmetric UDP is about a big a break of firewall security as there can
be.
Those ports are not only opened, they are opened dynamically both
outbound and in.

M

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Greg Daley
Sent: March 16, 2006 2:07 PM
To: Michael Slavitch
Cc: P2P-SIP
Subject: Re: [p2p-sip] Fwd: SIP, ICE, and an Overlay Network

Hi Michael,

You are missing the point.
I'm not for relying on port numbers for security.

I'm for not overloading the mechanisms _yet again_ and allowing systems
administrators to:

1) Identify the traffic on the network

2) Provide basic policy control.

People will certainly be able to tunnel stuff out of the network using
customized tools.  I'm just saying we shouldn't build our protocol on
top of the idea.  Put P2P over SIP over HTTP over SSH over DNS if you
like, just don't propose it when other people are having a serious
attempt at chartering a working group.

People will think the group hasn't made a serious consideration of
operational security requirements.

It's also worth considering that while _outbound_ HTTP HTTPS and DNS are
common on the Internet.  How many companies allow them inbound?

We're going to have to allow inbound traffic.  Why not have a well known
port?

Greg

Michael Slavitch wrote:
> Forwarded to the list.
> 
> ---------- Forwarded message ----------
> From: Michael Slavitch <slavitch at gmail.com>
> Date: Mar 16, 2006 1:25 PM
> To: Greg Daley <gregd at research.panasonic.com>
> 
> 
> Depending on port numbers for security becomes silly when NAT 
> traversal comes into play.
> If your customers depend on static numbering they are truly kidding 
> themselves. How is it not easily identifiable?  It is a content lookup

> on http.  It is polite, W3 stuff. So what is a well-known number?  I 
> get access to my file system over WEBDAV. WEBDAV runs over http1.1, 
> giving me access to an entire network structure over http. Outlook and

> Exchange use 443 for reading and writing email if you so choose, and 
> if your settings are correct you have access to a file system through 
> outlook.  Streaming video, voice, you name it  runs over 80 or 443.
> Google mail pop access is over 995 and something else.
> 
> I have 2G of disk space on my gmail drive, which I can get access to
over 443.
> 
> A clever hack to get around a firewall guessing about access is to 
> have the equivalent of a secure-id card on  a web server,  an http get

> request gives you a server port number that only responds to your 
> request (an interesting abstraction of STUN).
> 
> If the firewall cannot read content the firewall is useless.  NAT 
> traversal by definition breaks the well-known number rule so that must

> be off the table.
> 
> A few years ago I got tired of a rather nasty firewall and I put an 
> ssh server on port 443, and with port tunneling I made an instant
> homebrew VPN in a few minutes.   The security officer at this firm
> insisted that this was impossible,  and didn't understand it even when

> I showed him (I was doing a network analysis, it was part of my job).
> 
> Depending on 'well-known numbers' when the world can run anything over

> 80 or 443 means that your customers do not have a firewall, they have 
> a port restrictor.
> 
> Security through stupidity isn't security.
> 
> M
> 
> 
> On 3/16/06, Greg Daley <gregd at research.panasonic.com> wrote:
>> Hi Michael,
>>
>> Michael Slavitch wrote:
>>> In such a case a nice P2P protocol would set the HTTP request header

>>> user agent designator to be something truly 'P2PSIP', keeping the 
>>> firewall guys happy. Make it politically correct, make it nice, and 
>>> make it work.
>>>
>>> This means that existing firewalls could support P2PSIP monitoring 
>>> without any state changes, only a new policy.
>>> This would make them and their customers very happy and remove a 
>>> pain point as discussed yesterday at VON.
>>>
>>> It is an interesting way of solving the problem, and making 
>>> bootstrap/configuration friendly and polite.
>>>
>>> M
>> We don't want to do this, as it requires modification of proxy and 
>> firewall infrastructure.
>>
>> There is a reason why we have assigned port numbers.
>> It's so people can tell what's travelling on a certain port.
>>
>> If an admin has to install a new firewall or proxy (or upgrade) in 
>> order to stop access of VoIP across my network boundary, they're 
>> either going to be upset at IETF, or not going to let the software be

>> deployed at all on the network.
>>
>> So we should have a protocol which is easily identifiable, and easily

>> blockable (conversely easily openable if need be).  The security ADs 
>> would eat us for dinner if we proposed http traversal just to get 
>> around an organization's legitimately configured firewall.
>>
>> Let proprietary vendors do it, and we'll see which protocol is left 
>> on the corporate LAN.
>>
>> Greg
> Michael Slavitch
> Ottawa, Ontario Canada
> Michael Slavitch
> Ottawa, Ontario Canada

--

---

From: slavitch at objectworld.com (Michael Slavitch)
Date: Thu, 16 Mar 2006 20:46:06 -0500

"I certainly support the notion of keeping admins in control of their
networks."

What gives more clear control than an HTTP request header user agent
designator? - "No X allowed here sorry. Go use something else, like
this."
In the extreme case the designator can be overloaded to contain a cert.
In that case the admin can permit/exclude traffic on a strong policy
basis guaranteeing security and identity, and the failure mode can
include an informative redirect to a third party so that it is well
understood to not be a man-in-the-middle attack.  In HTTP-land these are
well-established and well-done things, allowing as much administrative
control as one can muster. 

In SIP this is an open research item. Why?

A well-known port is a port is a port. That is VAX-era stuff.

M

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David Barrett
Sent: March 16, 2006 5:28 PM
To: 'Greg Daley'
Cc: 'P2P-SIP'
Subject: Re: [p2p-sip] Fwd: SIP, ICE, and an Overlay Network

> From: Greg Daley [mailto:gregd at research.panasonic.com]
> So if administrators can switch off P2P SIP at the firewall, and 
> direct their people to use a CS/SIP proxy as a gateway, while having 
> completely unrestricted (and otherwise serverless and unmanaged: 
> actually the proxy could be configured off the overlay) access within 
> the LAN, I think this interoperability is a selling point.

Ah, awesome, now I understand what you're saying.  Yes, this sounds like
a good vision.  The trick is distinguishing between environments that
explicitly block SIP due to some active policy, versus environments that
accidentally block SIP due to some combination of misconfigurations.

Skype takes an 'opt out' approach where, unless you explicitly block
access to the central authentication servers, Skype will do everything
it can to figure out a way to work (including tunneling over other
ports).

SIP currently takes an 'opt in' approach where, unless everything is
tuned in just right, it assumes it's not supposed to work (and doesn't
try to tunnel). 

I certainly support the notion of keeping admins in control of their
networks.  But I lean towards making PSP-SIP more of an 'opt out'
service like Skype, than maintaining the current 'opt in' bias.
Effective NAT penetration is one big step in this direction; I think
opt-out firewall tunneling is another good move.

-david

--