Business Drivers for Extranets
The market for extranet connections is growing because corporations are motivated to:
- Extend their B2B connections to existing partners (Today, an average of only 37% of corporations are connected with their business partners, usually with basic data exchanges such as EDI VANs (1) )
- Expand these connections beyond data exchanges to direct real-time access of data and applications
- Connect with new partners as a result of outsourcing
Many corporations simply want to extend certain internal applications to business partners, treating their business partners like a special class of employee with limited privileges. The drivers for this increased connectivity are well documented for partners who have achieved deeper levels of connectivity to business partners beyond data exchange (2) :
- 15-25% inventory reductions
- 20-40% reductions in lead time
- Major improvements in customer loyalty
"Companies in a supply chain react to the lack of real time information by building up their inventories as a defense mechanism. The opportunity to replace inventories with information to free up 10-15% of inventory gets the CEO or CFO interested." (Internet Week May 2001)
| (1) | Information Week Survey, September 2001 |
| (2) | Giga Information Group: Business Process Integration, March 2000 |
The VPN Paradox
For the past several years, vendors have touted VPNs as the natural solution for leveraging the lower cost Internet medium to support intranets, remote access, e-commerce, and extranets. While VPNs have made significant progress in replacing dial and leased lines for RAS and intranet connections, they have fallen short when it comes to Extranets. In general VPNs are ill suited to building multi-company extranets (1) or any situation that extends across organizational boundaries or where there is unbalanced trust between end points.
| (1) | Jim Slaby, Giga Information Group |
Why VPNs and Extranets Don't Mix
According to Giga Information Group, the reasons for VPNs' extranet failings are more operational than technical, though to be sure both technical and financial reasons line up alongside those operational impediments.
IPSec Virtual Private Networks assume common administrative control of both ends of a connection. Administrators at each end must coordinate everything from shared key exchanges to encryption modes, fallback modes, IP addressing, firewall configurations, and security policies. A partner must coordinate with his counterparts any changes to these parameters. All this to establish a private network connection, and private does not mean secure.
A VPN establishes an encrypted tunnel between two or more networks (private). A compromised workstation or unethical user can reach across into the partner's network and wreak havoc on systems and network elements he is not authorized to use and to which he should have no visibility (insecure). Most organizations reduce the scope of possible damage by replicating key servers and databases on demilitarized zones (DMZs), but this is expensive and only partially effective.
In a typical B2B hub-and-spoke topology the hub partner must also be concerned with limiting access from one spoke partner to another. While there may be valid reasons for the spokes to share data, they are often competitors who must remain isolated.
On the technical front, VPNs in extranets have run into the "standards" problem. The IPSec family has been implemented to varying degrees by a number of vendors, all of whom can claim conformity. As witnessed by the failures of industry consortia as large as ANX, implementing multi-vendor VPNs can be excruciatingly painful.
IP addressing is also a cause for complexity in the VPN extranet. As organizations embraced private IP addresses (IETF RFC 1918) on their intranets, they didn't anticipate coordinating extranet connections with partners running the same internal addressing scheme. Network administrators that successfully emerge from the Network Address Translation maze often discover that the applications they wish to share across the extranet can't handle NAT at least when encapsulated in IPSec.
Post-Modern VPN Alternatives
Following the rise and fall of VPN hype, and in parallel to the browser's emergence as the common Internet terminal emulator, a variety of potential solutions to the extranet problem have emerged. First is the private circuit, whose death has been greatly exaggerated. Private circuits can transport any application, are highly secure, and allow controllable QoS. Yet they are expensive and inflexible, and corporations use them in only the absence of a viable alternative.
Other approaches, such as thin client solutions, permit corporations to share limited types of applications with partners. Installation time can be lengthy and require a large investment in duplicative servers, but often yields savings in WAN costs. Web-enablement makes sense for some situations, but corporations that rely on homegrown or other legacy applications are often leery of costly recoding projects that don't directly contribute to the bottom line.
This has led to the emergence of a passel of proxy-based remote access solutions designed to offload the effort of exporting applications. Unfortunately, these solutions merely provide secure access to already-webified applications and at best a few widely used office automation tools. Corporations with anything off the beaten path have to wait for the proxy vendor to write code for them.
Web Services will undoubtedly play a role in helping corporations advertise the services they are willing to share with the general public. In the near term, most early adopters are testing Web Services on internally deployed projects while they wait for security standards to emerge. This also gives them field experience in determining whether the vaunted new paradigm will live up to its hype or be exposed as yet another layer of "the next best thing".
Needed: A New All-Encompassing Extranet Approach
As noted, the bulk of the post-modern VPN alternatives offer targeted value and solutions that may assist some corporations all the time and all corporations some of the time. What IT organizations look for is less complexity a single infrastructure to handle all extranet situations, all applications, and all WAN media. The basic requirements of a true extranet solution are deceptively straightforward. It should:
- Provide integral, complete security not just privacy.
Deliver granular access to applications, not networks.
- Drop dead simple: Partner personnel with little IT knowledge must be able to install it. Let the corporation/IT focus on business drivers, not technology issues.
- Have a minimal footprint requiring no change the application, client, or network and introducing few network elements
- Abstract out the WAN & network boundary issues
- Provide complete enterprise autonomy
- Be application agnostic deliver all applications in their native form, whether legacy, file share, web-enabled, or web-services
About the Author
Roger Wood is a Senior Product Marketing Manager for Flatrock Inc. Flatrock develops and sells Instant Extranet products to help companies dramatically reduce the cost, complexity and time associated with securely connecting business partners to critical applications.
Mr. Wood joined Flatrock following 9+ years at Cisco Systems, spent in several technical and senior product marketing management roles. Most recently he was responsible for Enterprise SLA and VPN management suites. Prior to that he spent several years leading the product management teams creating service provider element management systems for dial, WAN switching, provisioning, and directory enabled networks products.
Prior to Cisco Mr. Wood was Director of Education Services at Interconnect Network Consulting Group, a Los Angeles based network design, implementation, and training firm.
For information on Flatrock, go to www.flatrock.com.