Download as pdf or txt
Download as pdf or txt
You are on page 1of 8

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

You might also like