I've never spent much time tethered to an Exchange Server, other than on an experimental basis, so I'd forgotten -- or never knew -- that Outlook contacts Exchange on TCP port 135. That is, of course, the same port that Blaster has lately been partying on with wild abandon. I'd also heard that some ISPs had begun blocking 135, on the grounds that it's more trouble than it's worth. As this document from Cox High Speed Internet notes:
Customers who use Microsoft Outlook to connect directly to a Microsoft Exchange server may no longer be able to connect when this port filter is applied. We recommend the use of a Virtual Private Network (VPN) to the company or group who operates the Exchange server. Please contact the network administrator or helpdesk for that company or group for additional details.
Yesterday, PJ Connolly and I discovered the effects of this kind of policy first hand. He's got an Exchange Server 2003 in the test center lab, I've got an Outlook 2003 client in my home lab. You wouldn't normally connect these over the open Internet without using a VPN, but for the purposes of this temporary experiment we thought we could. Yes and no. I have two DSL circuits here, from two different ISPs. One allows me to make that connection, but the other is blocking 135. PJ had the exact same experience from his home lab, which also has two DSL circuits provided by yet another pair of different ISPs. One allows 135 traffic, one blocks it.
(This is, incidentally, a nice opportunity to try out an interesting new feature of Outlook 2003: RPC-over-HTTP, an alternate, special-purpose kind of VPN that's arguably both as secure and more flexible than the standard approach.)
It worries me to see this kind of systematic erosion of end-to-end connectivity. Of course you ought not run unencrypted Exchange traffic over the open Internet in the first place, so maybe we shouldn't mourn the loss of that capability. But I hate to see the vulnerabilities of Windows' RPC implementation tar other uses of RPC. My understanding (which is far from thorough) is that port 135 was used, long before Microsoft glommed onto it, as a rendezvous point for DCE RPC applications -- an endpoint mapper used to convert a partial binding to a host into a complete binding to a host and port.
Given the mess we are in, arguing against blocking 135 at the center rather than at the edge sounds kind of academic, and maybe it is. But once these things are done I don't see how they'll ever be undone. Someday (we can hope) the flaws that provoked these actions will be fixed. But the center will have ceased to be a dumb neutral fabric. Policy that used to reside at the edge will have migrated to the center, and will be difficult (maybe impossible) to dislodge. That doesn't feel good.
Former URL: http://weblog.infoworld.com/udell/2003/09/12.html#a795