home news blogs forums events research newsletter whitepapers careers


UBM Network Computing
TechWeb
Visit our SOA/Web Services Immersion Center

IMMERSE YOURSELF:

SOA

  |

Data Center

  |

802.11n

  |

Data Privacy

  |
APO  |

Virtualization

  |

NAC

  |

Security

  |

Network Mgmt

  |

Enterprise Apps

  |

Storage & Servers




Keeping Your Internet Investment Safe

By Robert Moskowitz
our customizable newsletter, sends you security alerts, product updates and software patches on the products you use. Sign up now at www.networkcomputing.com /express/
 We go to great lengths to set policy on our firewalls. We review each protocol and decide what we should let through for whom. But just when we think we have a working policy, some new application comes in, riding on an existing policy "so as to not require any firewall changes." To those of us responsible for defending our corporations' borders, this is a flagrant violation of our security policies. But, for the typical corporate user, it's a cosmic ride down a wormhole to a good performance award because he or she got the job done easily and looked good doing it--with no concern for the hidden cost.

When the first firewalls went up to protect a handful of companies from the ravages of the Internet, only a few services had to be supported: FTP, SMTP and telnet. Then, along came HTTP and it changed the whole nature of firewalls. In fact, it took some time for firewall vendors to figure out the basics of handling HTTP authentication. Over the past six years, however, firewalls have become increasingly capable of handling HTTP traffic, both outbound and inbound. And the number of firewalls has increased as well. Today, thousands of firewalls are deployed to limit a company's exposure to the Internet. These firewalls are fairly set in their behavior and have become a barrier to new Internet applications.

These new applications want to traverse the firewalls. And the application users typically aren't interested in the corporate Internet security policy; they just want their applications to work. So, Internet-application vendors are using HTTP as a shortcut through firewalls. You, the corporate networkologist, must choose your side--with your security team or with your end users.

There's nothing new about picking an underlying protocol, or substrate, for an application based on market pressures. The Internet community has a long tradition of protocol reuse, dating back to the use of NVT (network virtual terminal) as a substrate for telnet, FTP and SMTP.

Technical rationalizations are always available to confuse the issue. Be prepared to face significant pressure to accept any of them just to move forward. First, there's the familiarity and mind-share argument. It's easier to familiarize programmers with HTTP than train them on a newly created protocol. Then, there's the compatibility concern. If HTTP is used, the new application is "automagically" compatible with widely deployed browsers--and you probably don't need to be reminded that you don't want to upgrade in the middle of the year 2000 conversion. Of course, time-to-market is always a concern, and the ability to reuse existing servers and client libraries can be a very compelling point. Indeed, HTTP server support is needed on the application server anyway, so why not just use it and gain the benefit of CGI scripts for prototyping?

The self-justification is almost comical. Only occasionally do I hear that HTTP's ability to traverse firewalls is what really counts.

Technically, HTTP is a session-layer protocol in the classical OSI model. So is there anything wrong with picking the most-available session layer in the IETF for a new application? It seems that groups working on new protocols like the IPP (Internet Printing Protocol) are determined to use HTTP. But this raises a number of issues for both the corporate manager and the Internet community. Should the application use a different port than the HTTP default of 80? Port 80 works through the firewalls, but results in the standard HTTP server needing to take on this new application function (you can only have one application server on a port on a system). Should the application use traditional HTTP methods or should it define new methods? Standard Web client/server competition will be driving enhancements to those methods that could work against a new application's use of them. Finally, should the application use "http:" URLs or define its own prefix? The answers to these questions will have a long-term impact on your networking and security plans.


Other Articles
by Robert Moskowitz

PSTN's Particularly Pesky Problem
April 15, 1998

Taking The Confusion Out Of Digital Certificates
May 15, 1998

Ask Yourself: In Whom Can You Really Trust?
June 15, 1998

Technology And Trust: The Final Analysis
July 15, 1998

Virtual Private Networks For Sale
August 15, 1998


Other Columnists

Net Results
By Dave Molta
On the Edge
By Art Wittmann

Company Directory
to browse our data, starting with a particular company.

Network Computing Links
allows you to request additional product information from our advertisers.

Print This Page


e-mail E-mail this URL






Ready to take that job and shove it?

Function:

Keyword(s):

State:
SPONSOR
RECENT JOB POSTINGS
CAREER NEWS
Go beyond Google and get vertical. These specialized search sites will help you find the business information you need -- fast.

Ari Balogh was named to the post of chief technology officer as the companys for a "realignment" of employees.










InformationWeek U.S. IT Salary Survey 2008
Salaries for business technology professionals are falling. Here's what you need to know in order to make good hiring decisions and personal career choices. Purchase Today: $299
 
ROLLING RIGHT ALONG
Follow key Network Computing Reviews from conception to completion. This Week: Holistic APM.



Network Computing Reports Emerging Enterprise Podcast Series: Secrets to Success








TechSearch


Microsite of the Week


Powerful Information at Your Fingertips



App Infrastructure   |   Messaging & Collaboration   |   Network & Systems Mgmt   |   Network Infrastructure   |   Security  |   Storage & Servers   |   Wireless   |   Enterprise Apps
About Us  |  Contact Us  |  Site Map  |  Media Kit  |   Briefing Centers
Other Techweb Sites:   InformationWeek Reports  |  Intelligent Enterprise  |  Light Reading  |  InformationWeek
Techweb  |  Dark Reading  |  Network Computing Germany  |   Byte & Switch  |  bMighty  |  Small Biz Resource  |  InformationWeek Analytics
Copyright © 2008  United Business Media LLC  |  Privacy Statement  |  Terms of Service  |  Your California Privacy Rights