Hello,
it's great, that it's now possible to "control" Skype with Group Policies. I think it would be great, if settings made by Group Policies could not be changed by "normal" users. Like the Group Policy settings in IE (Grayed out). Greetings from germany, Michael

Requiring registry hacks to turn off features is not a fix, it is a poor workaround. There needs to be a better version of the program for businesses.
We need a software that we can setup on our Own server. One that does not port hop, circumvent the firewalls, or try to suck up our bandwidth by becoming a Super Node at it's own descretion. We need admin level controls and monitoring, coupled with ease of administration, and the ability to run Intranet, internet, or both, while remaining secure.
I wish I could say Skype does this...instead, me, a died in the wool linux head had to advise our company to remove Skype from all systems, and go with MS Communicator (eeewwww).
Can we fix this? Please?

Hi Kurt,

> There is a lot of work ahead for us — not just in
> the policy area but in security as a whole. Policy
> management is just one part of the process, but it

This is certainly a step in the right direction, and I know that many organisations will appreciate the direction Skype is headed.

> is an important part. Feel free to send your
> thoughts to us at security@skype.com or make reply
> comments to this posting.

Erm...

----- The following addresses had permanent fatal errors -----

(reason: 550 : Recipient address rejected: User
unknown in virtual mailbox table)

So, security@skype.com seems to bounce at the moment. I have feedback and some suggestions on the back of our own evaluation of the new features provided in 3.0. They are in the context of a large international organisation (50k+ users) and but I would prefer to share privately.

I would appreciate it if you can fix your mailbox

Cheers,

Dave.

Hello Kurt, I like the enterprise features.

I understand that it is possible to prevent the Skype client from becomming a supernode. Is is possible to prevent the client from becomming a Relay Host?

Thanks,
Damian

We’re trying to improve the quality of Skype service on our campus based network for our students (Skype is our preferred IM application), and recently we’ve been getting some consistent reports of poor call quality with calls getting clicking noises, jitter, echoes and generally a poor user experience all round.

As a quick overview we’re very well connected – with considerably over provisioned LAN and Internet connectivity.

I’ve checked with http://www.skype.com/security/guide-for-network-admins.pdf and Skype have published the following recommendations for “making your network as skype friendly as possible”

Network administrators can positively impact the quality of Skype communications conducted by their network’s users by tuning the network’s handling of transmission control protocol (TCP) and user datagram protocol (UDP) packets for best Skype performance. By this we mean that network administrators can exercise a great deal of control over their users’ networking experience by adjusting control parameters on networking appliances such as routers, firewalls and network address translation devices. In the broadest possible terms, Skype considers an ideal network configuration to be one that’s set up according to the rules shown in Table 1-1, below.

1. Outgoing TCP connections should be allowed to remote ports 1024 and higher.

Our comment: We do not permit this, as it would negate having a strong default-deny campus firewall. We only permit specific common ports outbound from the network(HTTP, HTTPS, IMAP, POP, etc), and this not only prevents a lot of non-business requirement applications from working (e.g. BitTorrent) but it also prevents a lot of spyware and other malware from calling home.

2. Outgoing TCP connections should be allowed to remote ports 80 and 443.

Our comment: This is fully supported. The access is direct to the internet. No NAT involved (we issue all clients public IP addresses). No filtering. No proxies.

3. Outgoing UDP packets should be allowed to remote ports 1024 and higher. For UDP to be useful to Skype, the NAT must allow for replies to be returned to sent UDP datagrams. (The state of UDP “connections” must be kept for at least 30 seconds, and Skype recommends that these translations be maintained for as long as an hour, if possible.)

Our comment: Again, we do not permit this, for the same reasons in item 1. However, the fact that we are denying UDP traffic will almost certainly make Skype less efficient, and will mean that the side effects of jitter will affect call quality more.

4. The NAT translation should provide consistent translation, meaning that outgoing address translation is usually the same for consecutive outgoing UDP packets.

Our comment: We do not use NAT, so this is a non-issue.

So based upon the fact that I’m adhering to item 2 and item 4, and I can’t see ways of permitting items 1 or 3 just for Skype. Can anyone offer any advice on the above?

Another thing we’ve been asked to look at is that we are not prioritising Skype traffic over the Wifi and Internal network traffic. As far as I can see the Skype application does not adhere to any of the networking standards for classification of packets for prioritisation (IEE 802.1p). Additionally, as Skype traffic is encrypted, and goes to/from random IP addresses over the port designed for HTTPS (port 443) there is nothing that a network administrator can do to apply their own quality of service rules to Skype traffic. However, I can also state that there virtually no chance that the issue is being caused by congestion on the internal network with bandwidth being very much over provisioned throughout. There could be individual point in time issues of congestion on the Wifi network, but this would be the exception rather than the rule, and our wireless controller would be looking out for this and dealing with oversubscription automatically.

Based upon what I have documented above, I would be grateful of any suggestions on any ways that we could identify the source of poor quality creeping into the Skype service, and/or possible improvements that could be made to our LAN infrastructure without compromising on the security offered by a default deny firewall.