As the cost of consumer satellite systems and bandwidth drops lower and lower Internet access becomes more wide spread and the demand for secure connections from remote worker locations to Company headquarters, or branches, is increasing.
In order for a two-way satellite service to perform properly in conjunction with traditional terrestrial networks two-way satellite networks must employ special software to deal with the extra 23,000-mile space distance of the connection. Without this software, the increased latency (the time required to traverse the space segment) means that the TCP protocol severely limits link performance.
The Internet relies on the Transmission Control Protocol (TCP) to ensure packet delivery without errors. TCP works by sending a certain amount of data, then waits for the receiver to send an acknowledgment of receipt. With TCP, the sender cannot transmit more data until it has received an acknowledgment.
If an acknowledgment does not arrive in a timely manner, TCP assumes the packet was lost (discarded due to a congested network) and resends it. When packets go unacknowledged, TCP also slows the send rate to reduce the perceived congestion and to minimize the need for retransmissions.
TCP/IP sessions start out sending data slowly. Speed builds as the rate of the acknowledgments verifies the network’s capacity to carry more traffic. This is known as slow-start, followed by a ramp-up in speed. The speed of the connection builds until the sender detects packet loss from a lack of an acknowledgment.
Ground networks typically have round-trip latencies in the range of 35 to 100 ms. Satellite networks, due to the distance of geo-synchronous satellites above the equator, require 550ms or more. Some satellite connections have much higher RTT. The TCP protocol interprets the additional satellite RTT as network congestion. If uncorrected, this effect causes the network to send all additional packets at the slow-start rate.
Current two-way satellite networks employ a technique referred to as TCP spoofing to compensate for the extra time required to pass through the space segment. Special software on the satellite modem appears to terminate the TCP session, so it appears to the sender as the remote location. In reality, the satellite modem is acting as a forwarder between the originating PC or host and the remote site.
IPsec VPNs not only encrypt the data portion of packets, they also encrypt the TCP packet header. Popular IPsec VPNs, therefore, defeat the modem TCP acceleration software because the modem cannot detect the TCP packet and will pass the unrecognized packet over the space link as a “raw “packet.
This situation requires that acknowledgments transit the space segment twice (over and back) and results in substantial performance degradation. The impact on performance increases as the latency rises.
There are many products in the market to overcome this issue. They use many techniques—a common approach is to convert the TCP packet to UDP before the packet is presented to the satellite modem. UDP packets do not require acknowledgments’ and are, therefore, “pushed” over the satellite link at full throughput.
These solutions are generally end-to-end solutions with a hardware device or software at both ends of the connection that will unpack the received UDP packet and reconvert to TCP before passing onto the LAN.
A new form of VPN connection has recently appeared on the market—SSL VPNs. These new VPNs are based on the Secure Sockets Layer (SSL), the protocol that safeguards the world of e-commerce; the VPN’s are quickly becoming a leading option for remote access. Using HTTPS ports, the application can be recognized by the TCP spoofing software and, therefore, spoofed to full data throughput.