System iNetwork

April 2008

April 1, 2008 4:32 PM

Slow File Transfers in Windows Vista

Dear Doctor,
Our branch office network recently upgraded many workstations to Windows Vista. We've noticed that file transfers to and from these machines and the Internet is much slower — about 10 times slower — than our XP and Mac machines. Yet the same machines can transfer files fine over our VPN to the home office. We use a Cisco PIX firewall for our Internet connection and a Sonicwall VPN appliance for our corporate VPN. I'm perplexed!

Gentle User,
You are not alone in your perplexity. Many Vista users have reported this problem, and Microsoft has explained the behavior and published a workaround.

Windows Vista enables a little-used TCP/IP option called Window Scaling, which allows for more than 65K in a TCP receive window. While useful for high-speed LANs, many edge devices, such as routers and firewalls, don't support this option, causing the performance problem you've observed.

The fix is to simply disable Window Scaling in Vista. You must run the following DOS command as Administrator (right-click the Command Prompt icon and choose "Run as Administrator"):

netsh interface tcp set global
autotuninglevel=disabled

Posted by mbeckman on April 1, 2008 at 4:32 PM | Comments (0)

Deploying Domain Key Identified Mail (DKIM)

Dear Doctor,
In an effort to reduce the amount of phishing e-mail going to our users, I've been asked to set up processing for something called Domain Key Identified Mail (DKIM). I gather DKIM is some kind of encryption system, but I don't have the foggiest idea where to begin to implement it. We currently use CommuniGate Pro mail server running under i5/OS, but the vendor doesn't seem to have much info on the subject.

Gentle User,
Your managers are thinking well to implement Domain Key Identified Mail, as it's one of the best antiphishing tools to come down the pike in a long time. DKIM does use encryption technology, as you suggest, although it does not actually encrypt message content. Phishing target organizations, such as financial institutions, e-commerce sites, and online auctions, increasingly employ DKIM to let users verify that mail purporting to be from one of the target organizations actually is from that organization.

The sending organization digitally signs all of its outgoing mail with a private key and then publishes its public key via DNS. A receiving mail server (called a mail transfer agent, or MTA, in the e-mail biz) uses DNS to check for a Sender Signing Policy (SSP) for the domain of every incoming message. If an SSP exists, the receiving MTA retrieves the public key using another DNS query, then uses that key to verify the digital signature in the incoming message. If the signature is invalid, or nonexistent, the message is fraudulent and gets discarded.

Getting this to work in legacy MTAs, such as CommuniGate Pro, can be challenging. In your case, CGPro's vendor, Stalker Software, has not yet built DKIM into its product. A third-party CGPro plug-in, DomainKeys Helper from Niversoft.com, adds this support to CGPro, but only for Intel-architecture servers, excluding i5/OS (which employs PowerPC architecture). In this situation, the easiest solution is to interpose a DKIM-capable MTA between your MTA and the Internet. You can do this using a separate hardware server or appliance, or on your System i box via Linux under LPAR. With either method, you would configure the front-end MTA to apply the DKIM process to all incoming messages, and pass any not dropped to your i5/OS MTA.

If you're handy with Linux, you could roll your own DKIM MTA using Sendmail (http://www.sendmail.org), an open-source mail server that includes MTA support. Some other open-source MTA's also have DKIM support, as do some e-mail filtering services, for which you pay a per-month, per-mailbox support fee.

Whatever method you choose, a critical prerequisite for DKIM is that your DNS be secure and reliable. If an interloper can compromise DNS, she can bypass DKIM protection. You should ensure that your DNS server code is up to date and fully patched, and that you employ separate DNS servers for inside and outside name resolution. Your inside DNS server must not be open to outside queries, and your external DNS server should not open to recursive queries (called an "open DNS").

Posted by mbeckman on April 1, 2008 at 4:30 PM | Comments (0)