Thanks for all your replies.

What I was looking for was less along the lines of "you really should
not do this" and more "it's a bad idea, but if you tweak X then you
can get reasonable call quality and still not open the floodgates for
Limewire and IRCbot-Q9".

I will pass along the "you really should not do this" sentiment to our
CSO, but he's already heard more than enough along those lines from me
and my peers.

On 8/26/06, Paul D. Robertson wrote:
> On Fri, 25 Aug 2006, Kevin wrote:
> > I wish I could.

> Then you've failed policy 101.

No argument here. I've already proposed looking at other
(standards-compliant) VOIP carriers. When the replies from above
state "we have to do this." and " We are using Skpye. We need options
on how to make Skype work.", it becomes abundantly clear that my
options have been whittled down to:
A) Make it work (with reasonable reliability and call quality).
B) Find a new workplace.

> > the actual requirement is that the buzzword-friendly
> > Skype desktop application must work. No excuses.

> If your security policy doesn't enumerate the process for allowing
> applications to work through the firewall, applications allowed to work
> through the firewall and a procedure for evaluating and approving such,
> then it's not complete.

The policy provides a process to add new allowed applications, but a
very limited process for evaluating and approving new applications and

Our process is designed around the ability to quantify the risk of
enabling a new application or protocol, so management can balance this
against the "opportunity cost" of denying the request. The question
is unanswerable when the application and protocol are designed to
resist analysis, and so far I haven't found any option to limit the
exposure from the policy change necessary for Skype to function
through a firewall.

> Oh, sorry Citrix Metaframe is the right answer there.

The goal is as much "key staff use Skype at home and on the road, and
want the same contact list and UI when in the office" as it is the
potential for cost savings from free long-distance and dirt cheap
international calling. A Metaframe deployment would eat these savings
for breakfast.

> > > 3. Deny the request as unreasonablely out of kilter with the security
> > > policy in place and make them do the requirement over.

Tried this. The only acceptable reply that begins with "Request
Denied" will be one that ends with " I respectfully resign my

> 5. Allow it with the stream QoSed down to unusable with random packet
> dropping, latency and declare it "must not work with our firewall."

Actually, Skype legitimately does not work with our firewall, no QoS necessary.
If I turn off all the advanced protection features I can get get Skype
to connect, but call quality is poor, and calls are dropped seemingly
at random.

That's why I posted the original message.

On 8/26/06, Paul D. Robertson wrote:
>On 8/25/06, Patrick M. Hausen wrote:
>> If you are working for a big enterprise, have the company lawyer read it.
>> Short version of the last Skype license I read: "Skype owns your PC".
>> I have been able to talk every single customer out of "make Skype
>> work" by simply kindly asking them to read the license first and
>> _really_ read and understand it.

>Nice- wonder if there's a good Sarbaines Oxley blocking vector in there
>for those affected by it.

Thanks for the idea, I'll give that a try on Tuesday.


How to say "I quit" with style and grace... or not.
firewall-wizards mailing list