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

From: gregd at research.panasonic.com (Greg Daley)
Date: Thu, 16 Mar 2006 17:54:39 -0500

Dear Dave,

Please let me be clear.

David Barrett wrote:
> It seems to me the key sticking point is deciding which is more important:
> 
> 1) Adhering to the spirit of the IANA
> 2) Creating a system that "just works" as well as Skype
> 
> Clearly, if we can do both, then there's no conflict.  But in the event that
> we can't do both, which wins?
> 
> I think Michael is arguing that the user trumps all (even if it means
> ignoring the IANA).  And I think Greg is arguing that the IANA numbering
> can't be violated (even if it means limiting functionality for users).

I'm not saying it can't be violated, it's just that there
are costs if you do.  Following the leader an putting everything
through the smallest open hole in the firewall isn't a magic bullet.

> Personally, I'm in Michael's camp -- if what we make isn't at least as good
> for users as Skype is today (and remember, it'll only get better), then
> there will be little gain from our effort.
> 
> Thus while I like the idea of using well-known IANA port numbers, and I'm
> eager to find a way to stick within its guidelines, I'm more concerned with
> making the best experience for users.

I personally am not interested in making skype.
Perhaps I am one of the few.

I do not want to do it because it has already been done,
and I think that if we want to make skype we could
save a lot of time and useless bickering by asking
them to come and present the protocol at the BoF.

I want to make something MUCH better than skype, which
sometimes means making different architectural decisions
to their system.  (really!)

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.

I also think that because the administrators know they can
turn it off when they like, they will let it on the network,
whereas corporate IT teams will ban use of applications which
force their way through firewalls.

"users" in this case doesn't mean "individuals".  It really means
"enterprises". Individuals at home don't block outbound ports.

Greg

---

From: hgs at cs.columbia.edu (Henning Schulzrinne)
Date: Thu, 16 Mar 2006 18:09:34 -0500

Maybe we need to step back and see what kind of systems make longer-term 
technical sense. I think we need to distinguish, for example, between 
inbound and outbound firewalls. We seem to have:

- Connection-based: Any connection is ok, as long as it is initiated by 
the inside. Some people erroneously believe that NATs provide this 
functionality.

- Port-based: Probably just encourages cloaking if used for outbound 
filtering, but works reasonably well for limiting inbound connections to 
servers that are authorized and designed to provide that service (as 
opposed to some rogue non-patched IIS server running on a personal laptop).

- Content-based: Deep packet inspection seems to be all the vogue, but I 
think in the end, only true protocol participation is going to be 
useful. In other words, the firewall has to be an outbound proxy (or 
work with a trusted outbound proxy) to make sure that only real protocol 
messages make it in or out. I don't see much hope in preventing 
information leakage - it's just too easy to hide information or tunnel 
protocols in what looks like valid HTML or SIP (steganography). Just 
send your protocol requests in base 64 as Via tokens or in Subject 
headers or in a hundred other ways.

I think it also helps to understand the often unstated motivations for 
these filters, which are somewhat different:

- keep the bad guys from connecting to machines that are not meant to 
provide public services;

- keep bad protocol elements out before the IT guys have had a chance to 
fix the buffer overflow;

- keep stupid, untrustworthy and gullible users (as viewed by the IT 
guys) from connecting to bad guys.

Thus, just saying "firewall" tells us very little without being more 
precise what kind of firewall it is and why it is there.

We are now, however, dangerously close to getting into a discussion on 
session border controllers.

FWIW, 
http://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-biondi/bh-eu-06-biondi-up.pdf 
illustrates that these problems are not merely theoretical.

Henning

---

From: dbarrett at quinthar.com (David Barrett)
Date: Thu, 16 Mar 2006 17:28:28 -0800

> -----Original Message-----
> From: Greg Daley [mailto:gregd at research.panasonic.com]
> Subject: Re: [p2p-sip] Fwd: SIP, ICE, and an Overlay Network
> 

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