TCP/IP Over Satellite Yi Zhang

G27525863

1. Introduction Satellite communications have numerous advantages over terrestrial data

connections including mobility, network topology, and the “anywhere and everywhere” benefit of global coverage. These advantages come at the price of increased data transit times and low security level. There are two problems in particular handicap satellite links for data applications [1]:

• Throughput limitation. TCP senders cannot exceed the rate at which the receiver can acknowledge receipt of packets--satellite latency effectively caps standard TCP throughput per session (RFC-793).

• Security. Transmissions from satellites are available to anyone with a suitable receiver. Separate solutions for each problem have been available for years. Manipulation

of TCP header fields with a Performance Enhancing Proxy (PEP) server can fool the end points into increasing the throughput on a satellite connection. Encryption of the data defeats interceptions off the air. However, standard IPsec encryption of the IP packet hides the fields in the TCP header and so prevents an acceleration proxy from changing them. Therefore, an end user had to make a choice and compromise on what is more important, throughput or security. This paper will discuss these two problems in details and give solutions for each problem.

2. Throughput Limitation of Satellite Communications Throughput is not a problem with one-way transmissions, such as media

broadcasting, for which the only limit is the capacity of the transponder or relay equipment in the satellite. The sender can transmit at the maximum circuit capacity 100% of the time because:

• The circuit is dedicated and fully available, • There is no need to acknowledge data or correct errors, and • The receiver applies no "back pressure" to limit throughput.

Transmission Control Protocol (TCP), was designed for entirely different conditions:

• Low network latency, • Maximize bandwidth utilization, • Error detection and correction and • Congestion avoidance and recovery via flow control mechanism.

2.1. Latency[2] The large latency associated with satellite communications originates in the 125

ms required for data packets to travel at the speed of light from the earth’s surface to any one of the communication satellites positioned over the equator. This implies a minimum round trip time (RTT) (up and down and back again) between the source and destination of a data session of at least 500 ms, as shown in Figure 1.[2]

Unfortunately, as mentioned above, neither client–server applications nor the TCP protocols are designed to accommodate these high latencies. Most applications are written without regard for network latency, i.e. as though the client and the server are connected over a high speed Local Area Network (LAN). The TCP protocol was designed for use on terrestrial networks where latencies seldom exceed 250 ms to travel around the world over copper or fiber circuits.

Figure 1Total Round Trip Time using Broadband satellite [2]

2.2. Slow Start[3] Note in Figure 2 the TCP header fields called Sequence Number,

Acknowledgment Number, and Window. These fields control data flow between two TCP devices, A and B. Also, they are used to implement sliding window scheme that ensures an effective flow control between the end points.

Figure 2 TCP header portion

TCP senders may transmit all the bytes in the window value. This allows packets to be burst onto the satellite channel in groups. When the window is exausted, the sender must stop until it receives another Acknowledgment Number (with a Window size). In this way, each side of a TCP connection controls the rate at which it receives data; it applies backpressure by reducing its window.

A complicating issue with TCP is its flow control mechanism, which misinterprets the long delay from long trips through the atmosphere as evidence of a congested network or packet loss and will not increase the rate at which it sends packets, even though there is no actual congestion or packet loss across the satellite link. More specifically, TCP assumes that all loss and delay are caused by network congestion. As a result, it cuts back the transmission rate by reducing the Window size, and then slowly ramps the send rate back up. Based on following formula [5] the throughput will keep low since the small window size.

𝑡ℎ𝑟𝑜𝑢𝑔ℎ𝑝𝑢𝑡 =  max𝑤𝑖𝑛𝑑𝑜𝑤  𝑠𝑖𝑧𝑒

𝑅𝑇𝑇

3. TCP Acceleration for Satellite Links: Since TCP is the standard for data communications worldwide over the Internet,

satellite operators have developed technologies to make TCP sessions perform better by minimizing the effects of high latency intrinsic to satellite links, which often termed as “TCP Acceleration”.

There are a number of different forms of TCP acceleration. One of most widely used is Performance Enhancing Proxies (PEPs), which all have one important common feature. All PEPs involve techniques that change the TCP header data before and after the satellite link to hide the high latency of the satellite link from the TCP session.

One of the techniques using PEP is called TCP spoofing. It will be discussed in details in following section.

