2.7.1 Satellite IP Routing
Satellite networks with onboard processing and switching capabilities allow direct interconnection between satellite terminals located in any satellite beam. Within a designated service coverage region, network management, onboard switch control, service access, routing and IP/ATM address translation function are managed by a network control center (NCC). The NCC hosts a network management system (NMS), a Switching Control System (SCS), and a Satellite Router System (SRS). The SRS is responsible for service management routing enforcing routing policies and connectivity constraints and IP/ATM address translation. Further details on SRS can be found in [229, 230].
2.7.2 Satellite IP QoS Challenges
QoS mechanisms provide service differentiation and performance measures for Internet applications. Service differentiation provides different services to different applications according to their requirements. Performance assurance addresses bandwidth, loss, delay, and delay variation. Bandwidth is a fundamental resource for satellite communication and its proper allocation determines the system throughput. End-to-end delay is also important for several applications. There are a variety of choices to provide the Internet QoS. These are Integrated Services (IntServ) [186, 187, 188], Differentiated Services (DiffServ) [190, 191, 192], and Multiprotocol Label Switching (MPLS) [214, 215, 216, 217]. However, the research of application of these QoS framework to broadband satellite network is required. Research must also be done to support IP QoS in a dynamic demand assignment capacity environment.
There are many issues for IP based networks and services and a lack of proven robust and scalable standard mechanisms for terrestrial and more so for satellite networks.
– Dynamic allocation of resource optimized for packet loss and delay.
– Assuring that the required end-to-end network performance objectives are achieved.
– Seamless signaling of the desired end-to-end QoS across both the network and inter-faces.
– Performance monitoring of IP based networks and services consistent with planning method.
– Rapid and complete restoration of connectivity following severe outages or heavy congestion levels.
The QoS mechanisms recommended by the IETF, i.e, IntServ, DiffServ, Resource Reservation Protocol (RSVP)[189] and aggregate RSVP, and MPLS are described in chapter 4. This thesis focuses on the TCP performance study of satellite, buffer designs and performance analysis of TCP flavors and end system policies for ATM transport over
satellite in chapter 3. IntServ, DiffServ based QoS architectures are proposed for satellite IP networks in chapter 4. Also, TCP, UDP performance over satellite network with differentiated services is analyzed in chapter 4.
2.7.3 Satellite Network Security
GEO satellite environment has some security challenges. Eavesdropping and active intrusion is much easier than in terrestrial fixed or mobile networks because of the broadcast nature of satellites. This can weaken the concept of firewalls for isolating company private data from intruders. Satellite channels experience high bit error rates, which may cause the loss of security synchronization. This demands a careful evaluation of encryption systems to prevent QoS degradation because of security processing. The security requirement for end-to-end communications depends on the applications and there is no single security solution for applications with varying requirements.
Satellite ATM Security: For satellite ATM transport ATM Forum has defined four security services. [173.]
User plane security: The user plane security defines the mechanisms to allow for secure communication between nodes in an ATM network, which can be subdivided into access control, authentication, data confidentiality, and data integrity.
Control plane security: The control plane defines the call control signaling needed to establish, maintain and close a certain Virtual Connection (VC). Thus, authentic signaling has been defined as the main target of control plane security for any endpoint-to-endpoint, switch-to-switch, or endpoint-to-switch signaling communication.
Support services: The support services define the certification infrastructures, the key exchange mechanisms, and the basic negotiation of security requirements and capabilities.
Management plane security: The management plane is responsible for both performing management functions for the system as a whole (plane management), and for performing network and system management functions such as resource management (layer management).
ATM Forum specifications address the security issues in terrestrial fixed network only.
Considerable amount of research has to be done addressing security in a satellite environment which has high bursty error rates. It is important to investigate the encryption algorithms for high link data rates.
Internet Security (IPSec): The IETF has provided security standards for the Internet known as IP Security (IPSec). The IPSec protocol suite is used to provide interoperable cryptographically based security services (i.e. confidentiality, authentication and integrity) at the IP layer. It is composed of an authentication protocol - Authentication Header (AH), a confidentiality protocol - Encapsulated Security Payload {ESP), and an Internet Security Association Establishment and Key Management Protocol (ISAKMP).
Although these protocols satisfy to a large extent the needs of secure communications in the Internet, they are aimed mainly at unicast transmissions between one sender and one receiver.
IP AH and IP ESP may be applied alone or in combination with each other. Each protocol can operate in one of two modes: Transport mode or tunnel mode. In transport mode, the security mechanisms of the protocol are applied only to the upper layer data and the information pertaining to IP layer operation as contained in the IP header is left unprotected. In tunnel mode, both the upper layer protocol data and the IP header of the IP packet are protected or “tunneled” through encapsulation. The transport mode is intended for end-to-end protection that can be implemented only by the source and destination hosts of the original IP datagram. Tunnel mode can be used between firewalls.
PEP Security
Some of the current satellite networks employ PEP to enhance the TCP performance as discussed section 2.5.3.4. The PEPs do not attempt to replace any application level end-to-end function, but only optimize the performance to a subpath of the end-end-to-end path between the application endpoints. The potential end-to-end security implications in PEP implementations are discussed in the following paragraphs.
In most cases, security applied above the transport layer can be used with PEPs, especially transport layer PEPs but today only a limited number of applications include support for the use of transport (or higher) layer security. On the other hand, IPSec can be used by any application, transparently to the application.
A user or network administrator must choose between using PEPs and using IPSec. If IPSec is employed end-to-end, PEPs that are implemented on intermediate nodes in the network cannot examine the transport or application headers of IP packets because encryption of IP packets via IPSec’s ESP header (in either transport or tunnel mode) renders the TCP header and payload unintelligible to the PEPs.
If a PEP implementation is non-transparent to the users and they trust the PEP in the middle, IPSec can be used separately between each end system and PEP. This is not an acceptable alternative because, end systems cannot trust PEPs in general, this is less secure than end-to-end security, and it can lead to potentially misleading security level assumptions by the end systems. To prevent this, PEP could force the same level of security to each end system which again increases the complexity.
With a transparent PEP implementation, it is difficult for the end systems to trust the PEP because they may not be aware of its existence. Even if the user is aware of the PEP, setting up acceptable security associations with the PEP while maintaining the PEP’s transparent nature is problematic. Even when a PEP implementation does not break the end-to-end semantics of a connection, the PEP implementation may not be able to function in the presence of IPSec.
[127] has reported security implication mitigation methods such as end user using IPSec for some traffic and not for other, and implementing IPSec between two PEPs of a distributed PEP implementation. In both the cases significant complexity being added to the end system implementation has been reported. A further research has to be undertaken for developing alternative approaches for achieving end-to-end secured satellite networks.