Ing Case Study Ing\'s Network

Ing Case Study

ING's network topology to support its 2,000 brokerage partners begins with a Frame Relay WAN connecting the partner base to the ING Life Headquarters in Don Mills, Ontario. Data traffic including policy queries had been significantly bottlenecked by the Frame Relay WAN speed of 55 kbps, and then further constrained by the conversion from TCP/IP to SNA prior to the requests being sent to the company mainframe in Norwich, CT. The decision to create an extranet solved only a portion of the bottleneck however. In effect ING traded their 56 kbps line for the Extranet's T1 line. Usability is also increased ING has configured their IBM Host OnDemand server to deliver an applet that loads the client software automatically within a browser session. The applet is a TN3270 emulation which is in effect a "screen scrape" to the 3270 terminals that would be connected directly to the mainframe in Norwich, CT. Access times for TN3270 emulations running over T1 lines in an Extranet secure via VPN are going to be sporadic and there will be many times the VPN connection drops due to traffic congestion over the network. The intent of this paper is to analyze how this topology could be further improved, taking note of the probable difficulties and risks associated with using public infrastructure. In addition the precautions ING needs to take over and above what they have already done with their VPN and SSL connections are discussed. Finally the extranet topology itself is discussed and evaluated from the context of greater security, scalability and performance over time for the brokerage partners served.

Difficulties and Risks Running Private Extranets Over Public Networks

The greatest difficulty is the unpredictable nature of the Internet's bandwidth and availability across the broad geographic regions ING intends to serve with the extranet. The Internet itself is highly interdependent on the overall load it is placed under from a global standpoint; it is an ecosystem that is under a myriad of constraints simultaneously. ING's applications are the mercy of the global Internet, how the global routing and optimization of traffic are being managed, and also the relative level of security as well. On this last point, ING will face continual risks. Adopting the Secured Sockets layer (SSL) standard is a good first step yet the company needs to have Virtual private Networking (VPN) tunneling also in use to ensure their applications are not impersonated or hacked into at brokerage partners' sites or within the Canadian headquarters. The following section will discuss security precautions in greater depth. Finally ING faces the challenge of continually ensuring the client software of their TN3270 emulation is current across all brokerage partners which will become a significant issue as enhancements to the application are made over time.

Security Precautions

There are many security precautions that ING needs to take into account that they are not today. First, the configuration of the VPN protocol, which has been chosen as SSL, is a good choice given the fact that this protocol is specifically designed for remote access. IPSec, SSL's counterpart is a point-to-point-based protocol which would not scale given the brokerage partners' needs.

For the SSL-based VPN connections to be as secure as possible ING needs to take into account configuration of the tunneling or internetwork infrastructure configuration parameters of their network first. Tunneling is defined as the organization of data into secured frames or packets, defined by a secured preamble or transit network frame and transit internetwork header (Cisco, 2010). ING needs to take these steps into account in determining if the extranet will actually be as effective as they hope it will; VPN networks running SSL connections can be bandwidth intensive if there are high percentage of transaction traffic on them (Cisco, 2010). ING would be best advised to complete several pilots of the extranet, varying options in the VPN configuration parameters and the SSL options to ensure optimal performance while also gaining the greatest level of speed as well. Figure 1, How VPN Tunnels Work, illustrates this concept of how Transit Internetwork Headers are critical for securing a VPN tunnel that will send data, and in the case of ING, policy requests, from brokerage partners to the mainframe in CT and back. ING needs to also interpolate the effects of running TN3270 emulation sessions over a VPN configured for SSL security. These are all burdens on the network that will impact its performance and become amplified in the broader, global Internet's performance is slowed down and not working at optimal speeds.

Figure 1: How VPN Tunnels Work

Source: (Cisco Tutorial, 2010)

Extranet Topology Critique