3.1. TCP spoofing.[2] TCP spoofing is one PEP technique that imitates a terrestrial TCP session by

sending false TCP packet acknowledgements, which broke the TCP session into segments [4] (see Figure 3). The satellite modem can contain the spoofing software or an additional device can be deployed at the remote site and at the satellite carrier’s Network Operations Center (NOC) (see Figure 1). The spoofing device acknowledges receipt of the data packet locally (from the sender) as if it were the receiver and the TCP session proceeds as though it was occurring just across the LAN, i.e. the TCP flow control mechanism sends packets at the maximum rate supported by the LAN connection. On the other side of the satellite link, the spoofing device/software suppresses the real acknowledgments from the actual receiver.

The spoofing devices/software contain storage buffers to allow the transmission of data across the satellite links and deal with lost packets/re-transmissions between the two spoofing points, since the actual sender and receiver think the session is always fine. Other PEP techniques include adjusting packet size, data rates and other TCP parameters

to more closely match the characteristics of the satellite carrier protocols. In all cases, values are changed in each TCP packet header in both TCP-PEP devices.[2]

Figure 3 TCP Spoofing [4]

4. Security Issue with Satellite Communications Data security concerns have imposed certain criteria for enterprise Wide Area

Networks. Virtual Private Networks (VPNs) have become standard requirement for companies using the public Internet to connect their remote sites to the headquarters. [2]

4.1. VPNs VPNs encrypt a company’s data traffic when traveling over the public Internet so

that the data streams cannot be easily intercepted and viewed. VPNs also authenticate the data to ensure it has not been altered while in transit across the Internet. A VPN between two sites constitutes a private connection (across a public network) through which data can securely pass between hosts at the two sites.

VPNs operate in two modes [2], as shown in Figure 4, tunnel and transport. When a data packet enters into a tunnel mode VPN connection, the whole data packet (TCP header and payload) is encrypted and given a new header, thereby the original packet becomes the encrypted payload of a new VPN tunnel packet.

In transport mode, only the payload of the original data packet is encrypted; the original TCP packet header becomes the new header and remains unencrypted. Transport mode is fundamentally less secure than tunnel mode because the data header of the original packet is still used, i.e. the source and destination IP addresses of the two hosts are still used, and all the TCP session data remains in clear text in the header when traveling over the Internet.

Figure 4 VPN Tunnel Mode vs. VPN Transport Mode

Tunnel mode VPNs have become the corporate security standard because of the superior security features [2]. By completely concealing (through encryption) the original data packet header and payload, the packet is impervious to the “man in the middle” attacks used to intercept, record and retransmit TCP sessions as the packets traverse the public Internet. With the header of the original data packet fully encrypted, no information can be obtained about the original TCP session running between the client and server. In transport mode, only the original payload is encrypted and the header is left unencrypted and subject to the prying eyes of a would be attacker. As such, transport mode VPNs are seldom used because they do not meet companies’ security criteria for modern wide area networks.

4.2. Problems with VPNs and TCP Acceleration Although these TCP acceleration methods all sound good to improve TCP data

rates over satellite, there are problems when you trying to use VPNs and TCP acceleration together [1]. Recall how all the TCP acceleration technologies rely on altering the TCP header of each data packet. Herein lies the problem when combining TCP acceleration and VPNs to deliver secure, high performance data communications over satellite. The conflict arises in the TCP session data in the original packet header.

If the data packet enters a VPN in tunnel mode before the TCP acceleration takes place, then two problems arise [2]. First, the original TCP packet is completely encrypted (header and payload) and so the session header data is unavailable to be altered by acceleration. Second, applying TCP acceleration methods to VPN packets would alter the VPN header and/or spoof the VPN acknowledgements and violate the authentication safeguards which require the VPN packet (and headers) remain unchanged in transit between VPN endpoints. The only alternative is to reduce the level of VPN security by utilizing transport mode and leaving the packet headers unencrypted. Even then, some forms of TCP acceleration and VPN transport mode both attempt to alter certain values in the TCP packet header and may not function together at all [2] (Figure 5).

In this paper, two methods are given to solve this conflict. One is TCP optimization and another alternative way is that simply accelerate TCP packet before encrypting.

Figure 5 Conflicts Between VPNs and TCP Acceleration in the Satellite Modem

4.3. TCP Optimization: TCP Optimization changes the parameters of transmission to match the operating

system of the processor and the type of network connection. These parameters include: window size and path MTU etc. The following sections will discuss these parameters in details.

4.3.1. Window Size [5] Even if the network has a high bandwidth and the receiver has a large buffer, the

throughput achieved by TCP is limited by:

𝑡ℎ𝑟𝑜𝑢𝑔ℎ𝑝𝑢𝑡 =  max𝑤𝑖𝑛𝑑𝑜𝑤  𝑠𝑖𝑧𝑒

𝑅𝑇𝑇 This follows since a TCP source cannot send more than the window size of

packets in an RTT time. Using the standard maximum TCP window of 64Kbytes (coded on 16 bits) and a satellite link of RTT 560ms, this limits the throughput to 117 Kbytes/s. To send at higher rates, a window scale option has been added to TCP. It consists in multiplying the old window field by a scale factor coded on 14 bits. This lets TCP use larger windows, up to 230 Bytes.

4.3.2. Path MTU measurement. [6] To reduce the overhead due to the packet header, a large number of data bytes

must be sent in a TCP segment. However, large packets will be fragmented if they encounter a network with small MTU (Maximum Transfer Unit) which increases considerably the overhead. This method lets TCP detect the largest packet that can cross the Internet without incurring the cost of fragmentation and reassembly. Also, because

the TCP sender increases its window by segments, using large packets yields a faster growth of the throughput.

There are also other parameters like initial window size and buffer size [7]. However, one thing need to mention is that there is no single definitive source of this information as any changes that can be made will depend upon the users local environment. Some information is provided by Microsoft[8], Speedguide[9], IETF[10].

4.4. Accelerating before encrypting[11] Another alternative for improving VPN performance over satellite requires the

full encryption of the TCP data stream so that both data and protocol headers are secure. This is particularly important in cases where an enterprise has a predefined technology choice (such as IPSec), vendor procurement or security policy that requires the highest level of VPN security possible.

The method used here is to accelerate the TCP before passing the data stream on into the IP layer for encryption. See Figure 6.

Figure 6 Accelerating before Encrypting

This solution comprises an acceleration or PEP that is operated by the user, rather than embedded within the hub. Again, There are many providers of this technology, some implement a client/server pair as software and hardware, others implement a hardware gateway pair; the solution chosen depends upon the configuration required at the remote site (single PC or LAN).

5. Conclusions: Due to the nature of TCP transmissions, any performance increases achieved by

the various acceleration methods are offset by serious compromises in data security. Fundamental incompatibilities arise when one attempts to operate conventional VPN devices over satellite links, due to the nature of TCP acceleration techniques commonly used for broadband satellite connections. VPNs may not function at all, security is compromised through the use of transport mode VPNs, and/or the lack of TCP acceleration can degrade application performance over satellite links so as to be unusable.

6. Reference [1] High Performance VPN Solutions Over Satellite Networks, http://www.virgintechnologies.com/downloads/WP_VPNs_over_satellite.pdf [2] TCP/IP over Satellite: Optimization vs. Acceleration, Todd J. Anderson, PhD, End II End Communications, Inc.-White Paper [3] TCP/IP Performance over Satellite Links, Craig Partridge and Timothy J. Shepard. [4] Cisco Accelerated Internet over Satellite Solution, http://www.cisco.com/en/US/prod/collateral/modules/ps2797/solution_overview_c07-525404_ps2797_Products_White_Paper.html [5] V. Jacobson, R. Braden, and D. Borman, TCP Extensions for High Performance, May 1992, RFC 1323. [6] M. Allman and D. Glover, Enhancing TCP over satellite channels using standard mechanisms, Technical report, NASA Lewis, 1998 [7] TCP/IP Over Satellite, Marc Emmelmann, [8] Speedguide, http://www.speedguide.net/articles.php?category=52 [9] Microsoft, http://www.microsoft.com/technet/itsolutions/network/deploy/depovg/tcpip2k.mspx [10] IETF, http://www.ietf.org/rfc/rfc2760.txt [11] Using VPN (Virtual Private Networks) over Satellite, http://www.sonet.at/dsdsl-vpn/dsdsl-vpn.htm