end‐to‐end security and resource optimization for broadband satellite networks

UNIVERSITÀ DEGLI STUDI DI ROMA

“TOR VERGATA”

Degree of Philosophy Doctor in Space Systems and Technologies

XXVII Cycle

End-‐to-‐End Security And Resource Optimization

For Broadband Satellite Networks

Ahmed Abdelsalam

2014/15

Tutor: Prof. Michele Luglio

Coordinator: Prof. Gian Carlo Cardarilli

I

ACKNOWLEDGMENT

This thesis is an output of the work I have been carrying over the last three years at the Satellite Multimedia Group (TLCSat1) in the University of Rome Tor Vergata.

At this moment, I wish to thank my supervisor, Prof. Michele Luglio, for his guidance and honest feedback, leading to the development and improvement of the work presented in this thesis. Also I am very grateful to my colleagues in TLCSat group, Dr. Ing. Cesare Roseti and Dr. Ing. Francesco Zampognaro for their extended support and guidance that resulted to this final work.

I would like also to thank Dr. Ing. Daniel Caragata, Universidad Técnica Federico Santa María, Chile, for his interest, advice, and assistance that helped to improve and validate the development of the security mechanism presented in this thesis.

Finally and importantly, special thanks and appreciation to my beloved parents and my dear sister for their continuing support and encouragement during every stage of my life’s journey.

1 http://tlcsat.uniroma2.it/

II

PUBLICATIONS

Most of the work presented in this thesis has been published, accepted, or even submitted for publication in research projects, peer reviewed International conferences, and international journals:

International Journals

• Caviglione L.; Gotta A.; Abdel Salam A.; Luglio M.; Roseti C.; and Zampognaro F., “Performance Evaluation of HTTP and SPDY over a DVB-‐RCS Satellite Link with Different BoD Schemes”, In Personal Satellite Services. Springer International Publishing, 2014.

• Abdelsalam, Ahmed; Caviglione, Luca; Celandroni, Nedo; Collina, Matto; Cruickshank, Haitham; Fairhurst, Gorry; Ferro, Erina; Gotta, Alberto; Luglio, Michele; Roseti, Cesare; Secchi, Raffaello; Sun, Zhili; Vanelli, Alessandro,“A Deep Analysis on Future Web Technologies and Protocols over Broadband GEO Satellite Networks”, International Journal of Satellite Communications and Networking, (Submitted August 2014).

• Abdelsalam, Ahmed; Caragata Daniel, Luglio, Michele; Roseti, Cesare; Zampognaro, Francesco, “Robust Security framework for DVB-‐RCS Satellite Networks (RSSN)”, International Journal of Satellite Communications and Networking, (Submitted January 2015).

International Conferences

• Salam, A.A.; Luglio, M.; Roseti, C.; Zampognaro, F., "DVB-‐RCS security framework for ULE-‐based encapsulation" 9th International Wireless Communications and Mobile Computing Conference (IWCMC), 2013, vol., no., pp.131, 136, 1-‐5 July 2013, Italy.

• Salam, A.A.; Luglio, M.; Roseti, C.; Zampognaro, F., “SPDY Multiplexing Approach on Long-‐latency Links” IEEE Wireless Communications and Networking Conference (WCNC), 2014, pp. 3492, 3497, 6-‐9 April 2014, Istanbul, Turkey.

• Salam, A.A.; Luglio, M.; Roseti, C.; Zampognaro, F., “Resource Optimization Over DVB-‐RCS Satellite Links Through the Use of SPDY” 10th International Workshop on Resource Allocation, Cooperation and Competition in Wireless Network RAWNET/WNC3 2014, 25-‐29 May 2014, Hammamet, Tunisia.

• Salam, A.A.; Luglio, M.; Roseti, C.; Zampognaro, F., “SPDY over satellite: performance optimization through an end-‐to-‐end technology” 37th International Conference on Telecommunications and Signal Processing (TSP) 2014, 1-‐3 July 2014, Berlin, Germany.

• Caviglione L.; Gotta A.; Abdel Salam A.; Luglio M.; Roseti C.; and Zampognaro F., “Performance Evaluation of HTTP and SPDY over a DVB-‐RCS Satellite Link with Different BoD Schemes” 6th International Conference on Personal Satellite Services 2014, 28-‐29 July 2014, Genova, Italy.

III

Research Projects

• SPARC – Space Awareness for Critical Infrastructures -‐ The Telecommunication Terrestrial Networks Role And Its Dependencies With Regard To Satellite Assets. 11, 2013

• SatNEx III -‐ Future Web technologies and protocols over broadband GEO satellite networks. SatNex III. Deliverable CoO3-‐Task 3 -‐ 10, 2013.

• SatNex III -‐ State-‐of-‐the-‐art Web Technologies and Protocols State-‐of-‐the-‐art Web Technologies and Protocols. SatNex III. Deliverable CoO3-‐Task3 -‐ 12, 2013

• SatNex III -‐ Future Web Technologies and Protocols over Broadband GEO Satellite Networks -‐ New Web Modelling for Satellite Study Recommendations. SatNex III. Deliverable CoO3-‐Task3 -‐ 1, 2014

IV

ABSTRACT

The Satellites represent a solution for Internet connectivity and data distribution in isolated locations, on high mobility platforms such as planes, ships or high-‐speed trains or for disaster recovery applications. However, due to the characteristics of the satellite systems, the data transmission over the satellite networks must face some challenges. In particular, performance, from both security and communication point of view, are strongly affected by several factors introduced by the characteristics of the satellite systems (i.e. wireless nature, latency, link availability, propagation channel, link asymmetry, etc.), which significantly impact in particular web based applications, increasing both in terms of volumes and complexity

Satellite networks, either commercial or military, are prone to different security threats. To care security of the information sent over the satellite networks is very important, considering that the typology of services usually carried over includes emergency management, telemedicine, banking, off shore and airplane connectivity. In this thesis, novel end-‐to-‐end robust security architecture is introduced for securing DVB-‐RCS satellite networks. This security architecture is inspired by the robust security mechanism available in IEEE 802.11i WLAN but considers the particular characteristics of the satellite networks. An efficient authentication and key management mechanism is proposed, which performs the mutual authentication and key distribution through three round-‐trips only. Modular formalization for the security correctness is presented to prove that the proposed framework is as secure as IEEE 802.11i. Furthermore, the simulation results show that the proposed security framework has a very small data overhead and a better performance than IPSec, which is commonly used as end-‐to-‐end security solution over IP satellite networks.

The other aspect addressed in this thesis is Web performance over satellite using the future web technologies, such as SPDY protocol. SPDY is a new application technology, introduced by Google, to accelerate Web transfers over common terrestrial links. Most of the SPDY techniques (i.e. header compression, pushing and multiplexing) have been usually included in satellite Performance Enhancing Proxies (PEPs) to optimize performance. Therefore, SPDY over satellite is expected to provide end-‐to-‐end performance optimization solution without requiring any specific modification over the network. Proof of such an improvement is revolutionary for the role of satellite in the future Internet, since it could be considered as a transparent link, which does not need ad-‐hoc protocol adaptations. Performance assessment of the protocol has been obtained through a satellite emulator that reproduces in software a DVB-‐RCS link while running real implementations of both TCP/IP stacks and SPDY.

TABLE OF CONTENTS

ACKNOWLEDGMENT I

PUBLICATIONS II

ABSTRACT IV

1 INTRODUCTION ........................................................................................................................ 11

2 BROADBAND SATELLITE NETWORKS ...................................................................................... 14 2.1 Satellite Network Architecture ............................................................................................................. 15

2.1.1 Transparent Satellite Star Networks ......................................................................................... 16

2.1.2 Transparent Satellite Mesh Networks ....................................................................................... 16

2.2 DVB Networks .............................................................................................................................................. 17

2.2.1 MPEG Transport Stream .................................................................................................................. 17

2.2.2 Data Encapsulation ............................................................................................................................ 19

2.2.2.1 Multi-‐Protocol Encapsulation (MPE) .................................................................................................. 20

2.2.2.2 Unidirectional Lightweight Encapsulation (ULE) ......................................................................... 20

2.2.2.3 Generic Stream Encapsulation (GSE) .................................................................................................. 21

2.2.3 DVB-‐S/ DVB-‐S2 .................................................................................................................................... 22

2.2.4 DVB-‐RCS/ DVB-‐RCS2 ........................................................................................................................ 23

2.2.4.1 Bandwidth on Demand ............................................................................................................................. 24

2.3 Issues Related to the Characteristics of Satellite Links .............................................................. 25

2.3.1 Latency and Bandwidth ................................................................................................................... 25

2.3.2 Bit-‐Error Rate (BER) ......................................................................................................................... 26

2.3.3 Link Asymmetry .................................................................................................................................. 26

2.4 Performance Enhancing Proxies (PEPs) ........................................................................................... 26

3 SECURITY IN DVB-‐RCS SATELLITE NETWORKS .................................................................... 29 3.1 Main Threats on the Satellite Links ..................................................................................................... 30

3.2 Security Requirements ............................................................................................................................. 30

3.3 Current Security Techniques: State-‐of-‐the-‐Art Review .............................................................. 32

3.3.1 DVB Common Scrambling ............................................................................................................... 32

3.3.2 DVB-‐RCS Privacy “Individual User Scrambling” ................................................................... 32

3.3.3 IP or higher layer security mechanisms ................................................................................... 34

3.3.4 ULE Security Extension Header ................................................................................................... 35

3.3.5 DVB-‐RCS Security Framework For ULE-‐Based Encapsulation ...................................... 36

3.4 Weaknesses of DVB-‐RCS Privacy ......................................................................................................... 38

3.4.1 Mutual Authentication ..................................................................................................................... 38

3.4.2 Security Messages Integrity .......................................................................................................... 38

3.4.3 Data Encryption and Integrity ..................................................................................................... 38

3.4.4 Destination Address Protection .................................................................................................. 39

3.4.5 Unsigned Diffie-‐Hellman Parameters ....................................................................................... 39

3.4.6 Key Derivation from the cookies ................................................................................................. 39

3.4.7 MPE/ ATM Limitation ...................................................................................................................... 39

3.4.8 Multicast Support .............................................................................................................................. 40

4 ROBUST SECURITY FRAMEWORK FOR DVB-‐RCS SATELLITE NETWORKS (RSSN) .............. 41 4.1 RSSN Framework Description .............................................................................................................. 43

4.1.1 Phase 1: Discovery, Logon, and Security Agreement ......................................................... 44

4.1.2 Phase 2: Mutual Authentication .................................................................................................. 45

4.1.3 Phase 3: Key Derivation and distribution ............................................................................... 47

4.1.4 Phase 4: Data Encapsulation and Protection ......................................................................... 50

4.1.5 Phase 5: Rekeying, ............................................................................................................................. 53

4.1.6 Phase 6: Security Teardown, log-‐off .......................................................................................... 54

4.2 RSSN Framework Analysis and Evaluation ..................................................................................... 54

4.2.1 Compatibility Evaluation ................................................................................................................ 54

4.2.2 Security Analysis ................................................................................................................................ 55

4.2.2.1 EAP-‐SAT Security Analysis ...................................................................................................................... 55

4.2.2.1.1 Security Compliance .............................................................................................................................. 55

4.2.2.1.2 Modular Security Correctness Proof .............................................................................................. 56

4.2.2.2 Key Derivation and Distribution Security Analysis ...................................................................... 59

4.2.3 Performance Evaluation ................................................................................................................. 61

4.2.3.1 FTP Traffic: .................................................................................................................................................... 63

4.2.3.2 HTTP Traffic .................................................................................................................................................. 64

4.2.3.3 UDP VoIP and Video Traffic .................................................................................................................... 65

5 FUTURE WEB TECHNOLOGIES (WEB 2.0) AND SATELLITE NETWORKS .............................. 69 5.1 Real-‐Time Data Server Push Techniques ......................................................................................... 73

5.2 AJAX Web Applications ............................................................................................................................ 75

5.3 WebSocket Protocol ................................................................................................................................... 77

5.4 New HTTP Paradigms: HTTP/2.0 (SPDY) ........................................................................................ 78

5.4.1 SPDY Request Prioritization .......................................................................................................... 79

5.4.2 SPDY Stream Prioritization ............................................................................................................ 80

5.4.3 SPDY Server Push ............................................................................................................................... 81

5.4.4 SPDY Flow Control ............................................................................................................................. 82

5.5 Impact of The Future Web Technologies On Performance Of Satellite Networks .......... 83

6 HTTP/2.0 OVER SATELLITE: AN ALTERNATIVE END-‐TO-‐END OPTIMIZATION TECHNIQUE87 6.1 Testbed Description ................................................................................................................................... 88

6.1.1 Satellite Network Emulation Platform (SNEP) ...................................................................... 88

6.1.2 SPDY Web Server & Web Client ................................................................................................... 89

6.2 SPDY Evaluation Over DVB-‐RCS Satellite Links ............................................................................. 90

6.2.1 Methodology ......................................................................................................................................... 92

6.2.2 Results ..................................................................................................................................................... 93

6.2.2.1 Analysis of Header Compression .......................................................................................................... 93

6.2.2.2 Analysis of TCP Connection .................................................................................................................... 94

6.2.2.3 Analysis of Bandwidth on Demand Impact ...................................................................................... 97

6.2.2.4 Analysis of the Resource Utilization ................................................................................................. 100

6.2.2.5 Analysis of Multi-‐Terminal Traffics .................................................................................................. 103

6.3 Impact of SPDY on The Satellite Network Architecture .......................................................... 107

6.3.1 Analysis of SPDY Multiplexing ................................................................................................... 108

6.3.2 Results .................................................................................................................................................. 109

6.4 SPDY as an Alternative End-‐to-‐End Optimization Technique .............................................. 112

6.4.1 Test Setup ........................................................................................................................................... 113

6.4.2 Results .................................................................................................................................................. 116

7 CONCLUSION .......................................................................................................................... 120

8 BIBLIOGRAPHY ...................................................................................................................... 123

LIST OF FIGURES

FIGURE 2-‐1: TRANSPARENT SATELLITE STAR NETWORK ARCHITECTURE ..................................................... 16

FIGURE 2-‐2: PES PACKET STRUCTURE ................................................................................................................................ 18

FIGURE 2-‐3: MPEG-‐2 TS FORMAT ........................................................................................................................................... 19

FIGURE 2-‐4: MAPPING OF ES, PES TO THE TRANSPORT STREAM .......................................................................... 19

FIGURE 2-‐5: MPE ENCAPSULATION FORMAT OVER MPEG-‐2TS .............................................................................. 20

FIGURE 2-‐6: ULE ENCAPSULATION FORMAT OVER MPEG-‐2 TS .............................................................................. 20

FIGURE 2-‐7: GSE ENCAPSULATION FORMAT .................................................................................................................... 22

FIGURE 2-‐8: FUNCTION DIAGRAM FOR DVB-‐S MODULATION .................................................................................. 23

FIGURE 2-‐9: TCP SPOOFING PEPS ........................................................................................................................................... 27

FIGURE 2-‐10: TCP SPLITTING PEPS ....................................................................................................................................... 28

FIGURE 3-‐1: KEY EXCHANGE MECHANISMS ...................................................................................................................... 34

FIGURE 3-‐2: LIGHTWEIGHT SECURITY EXTENSION HEADER .................................................................................. 35

FIGURE 3-‐3: ULE SECURE SNDU .............................................................................................................................................. 36

FIGURE 3-‐4: SIGN-‐ON MAC MESSAGE STRUCTURE ........................................................................................................ 37

FIGURE 4-‐1: MESSAGE EXCHANGE – PHASE 1 .................................................................................................................. 45

FIGURE 4-‐2: MESSAGE EXCHANGE – AUTHENTICATION – PHASE 2 ...................................................................... 47

FIGURE 4-‐3: KEY DERIVATION AND DISTRIBUTION DURING PHASE 3 ................................................................ 48

FIGURE 4-‐4: ULE SNDU WITH THE CCMP EXTENSION HEADER .............................................................................. 51

FIGURE 4-‐5: ULE-‐CCMP ENCRYPTION .................................................................................................................................. 52

FIGURE 4-‐6: ULE-‐CCMP COUNTER STRUCTURE .............................................................................................................. 53

FIGURE 4-‐7: OMNET++ SIMULATED SATELLITE NETWORK ..................................................................................... 62

FIGURE 4-‐8: SIMULATED FTP TRAFFIC (ZOOM VIEW) ................................................................................................. 63

FIGURE 4-‐9: SIMULATED HTTP TRAFFIC IN THE FORWARD LINK ........................................................................ 65

FIGURE 4-‐10: SIMULATED HTTP TRAFFIC IN THE RETURN LINK .......................................................................... 65

FIGURE 4-‐11: SIMULATED VOIP TRAFFIC .......................................................................................................................... 66

FIGURE 4-‐12: OVERHEAD ADDED TO THE VOIP PDU ................................................................................................... 66

FIGURE 4-‐13: THROUGHPUT VS UDP PACKET SIZE ....................................................................................................... 67

FIGURE 5-‐1: EXAMPLE OF PIPELINING OF HTTP REQUESTS. ................................................................................... 70

FIGURE 5-‐2: HOL BLOCKING EXAMPLE ............................................................................................................................... 71

FIGURE 5-‐3: ASYNCHRONOUS INTERACTIONS OF AJAX WEB APPLICATION MODEL ................................... 76

FIGURE 5-‐4: RELATIONS, SERIALIZATION AND PRIORITIZATION IN SPDY ....................................................... 80

FIGURE 5-‐5: WINODOWS_UPDATE CONTROL FRAME .................................................................................................. 83

FIGURE 6-‐1: SATELLITE NETWORK EMULATION PLATFORM (SNEP). ................................................................. 88

FIGURE 6-‐2: IMPACT OF THE HEADER COMPRESSION PER PROTOCOL. ............................................................. 94

FIGURE 6-‐3: DIFFERENT MANAGEMENT SCHEMES OF TCP CONNECTIONS PER PROTOCOL. .................. 95

FIGURE 6-‐4: THROUGHPUT ANALYSIS OF HTTP1.0 ....................................................................................................... 96

FIGURE 6-‐5: THROUGHPUT ANALYSIS OF HTTP1.1 ....................................................................................................... 97

FIGURE 6-‐6: THROUGHPUT ANALYSIS OF SPDY .............................................................................................................. 97

FIGURE 6-‐7: PLT VS. DIFFERENT BOD SCHEMES. ............................................................................................................ 98

FIGURE 6-‐8: TIME TO THE FIRST PAINT. ............................................................................................................................ 99

FIGURE 6-‐9: SPDY PAGE LOAD TIME WITH DIFFERENT PERCENTAGES OF SERVER PUSH .................... 100

FIGURE 6-‐10: SPDY TIME TO THE FIRST PAINT WITH DIFFERENT PERCENTAGES OF SERVER PUSH100

FIGURE 6-‐11: BANDWIDTH UTILIZATION DURING WEB PAGE DOWNLOAD ................................................. 102

FIGURE 6-‐12: RETURN LINK SLOTS .................................................................................................................................... 103

FIGURE 6-‐13: SNEP MULTI-‐TERMINAL TRAFFIC GENERATION ........................................................................... 104

FIGURE 6-‐14: WEB PAGE DOWNLOAD TIME IN A MULTIPLE RCST SCENARIO ............................................. 106

FIGURE 6-‐15: SPDY PERFORMANCE DETAILS IN MULTIPLE RCSTS CONFIGURATION .............................. 106

FIGURE 6-‐16: WEBPAGES LOADING TIME OVER DIFFERENT PROTOCOL CONFIGURATIONS. .............. 110

FIGURE 6-‐17: SNEP CONFIGURATION FOR SATELLITE EMULATION ................................................................. 114

FIGURE 6-‐18: WEB TEST PAGE OBJECTS HIERARCHY ............................................................................................... 114

FIGURE 6-‐19: TERRESTRIAL VS. SATELLITE PAGE LOAD TIME ............................................................................ 117

FIGURE 6-‐20: SATELLITE SPDY OPTIMIZATIONS ......................................................................................................... 118

FIGURE 6-‐21: REDUCTION OF RETURN LINK USAGE DUE TO SPDY .................................................................... 119

LIST OF TABLES

TABLE 2-‐1: MPE/ULE HEADER OVERHEAD ....................................................................................................................... 21

TABLE 4-‐1: SECURITY REVIEW, CURRENT COMMERCIAL WIRELESS NETWORKS ........................................ 43

TABLE 4-‐2: SIMULATION SETUP ............................................................................................................................................. 63

TABLE 4-‐3: AVERAGE DATA OVERHEAD RSSN VS. IPSEC ........................................................................................... 68

TABLE 6-‐1: WEB SERVER CONFIGURATIONS. .................................................................................................................. 90

TABLE 6-‐2: WEB CLIENT CONFIGURATIONS. ................................................................................................................... 90

TABLE 6-‐3: PARAMETERS USED FOR EMULATING THE DIFFERENT BOD SCHEMES. ................................... 92

TABLE 6-‐4 TESTING WEBPAGES COMPONENTS .......................................................................................................... 109

TABLE 6-‐5: STATISTICS ON PAGE-‐A DOWNLOAD ........................................................................................................ 111

TABLE 6-‐6: STATISTICS ON PAGE-‐B DOWNLOAD ........................................................................................................ 111

TABLE 6-‐7: CONFIGURATION OF SNEP FOR DIFFERENT SETUP CONSIDERED ............................................. 115

11

1 INTRODUCTION

The Internet has become the universal source of information exchange for most of people around the world. The growing dependency on the Internet applications (e.g. emails, web browsing, social media) created a desire for reliable, fast, and uninterrupted connectivity even in remote and rural areas with insufficient or no terrestrial infrastructure. Therefore, the wireless communications became an important solution due to its ubiquity and flexibility. For these reasons, satellite networks became a largely successful on worldwide scale due to their large geographic coverage, broadcast capabilities, and the high transmission capacity. However, being the DVB standard, largely utilized in the forward link of bidirectional broadband networks, initially designed for transmitting optimized multimedia (i.e. audio, and video), an additional adaptation layer is needed to support the carriage of Internet IP packets.

To access the Internet through a satellite system, a challenging environment shall be considered. Differently from terrestrial networks, problems of bandwidth limitation and availability, and the higher latency of the network (minimum Round Trip Time of 560ms using a geostationary satellite) require to introduce some specific optimization countermeasures. Yet, efforts to efficiently mitigate all these issues did not produce effective solutions to make satellite networks attractive as terrestrial equivalents. Thus, in practice, satellite continued to represent a backup solution in case other terrestrial networks become not available.

On the other hand, satellite networks, like any other communication networks are vulnerable to many security threats. Passive attacks are the easiest attacks for eavesdropping or monitoring data traffic to gain some information about the communication parties and the transmitted data. Active attacks including message modification, masquerading, and reply attacks are more complex since they require expensive equipment, knowledge of the communication standard and direct access to the transmitter network. Furthermore, due to its wireless broadcast nature, and the large transmission coverage area, satellite networks are lacking in physical-‐layer protection comparing to the other cable based communication

12

networks. For example, in case of wired communications, the adversary must first gain a physical access to the wire in order to perform any attacks, while this is not the case in the satellite networks. Thus, security is even more important for satellite networks than for the terrestrial cable networks.

This Ph.D. thesis concerns itself with the security and performance issues of DVB broadband satellite networks. First, the state-‐of-‐the-‐art for broadband satellite systems is studied, while presenting the drawbacks in satisfying the increasing requirements of interactive Internet communications. Thus, it proposes an end-‐to-‐end security and performance enhancement solutions that aim to justify a revision of satellite role for Internet connectivity.

The preliminary research and investigations proved that the existing security techniques either insufficient to provide an adequate protection for the data communication over satellite networks or they may introduce some incompatibilities with the necessary performance enhancement approaches. On the other hand, some performance-‐enhancing techniques (i.e. PEP [50]) could be effective solutions but specific security vulnerabilities must be faced up too. At this point it appears that unsolved problem exists. While both solutions are not incompatible, the user or network operator must choose between secure communication and better performance. Generally, it is often the case security must be traded off against other factors, in this case performance.

The research work has been extended to investigate on the different security mechanisms that are used on the commercial wireless networks. Moreover, the future web technologies and protocols aimed to improve the Internet access over the terrestrial links have been investigated too. The goal of this work was to understand the direction of the emerging technologies and to identify the most suitable for satellite networks or at least to get some useful hints. The results show that, the mature wireless security mechanism (i.e. WLAN security) and the modern web technologies (i.e. HTTP/2.0 [2]) can be revolutionary solutions to the issues addressed in satellite network, particularly those related to security and performance.

Concerning communications security, a novel robust link-‐layer security mechanism is designed to secure end-‐to-‐end data communication over satellite networks. The proposed security is leverage on the mature and robust security mechanism available in IEEE 802.11i WLAN [46]. The special characteristics of satellite networks are well considered during the design of each elements of the security mechanism. It is proved that the proposed security mechanism provides mutual authentication, data confidentiality, data integrity, and lightweight key management system. In addition, it has a very minor overhead and it is compatible with network techniques that are commonly used for performance enhancements.

Concerning the performance, the goal was to understand the direction of the emerging web technologies and to evaluate their expected impact on satellite networking. Different aspects have been analysed using satellite testbed and emulation platforms. This analysis included an evaluation of the HTTP/2.0 protocol performance over satellite and experiments to understand the expected interaction with the existing traditional performance enhancement

[END-‐TO-‐END SECURITY AND RESOURCE OPTIMIZATION FOR BROADBAND SATELLITE NETWORKS]

Introduction

13

techniques, and the effect on the satellite capacity allocation mechanisms. The analysis also considered the impact of application protocols and the delay induced by satellite system.

The research resulted to an optimized version of HTTP/2.0 protocol, including multiplexing, compression, pushing, and caching features, that allow a significant reduction of the webpage loading time, while minimizing the satellite network resources (i.e. bandwidth, return link resources). Results show that the achieved page load time is very close to the value measured when performing the same transfer over ADSL link. These results make the satellite systems suitable to act as an alternative access technology to the access Internet in the future, without the need of additional performance enhancement techniques.

This thesis is structured as follows: Chapter 2 starts with an overview of broadband satellite networks, satellite network architectures, and the specifications of DVB satellite network, describes the various data encapsulation protocols that have been standardized, and then goes on to discuss the issues related to the characteristics of the DVB satellite links, and finally presents an overview of the important intermediate devices within the network architecture. Chapter 3 provides a theoretical analysis of the security in DVB-‐RCS satellite networks, evaluates the main security threats, security requirements, and the state-‐of-‐the-‐art security techniques that are currently used on DVB-‐RCS satellite systems, presenting the limitation and drawbacks of each technique. Chapter 4 presents the design of a robust security framework for DVB-‐RCS networks, specifies the life cycle of the security framework, prescribes a detailed architecture and algorithms to be implemented, and finally presents a comprehensive evaluation of the security framework including formal security validation, performance and compatibility analysis. Chapter 5 presents a theoretical detailed study of the future Web technologies including server push techniques, AJAX web application, WebSocket protocol, and the newest HTTP/2.0 protocol, and then it analyses the impact of these technologies on the DVB-‐RCS satellite systems. Chapter 6 presents a detailed evaluation and of the future HTTP/2.0 protocol over a simulated DVB-‐RCS satellite network, presenting an alternative end-‐to-‐end performance enhancement solution through an optimized version of HTTP/2.0 protocol. The thesis concludes in chapter 7, which summarizes the work carried out and the achieved results.

14

2 BROADBAND SATELLITE NETWORKS

Broadband satellite networks are nowadays designed to offer most of the services and applications provided by the telecommunication networks such as broadband Internet access, VoIP telephony, private IP for corporate intranet, telemedicine, video conferencing, etc. Satellite network is composed of two main segments: the ground segment and the space segment.

The ground segment is composed of one or several Gateways or Hub stations (GW) allowing internetworking with terrestrial networks, a pool of Satellite Terminals (STs), and finally the Network Control Centre (NCC). The NCC plays a fundamental role in configuration and management of satellite terminals, bandwidth capacity assignment, performance management, security management, synchronization and acquisition, billing and accounting.

The space segment consists of the satellite equipment, which includes the communication payload. Satellite systems are usually classified on the basis of orbits: Geostationary Earth Orbit (GEO), Low Earth Orbit (LEO), Medium Earth Orbit (MEO), Highly Elliptical Orbit (HEO), and Hybrid constellations.

GEO satellite is located on the geostationary earth orbit at altitude of 35,786 km. GEO satellites have a large coverage area (footprint) covering around 1/3 of the earth surface. Therefore, theoretically, 3 GEO satellites can be sufficient to cover the entire earth surface. However, this altitude introduces a problem of high latency in communications (around 600ms Round-‐Trip-‐Time, RTT).

LEO satellites are located on low earth orbit at an altitude ranging between few hundred and 2,000 km. LEO is deployed in constellation of several satellites in order to provide contiguous coverage. It requires a reliable handover mechanism to ensure the service continuity.


Broadband Satellite Networks

15

MEO satellites fall between GEO and LEO with altitude ranging from 2,000-‐35,786 km. Both MEO and LEO satellites have a better propagation delay comparing to the GEO systems. However, they are more complicated concerning the management, tracking, and continuous handover.

HEO satellites are located on the elliptic orbits that are close to the Earth at one point and very far away from earth at other point. They are located on different altitudes with a low perigee altitude (around 1,000 km) and high apogee attitude (more than 35,786 km). According to the Kepler’s second law, HEO satellites move slowly at the apogee and much faster at the perigee. HEO satellites are useful to serve the areas of extreme north and south of the Earth, which cannot be covered using geostationary satellites. Finally, Hybrid constellations can use combination of existing orbital solutions. This thesis mainly concerns about satellite networks based on GEO satellites.

This chapter discusses DVB broadband satellite network architectures, standards, and then describes its special characteristics and related issues.

2.1 Satellite Network Architecture

Most of communications satellite networks rely on a transparent satellite that simply acts as a signal repeater (Bent Pipe) between two ground stations. Therefore, there is no data processing taking place on board of the satellite. On the other hand, other satellite networks may rely on regenerative satellites with On-‐board Processing capabilities (OBP), which is capable to process the transmitted data on-‐board including modulation, coding, routing, packet switching, etc.

Transponders on the bent pipes satellite act simply to amplify the uplink signals then shift them to lower frequencies before retransmission on the downlink. An example of bent pipe satellites is the Direct Broadcast Satellite, which support only signal broadcasting service over set of carrier frequencies to a group of number of receivers within the coverage area.

On the other hand, to support two-‐way Internet access over the satellite network, a possible solution is to utilize the existing dial-‐up telephone services or any other terrestrial networks for the upload traffic. The other solution is to provide a return channel over the satellite network itself. This is the case of the interactive satellite communications using DVB-‐RCS/ RCS2 described later in this chapter.

In case of the regenerative satellites (OBP), the satellite works for switching the packets among the receiving and transmitting beams. Thus, the satellite footprint consists of multiple spot beams.

Usually there are two kinds of topologies supported by the interactive transparent satellite networks: star and full mesh.

16

2.1.1 Transparent Satellite Star Networks

Star networks are suitable for scenarios where all satellite terminals need to communicate to the Internet or any other external networks. It is simple solution for both terminals and satellite network design. It consists of a central Hub or gateway and a pool of satellite terminals. The gateway acts as the centre of the star, where all traffic is transmitted. In this network topology, any terminal-‐to-‐terminal communication should travel from terminal to the hub and again from the hub to the other terminal. Thus, it needs a double hop over the satellite (large delay), which may be excessive especially with interactive applications, i.e. video, voice, etc. Furthermore, terminal-‐to-‐terminal communication requires twice the bandwidth required for endpoint communications. Figure 2-‐1 shows the architecture of the transparent satellite star network. The gateway performs all switching and routing procedures. Terminal-‐to-‐terminal communication passes through the central gateway station.

FIGURE 2-‐1: TRANSPARENT SATELLITE STAR NETWORK ARCHITECTURE

2.1.2 Transparent Satellite Mesh Networks

In the transparent mesh topology, satellite terminals can be directly interconnected among one another via a single hop to the satellite. Thus, this architecture minimizes the communication delay and bandwidth utilization required for mesh communications comparing to star networks.

In this architecture, each satellite terminal is capable to receive a single forward link carrier (TDM) as well as multiple return-‐link carriers (TDMA). Thus, the terminals are able to decode multiple different carriers in parallel, similar to the gateway technology.



17

2.2 DVB Networks

Digital Video Broadcasting (DVB) refers to a suite of open standards for digital television and data delivery identified by the DVB Project1, which is an industry-‐led consortium consisting of over 200 television broadcasters, network operators, software developers, manufacturers, and regulatory. DVB specifications are standardized by the European standards bodies, such as the European Telecommunications Standards Institute (ETSI) or the European Committee for Electrotechnical Standardization (CENELEC).

2.2.1 MPEG Transport Stream

DVB specifications adopted a cell-‐oriented packet transmission system called MPEG-‐2, which is defined by the Motion Pictures Expert Group (MPEG) [19]. MPEG-‐2 specifies a basic encapsulation mechanism for multiplexing several types of multimedia information into a single MPEG-‐2 Transport Stream (TS) that can be transmitted over a variety of transmission media.

The basic component of MPEG-‐2 System is the Elementary Stream (ES), which is the output for a programme encoder (i.e. video or audio). Each programme contains a combination of Elementary Streams, typically one for video, one for audio and one for metadata.

MPEG-‐2 processor (i.e. audio/ video compressor or data encapsulator) assembles data of each ES into a stream of Packetized Elementary Stream (PES). PES is a packet with variable sizes (up to 65536 bytes), of which six bytes constitute a mandatory protocol header. The PES header Figure 2-‐2 consists of 3-‐bytes Start Code, 1 byte Stream-‐ID, 2-‐bytes Length field followed by 1-‐byte PES indicator, which contains further information about the stream in order to assist the decoding process at the receiver side. This information includes:

• Fixed bits (2-‐bits); • Data Alignment Indicator (1-‐bit), which indicates the type of the start code for the

current stream, i.e. audio/ video; • Copyright Information (1-‐bit), which indicates if the payload is copyright

protected; • Priority (1-‐bit), which indicates priority of the PES packet; • PES Scrambling Control (2-‐bits), which indicates if the scrambling is used and

which scramble method; • Original or Copy (1-‐bit), which indicates if the current PES stream belongs to the

original ES or it has been copied.

1 https://www.dvb.org/

18

FIGURE 2-‐2: PES PACKET STRUCTURE

The indicator field is followed by the flag field, which completes the PES header. Flag field indicates the presence of the following optional fields, which (if present) are inserted at the end of the PES header and before the PES data payload:

• Presentation Time Stamp (PTS) and the Decode Time Stamp (DTS), which are used to synchronize a set of elementary streams and to control the rate they are replayed by the receiver;

• Elementary Stream Clock Reference (ESCR) and Elementary Stream Rate (ESR), which synchronize the receiver clock as well as indicate the encoding rate of each ES;

• Trick Mode, which indicates the abnormal or special ES types (i.e. after DSM-‐CC has signalled a replay);

• Copyright Information, which indicates the current stream is a copyright ES; • CRC, which may be used to monitor errors in the previous PES packet; • PES Extension Information, which may be used to support MPEG-‐1 streams.

Sequence of PES packets with a variable length composes a Program Stream (PS). PS is sensitive to the errors in the transmission channel. Generally, it assumes the use of error free channel, i.e. storage.

MPEG-‐2 allows the conversion of different PS streams into single Transport Stream (TS), which is designed for different types of transmission channels such as telecommunications and broadcasting channels. Comparing to the PS packets, TS packet has a relatively short fixed length, which make it efficient and robust error-‐correction coding.

Each MPEG-‐TS packet (Cells) has a fixed 188 bytes, of which the first four bytes constitute the header. The basic format of the MPEG-‐TS header is shown in Figure 2-‐3. It consists of Synchronization byte, which is well known sequence of bits (0x47=01000111) and used to help receiver to recover from the synchronization loss, Payload Unit Start Indicator (PUSI), which is 1-‐bit flag indicate the presence of an additional payload following the header, Transport Error Indicator (TEI), which is 1-‐bit flag indicate the presence of un-‐correctable error in the packet, Transport Priority (TP), which is 1-‐bit flag indicates the priority of the TS cell, 13-‐bit Packet Identifier (PID), which is the most important information in the TS header serves as elementary stream identifier that can identify about 8000 types of packets, Transport Scrambling Control (TSC), 2-‐bits indicate the encryption of the payload, Adaptation Field Control (AFC), which 2-‐bits allow the extension of the TS header with another adaptation field, Continuity Counter (CC), which is 4-‐bits incremental counter incremented with every successive TS packet [19]. Only PID field is of interest for this thesis.



19

FIGURE 2-‐3: MPEG-‐2 TS FORMAT

Each TS stream is identified by a unique PID, so the receiver can filter PES packets at the high lever without performing a hard processing. Figure 2-‐4 shows how the PES packets are placed in the data payload of TS packets.

FIGURE 2-‐4: MAPPING OF ES, PES TO THE TRANSPORT STREAM

2.2.2 Data Encapsulation

MPEG-‐2 packets were originally designed to carry digital TV broadcasting. However, it is possible to carry defined data packets in addition to the audio and video. Transmission of variable length IP datagrams over fixed length MPEG-‐2 transport stream packets requires data encapsulation mechanism. Three different encapsulation protocols are defined to carry IP data packets over the MPEG-‐2 TS packets.

20

2.2.2.1 Multi-‐Protocol Encapsulation (MPE)

The DVB standard [21] has defined the Multi-‐Protocol Encapsulation (MPE) as a standard method to carry IP data packets over the MPEG-‐2 transport streams. MPE has a default header size 12-‐bytes. It is designed to provide a mechanism for transporting IPv4 packets over MPEG-‐2 TS. For other network layer protocols it requires 8-‐byte IEEE 802.2 Logical Link Control/Subnetwork Access Point (LLC/SNAP) additional header. MPE requires the presence of 48-‐bit MAC address of the distant receiver. Figure 2-‐5 shows the overview for MPE encapsulation over MPEG-‐2 TS.

FIGURE 2-‐5: MPE ENCAPSULATION FORMAT OVER MPEG-‐2TS

2.2.2.2 Unidirectional Lightweight Encapsulation (ULE)

ULE has been defined in RFC4326 [30] as an alternative for MPE. It supports transporting of IPv4, IPv6, and other network layer protocols over the MPEG-‐2 transport stream. The higher layer payload is encapsulated in Sub-‐Network Data Unit (SNDU), which is then directly placed into the MPEG-‐2 TS. It does not require destination address to identify the receiver. Figure 2-‐6 shows ULE encapsulation format over MPEG-‐2 TS.

FIGURE 2-‐6: ULE ENCAPSULATION FORMAT OVER MPEG-‐2 TS

The basic header consists of Length, which 15-‐bit field identifies the total length of the SNDU, Type, which is 16-‐bit field indicate the protocol or the next header type, Network Point of Attachment (NPA), 48-‐bit optional field indicate the destination address, NPA presence is indicated by the Destination Absent (D) 1-‐bit field, CRC, 32-‐bit field for transmission error protection.



21

ULE is more efficient than MPE thanks to the smaller and simple header with few fields, which implies less transmission overhead and less complex processing. ULE header contains 16-‐bit type field, which makes it efficient for transmitting different network layer protocols from IPv4, without needing additional LLC/SNAP header required for MPE [30][82]. Table 2-‐1 compares the header overhead and the support for different payload type for MPE and ULE encapsulations.

Encapsulation Header Protocol Header Overhead MPE IPv4 16 bytes MPE with LLC/SNAP additional Header IPv6 16 + 8 = 24 bytes

ULE without NPA address field (D=1) Any 8 bytes

ULE with NPA address field (D=0) Any 8 + 6 = 14 bytes TABLE 2-‐1: MPE/ULE HEADER OVERHEAD

In addition the basic header, ULE specification supports carrying an extension header, which is identified by the 16-‐bit Type field. Any value greater than or equal to 1536 (0x600) indicates a specific type of the encapsulated protocol, i.e. IPv4, IPv6, etc. Type field with values less than 1536 (0x600) indicates the type of the extension header carried by the ULE SNDU.

2.2.2.3 Generic Stream Encapsulation (GSE)

Generic Stream Encapsulation (GSE) has been defined by ETSI [23]. It provides an efficient and lightweight mean for carrying IP packets on DVB physical layers. It is based on the ULE protocol and shares the same extension header mechanism. However, it works in the same level as the Transport Stream, offering an alternative mean of carrying different video, audio, and data packets. The second generation of DVB standards work on multi-‐mode system, which allow the use of either traditional MPEG-‐2 TS or the modern GSE encapsulation. Since the second generation DVB standards (i.e. DVB-‐S2 links) rely on Quasi Error-‐Free (QEF) transmission link, which offers very low bit error rate of approximately 10-‐10 [26], GSE requires CRC only when the SNDU is fragmented. Thus, CRC is responsible for detection of reassembly errors instead of transmission errors. Figure 2-‐7 shows GSE encapsulation format over the physical layer of second-‐generation DVB standards (DVB-‐S).

22

FIGURE 2-‐7: GSE ENCAPSULATION FORMAT

2.2.3 DVB-‐S/ DVB-‐S2

DVB standards are implemented on a worldwide scale for the delivery of digital television. DVB-‐S or “Digital Video Broadcasting – Satellite” [22] is one of DVB standards that, first published in 1994, enables the digital broadcasting of satellite television to the public. It provides a direct reception from the satellite to the home user with an integrated receiver-‐decoder (Direct-‐To-‐Home, DTH).

The standard identifies the physical layer properties in order to adopt the baseband signal produced by the MPEG-‐TS multiplexer to the satellite channel characteristics. Channel adaptation identifies the type of the modulation and coding schemes to meet the aimed quality of the signal. The aimed quality is the provision of “Quasi Error Free” (QEF) channel, which represents a low Bit Error Rate ranging between 10-‐10 – 10-‐11. This adaptation includes different process such as inner coding (i.e. Punctured Convolutional Code), base-‐band shaping and modulation, energy dispersal randomization, convolutional interleaving, and outer coding (i.e. Reed-‐Solomon). Figure 2-‐8 shows the function diagram for DVB-‐S modulation.



23

FIGURE 2-‐8: FUNCTION DIAGRAM FOR DVB-‐S MODULATION

The key advantage of DVB-‐S approach is that the data elements within the MPEG-‐2 TS container can carry timing independence information. This allows different information to be synchronized even if it does not arrive at the receiver at the same time. For example, video can be synchronized with audio at the receiver while both did not arrive at the same time. This feature is very essential for the television broadcasting. Also The DVB-‐S approach provides a high level of flexibility in term of multiplexing. For example, 38 Mbit/s data rate channel could provide one High-‐Definition Television (HDTV) programme or four Enhanced-‐Definition Television (EDTV) programmes or eight Standard Definition (SDTV) Television programmes. Alternatively, a mix of different programmes can be carried over the same container.

DVB-‐S2 [26] is the second generation of Digital Video Broadcasting – Satellite. DVB-‐S2 specification modified the channel adaptation block only. It introduced a new adaptive modulation and coding scheme (ACM), which allow for a 30 -‐ 40 % improvement in bandwidth efficiency over DVB-‐S. It also deified the Generic Stream Encapsulation (GSE) for IP encapsulation over the baseband frames without MPEG-‐2 encoding.

2.2.4 DVB-‐RCS/ DVB-‐RCS2

The success of DVB-‐S standard and the desire to use the existing satellite networks for IP connectivity due to its capability to transmit huge amount of data with flexible way, have resulted in the development of DVB-‐RCS (Return Channel on Satellite) standard [25]. DVB-‐RCS allows bidirectional communications in the return link and share the bandwidth on a Multi Frequency Division Multiple Access (MF-‐TDMA) technology.

24

By mid 2007, there were already more than 150 DVB-‐RCS systems deployed worldwide, serving around 100,000 terminals at Ku-‐band, Ka-‐band, C-‐band and EHF. It can be expected that this number has significantly grown since then2.

Similar to the development of a second generation standard (DVB-‐S2), in 2009 technical work has been started to design a more powerful version of the DVB-‐RCS standard. In 2011, the new standard, DVB-‐RCS2 [25] was approved by ETSI and in 2012 a mobility extensions (DVB-‐RCS2+M) were added in order to support mobile terminals and mesh connectivity, as driven by the market. The final version of DVB-‐RCS2 standard was published in 2012.

Similar to DVB-‐S2, DVB-‐RCS2 introduced a new Adaptive Modulation and Coding scheme (ACM), which offers a significant improvement of the bandwidth available on the return links. Additionally, DVB-‐RCS2 introduced the new “Return Link Encapsulation” (RLE), which offers an efficient and enhanced encapsulation for IP packets directly to the baseband frames (Physical layer), without use of MPEG-‐TS.

2.2.4.1 Bandwidth on Demand

Bandwidth in satellite systems is a resource typically scarce and expensive. To increase efficiency and contain costs of satellite communications, bandwidth on demand (BoD) mechanisms is often employed, able to make shared resource utilization efficient. Adopting the proper Quality of Service (QoS) approach is of paramount importance to allow the optimal response and guarantee target performance to the most widespread TCP/IP applications, in strict co-‐existence and in collaboration with BoD mechanisms.

Satellite networks use a broadcast forward link, following the DVB-‐S/(S2) standard and an interactive return link shared among a set of Satellite Terminals (RCSTs) competing for bandwidth on the return link. With reference to the DVB-‐RCS standard (common standard in Europe), return link is composed of a set of frequencies and uses a TDMA access mechanism, so that each RCST can transmit into a given frequency timeslot and avoid collisions. To extend the flexibility of this approach, the bandwidth allocation (in terms of transmission timeslots allowed) can be dynamic, and based on the variable transmission needs of each RCST (Bandwidth on Demand, or BoD). This technique in the specific case of DVB-‐RCS is called Dynamic Allocation Multiple Access (DAMA). As a drawback, DAMA introduces a further contribution to the propagation delay (sometimes referred as access delay) [19], which in geostationary satellite systems is relevant. In fact DAMA introduces a control loop with specific control messages for the request of resources exchanged with a Network Control Centre (NCC). The DVB-‐RCS standard defines three main types (out of five available) of BoD DAMA allocation schemes, which can also be used in combination:

• CRA (Constant Rate Allocation) -‐ is a fixed allocation, with some transmission timeslots permanently allocated to an RCST irrespective of whether they are actually used or needed. There is no allocation delay experienced, while resources utilization can be very inefficient;

2 DVB Fact Sheet -‐ August 2012 (http://www.dvb.org/resources/public/factsheets/DVB-‐RCS2_Factsheet.pdf)



25

• VBDC (Volume Based Dynamic Capacity) -‐ is a dynamic allocation based on requests of the RCSTs related to the volume of data stored in the MAC buffer. Each request is associated to a given volume of traffic, and requests are cumulative. Access delay is the biggest and almost constant for every packet sent, but resources utilization is the best possible;

• RBDC (Rate Based Dynamic Capacity) -‐ is a dynamic allocation as the VBDC one; differently from VBDC requests are issued for a given data rate (i.e., rate at which data feed MAC buffer) and are valid for a certain time. RBDC has an intermediate value for the access delay, as for resources utilization, in between CRA and VBDC cases.

In the typical context of users broadband access, access to real time streaming applications with strict requirements in terms of bandwidth, jitter and losses is very challenging, especially if taking into account delays introduced by BoD DAMA allocation mechanisms. If not correctly configured, the DVB-‐RCS satellite system can offer a poor performance to the users of these applications [19].

2.3 Issues Related to the Characteristics of Satellite Links

There are some factors and aspects related to the satellite links, which differ from their terrestrial equivalents. These issues may impact satellite communications particularly that concern about network performance and secure communications.

2.3.1 Latency and Bandwidth

Satellite network are designed with a particular propagation delay due to its own characteristics. Propagation delay imposed GEO satellite systems introduces a propagation delay of 500-‐600ms Round Trip Time (RTT). Additionally, adopting DAMA schemes on the return link introduces an additional delay called “access delay”, which is defined as the time the segment spent on the MAC buffer waiting for the actual transmission.

Total delay introduced on the satellite link may degrade the quality of the interactive applications concern voice and data communications. Furthermore, network delay is being a matter for security solutions designers; they need to ensure that the processing delay for the security solution is kept to minimum.

To achieve an efficient satellite services, it is necessary to provide a dedicated bandwidth per user in the same order of magnitude of terrestrial systems. However, recent broadband satellite although allowing a much higher throughput compared to older satellite platforms, the cost per Mbit is still much higher than in terrestrial cases. This bandwidth limitation is challengeable for many interactive communications and security solutions.

26

Satellite links have a high Bandwidth-‐Delay-‐Product (DBP), which refers to the amount of data that sender must transmit at any given time to fully utilize the link capacity. BDP = BW (bit/s). RTT. Thus, it is highly affected by the Round Trip Time (RTT). High BDP means that the transport protocol (TCP) needs to increase the transmission window in order to increase the number of the packet on the fly. This implies a long time spent by TCP to saturate the available capacity, and mostly the data transfers will complete before ever reaching the optimal TCP window size, which can fill the available bandwidth. In fact, this leads to a poor utilization for the available link resources. Additionally, keeping a large number of unacknowledged packets on transmission may imply multiples losses.

2.3.2 Bit-‐Error Rate (BER)

It is assumed that satellite links are Quasi-‐Error-‐Free (QEF) during the period of the link availability. The use of the concatenated Forward Error Correction (FEC) means that there are around 8 decades of Bit Error Rate per dB of carrier to noise ratio, which means that even the significant bit error rate still very small and can be discounted. However, satellite links are highly sensitive by the fades from atmospheric conditions, which may cause significant outage periods and high BER. BER can impact the network throughput, which leads to performance degradation and loss of security synchronization.

2.3.3 Link Asymmetry

Satellite links, both forward and return have different characteristics in term of bandwidth available, latency, bit-‐error rate, and media access mechanism. The network throughput depends on the characteristics of both links, thus the asymmetry may impact the network performance. Additionally, asymmetry is an important factor must be considered while designing a security solution. The security solution should be capable to work over links.

2.4 Performance Enhancing Proxies (PEPs)

Performance Enhancing Proxies [50] are intermediate devices, typically placed on each end of the satellite link or at the first and last hop of the connection. PEPs are used to perform processing on behalf of the TCP endpoints to achieve a greater performance. It does not only servers to enhance the performance, it can also used as a protocol adaptor or convertor that convert the standard TCP of the satellite terminals to another air interface transport protocol (i.e. UDP).

PEPs approach is to solve the issues related to TCP slow start and congestion avoidance phases by accelerating the growth of the TCP window size faster than it is normally done by the protocol. This is accomplished by a technique known as “TCP Spoofing”. Each PEP acts as a TCP endpoint; it automatically sends fake acknowledgements in correspondence to the incoming segments before the destination host has even received them; this is what enables a PEP to rapidly increase the TCP window size. In this way, the delay needed by the terminal in



27

order to receive acknowledgments and send a new segment has been reduced to the similar delay experienced by terrestrial link. The main drawback of this technique is that it does not respect the end-‐to-‐end semantics, introducing problems to the interactive applications, which mainly relies on these properties. Additionally, in this scheme, in order to avoid duplicate acknowledgments (real and fake ACKs) arriving on the TCP segment originator, the real ACKs generated by the receiver must be intercepted and suppressed. However, in case of lost segment, the originator’s PEP is responsible for retransmitting the missed segment. Thus a symmetric routing is required to allow the TCP segment and related acknowledgment to pass through the same path. Figure 2-‐9 describes PEP TCP spoofing technique.

FIGURE 2-‐9: TCP SPOOFING PEPS

Another technique used by PEPs is called “Splitting”. In this approach, the TCP connection established between two terminals is split into three separate connections, two of them are linking the endpoint hosts with the satellite PEP, and the third is linking between both PEPs over the satellite portion. The main added value of this technique is hiding the satellite link from the end users, while it take advantage of using specific transport protocols over the satellite links i.e. SCTP, XTP, etc. Figure 2-‐10 show TCP splitting approach.

28

FIGURE 2-‐10: TCP SPLITTING PEPS

29

3 SECURITY IN DVB-‐RCS SATELLITE NETWORKS

Satellite networks are generally lacking in the physical security. The open wireless characteristics of the satellite links, such as the broadcasting nature and the wide coverage, make satellite networks, either commercial or military, particularly vulnerable to different security threats. Unauthorized access, eavesdropping, traffic hijacking, and masquerading are just a few forms of attacks that can be performed against satellite communications. Therefore, these security issues suggest to satellite providers to consider the security as an important part of the system design.

Security mechanisms can be introduced in every layer of the OSI stack, from application layer to the physical one. RFC 5458 [40] recommends to place the security services on the link-‐layer, in order to benefit from several advantages, such as protection of the whole data unit, protection of the receiver identity, transparency of the higher layer protocols, allowing the use of different networking techniques, e.g., PEPs, IP compression, or NAT. Additionally, security provision at that or lower layer can provide an efficient protection of multicast traffic. Also end-‐to-‐end security solutions such as IPSec and TLS protocols can be considered to provide a reliable level of protection for the satellite links but they may inherit shortcomings. For example, IPSec, introduces incompatibility issues with Performance Enhancing Proxies (PEPs), which are largely used in satellite networks, and affects system performance due to the large overhead and additional delay due to the necessary round trip messages.

30

3.1 Main Threats on the Satellite Links

A threat is generally defined as any potential action that causes damage to the network or the system assets.

The potential threats and attacks that satellite networks may face can be divided into two classes: passive and active attacks. The passive attacks are the most relevant ones for satellite links due to the wireless broadcast nature of the communication. An attacker can tune to different frequencies and receive traffic destined to other terminals using an inexpensive satellite terminal and basic knowledge of the communication protocols (more difficult in case of proprietary standard). The attack, easier if no encryption is used, could reveal potentially sensitive or valuable data. In addition, this kind of attack is difficult to detect since it does not require any data modification or alteration.

Active attacks include a vast gamut of alternatives:

• Denial of Service (DoS Attacks), an attacker makes the system unavailable or prevents it from performing the proper functions for a limited period of time,

• Masquerading Attacks, an attacker can impersonate an authorized user identity to delude the trusted communicating parties,

• Replay Attacks, an attacker intercepts the traffic between two legitimate entities and replays them when he needs to,

• Traffic hijacking, an attacker is able to delay, redirect, or modify the messages exchanged between the legitimate communicating entities, also injecting forged or customized messages within the user traffic.

Generally, active attacks are more complex and typically require expensive equipment, knowledge of the communication standards and direct access to the transmitter network and/ or the terminals/ GW.

3.2 Security Requirements

To cope with the aforementioned threats, there are six main requirements for secure communication systems detailed in RFC 4949 [71]:

• Confidentiality, which offers protection of the traffic data against unauthorized disclosure of information; it is achieved by encrypting each message before sending, making it readable only by the intended receivers;

• Mutual Authentication, that implies that the communicating parties must be able to prove their identities before initializing the connection; mutual authentication prevents the intruder from impersonating sender or receiver identities to mislead the legitimate users;

• Integrity, which provides protection against the unauthorized modification of the data, allowing the authorized users to verify that received data is not modified during the transmission;


Security in DVB-‐RCS Satellite Networks

31

• Availability, which assures that the system and network resources are always accessible and available to the authorized users when needed;

• Authorization, which ensures that the users have the right permissions or privileges in order to access the system resources;

• Non-‐repudiation, which ensures that a party that has sent or received a message cannot deny having sent or received it.

In addition to these general security requirements, satellite networks have special security requirements coming from their peculiar characteristics.

• Link-‐Layer security -‐ Security solutions for broadband satellite networks have to be carefully designed. The architecture must identify the ideal layer for placing the security services, avoiding replications of functionalities already included and incompatibilities with present protocols and network nodes. For example, placing the security service on the network layer (adopting IP frame) may provide secure end-‐to-‐end connection, while it may introduce some incompatibilities with Network Address Translation (NATs) [3] and TCP Performance Enhancing Proxies (PEP) [50] both requiring the ability to inspect and modify the packets sent through a satellite link. On the other hand, placing the security solutions below the PDU encapsulation function, for example on the MPEG-‐TS streaming function, protection against outsider attacks; however can be provided. MPEG-‐TS typically multiplexes IP flows from different users. Therefore, all multiplexed traffic must share the same security keys, enabling each user to monitor the traffic of the other users.

RFC 5458 [39] recommends placing the security protocols at link-‐layer, as it can provide individual protection for each user equivalent to the wired networks. This solution, being transparent to the higher layers protocols, is compatible with NAT, PEPs, and other higher layer protocols. Moreover, link layer security can provide a protection to multicast and broadcast traffics.

• Security overhead -‐ satellite networks generally have limited bandwidth on the return link, and hence they are sensitive to the data overhead added by security mechanisms; therefore, the applied security mechanisms should add a minimal overhead while ensuring the required security services;

• Efficient key management -‐ security mechanisms are required to support both automatic and manual distribution of encryption keys and security policies.

• Manageability and Scalability -‐ very critical issues in the modern wireless networks, and in particular for broadband satellite networks, which can grow up to thousands of STs; any security mechanism must provide flexible and scalable solutions to support a wide deployment.

32

• Cryptographic agility -‐ the security mechanism must allow the update of the crypto algorithms and hashes when they become obsolete without affecting the overall security of the system;

• Multicast support -‐ multicast applications are efficiently supported over the satellite downlink; a multicast transmission allows the source to send data simultaneously to multiple clients whilst transmitting only a single copy to the network.

3.3 Current Security Techniques: State-‐of-‐the-‐Art Review

Most of satellite providers rely on their own proprietary security solutions (e.g. Comtech’s Streamline Encapsulation [14] or Newtec’s Extended Performance Encapsulation (XPE) [86], while military services implements unique and complex security measures that imply decrease of performance. Nonetheless, relying on undocumented and unstandardized protocols and proprietary security mechanisms exposes the system to high-‐risks and limits the interoperability of equipment from different manufacturers. For example, a recent research from IOActive [73] reported critical vulnerabilities in six different satellite network terminals manufactured by three different vendors and used for military, aerospace communications, maritime communications, and home users. These vulnerabilities include undocumented protocols, hardcoded credentials, insecure protocols, and backdoors.

On the other hand, three security frameworks can be identified for IP services over DVB-‐RCS links, which is the reference scenario for this work. DVB-‐S proposes a Common Scrambling for encryption of satellite downstream. DVB-‐RCS standard [24] introduces an Individual User scrambling for interactive satellite networks. Finally, IPSec and other Internet upper layer security protocols can be included as possible security solutions for the target scenario. Such mechanisms are described in the next sub-‐sections, highlighting their limitations and drawbacks.

3.3.1 DVB Common Scrambling

Common Scrambling Algorithm (CSA) [27] is used to secure MPEG-‐2 TS forward link by encrypting the broadcast traffic so that only authorized users can access the audio/video channels. This encryption algorithm uses per flow only one key, which is shared among all the receivers for decryption. Therefore, it is not a suitable mechanism for the encryption of IP over MPEG-‐2 TS because any user holding the key can use it to decrypt the traffic destined to other users. As a consequence, this mechanism won’t be addressed in details in this document.

3.3.2 DVB-‐RCS Privacy “Individual User Scrambling”

DVB-‐RCS standard [24] identified an optional security mechanism for an individual user scrambling over interactive satellite networks. This security mechanism is implemented at



33

the Data-‐Link layer to obtain an inherently secure system. It consists of two main stages: the first is a set of message exchanges used for authentication and key agreement; the second stage provides on the fly encryption and decryption for the data stream. Finally, each RCST holds 160-‐bit pre-‐shared secret, called “cookie”, stored in non-‐volatile memory, while the NCC keeps a database with cookies of all RCSTs.

The general scheme is shown in Figure 3-‐1. When a user terminal behind the RCST requests to use the satellite link, it sends a logon request to the NCC. Next, both NCC and RCST perform security handshake procedure composed of Sign-‐On Request/Response messages to agree the security profile and to negotiate a set of cryptographic primitives and key sizes. In fact, the NCC indicates supported cryptographic parameters and algorithms in the Sign-‐On request message, while the RCST indicates the specific parameters to be used in Sign-‐On response message.

For authentication, the specification identified three key exchange mechanisms aimed to both authenticate the RCST and agree on a session key. The three key exchanges and their principal features are:

• Main Key Exchange (MKE) -‐ it uses Diffie-‐Hellman scheme to allow both NCC and RCST to agree on a shared secret; consequently, the shared secret is used as an input to hash functions to derive the session key;

• Quick Key Exchange (QKE) -‐ it uses the cookie to authenticate the RCST to the NCC similarly to MKE; it derives a session key directly from the cookie;

• Explicit Key Exchange (EKE) -‐ the NCC generates the session key, and then transmits the encrypted session key to the RCST.

In every case, once the session key has been agreed between the NCC and the RCST, the secure communication is established. Symmetric key block cipher will be used for encryption of transmitted data and an 8-‐bit counter is used to prevent the cloning of the RCST.

34

FIGURE 3-‐1: KEY EXCHANGE MECHANISMS

3.3.3 IP or higher layer security mechanisms

IPSec [53] or higher layers security protocols, such as TLS [83], PGP [51], SSH [84] or other application layer security protocols represent suitable options to secure IP traffic over MPEG-‐2 TS. However, these standard security protocols employed for end-‐to-‐end communication in terrestrial networks perform poorly in the satellite networks. In particular, IPSec operates at network layer and is widely used in IP networks to provide end-‐to-‐end security. On the other hand, IPSec provides data protection through the use of Encapsulating Security Payload (ESP), where the IP payload, including the TCP header and all other upper layer information, is encapsulated and encrypted. Satellite links often exploit Performance Enhancing Proxies (PEPs), which mainly split TCP connections in order to use an optimized transport protocol over the satellite segment. Hence, IPSec is incompatible with several PEP functionalities, which require access to TCP header information. IPSec can be used together with PEPs only in the following configurations [36]: TCP header is encrypted with a key shared between the terminal and the PEP, while the payload is encrypted with a different key, shared by the end users. However, this approach revokes the concept of end-‐to-‐end security since the trust relationship between the endpoints depends on an intermediate node on the network.

The limitations of using IPSec to secure satellite-‐based links have been discussed in several studies [36] and include high overhead and lack of support for multicasting. Transport layer security protocols, such as SSL (Secure Socket Layer) and TLS (Transport Layer Security) also have drawbacks that make them inefficient in some circumstances. For example, TLS is only able to secure TCP flows and does not provide any security mechanisms for UDP flows, which support most of the real-‐time applications, such as telemedicine or video surveillance systems.



35

3.3.4 ULE Security Extension Header

ULE encapsulation does not provide any security mechanism but its specification supports carrying an extension header, as defined in [30], which can be utilized to provide secure ULE encapsulation over DVB-‐S/RCS.

Different security extension headers for ULE have been presented [40][59][11] and a unified lightweight security extension header is identified in [60][58] to address the security requirements within RFC5458 [39] but so far none of these proposed solutions have been standardized as mandatory security extension header for ULE.

Lightweight security extension header (Figure 3-‐1) suggests using a 16-‐bit security identifier (SID), similar to the Security Parameter Index (SPI) used in IPSec, to filter the security policies for transmitted and received traffic. It also suggests using a key to encrypt the data payload and receiver address. Message Authentication Code (MAC) is suggested to provide authentication and integrity. It finally suggests adding a sequence number to the SNDU for reply attack protection.

The lightweight security extension header satisfies most of the security requirement of DVB-‐S/RCS; however, using message authentication code (MAC) may not be reliable for source authentication. In fact, being MAC a symmetric function, anyone holding the key, such as a legitimate receiver, can pretend to be the real author of the authenticated message. This is an issue in environments where there are multiple senders, like mesh networks.

FIGURE 3-‐2: LIGHTWEIGHT SECURITY EXTENSION HEADER

Moreover, the security of the suggested mechanism depends on the security of the key management system and how the encryption key is generated and distributed among the communication parties. Key management protocols for secure ULE can be implemented at different layers: DVB-‐RCS at the link layer, IKEv2/IPSec at the network layer, TLS at transport layer and SSH at application layer. However, DVB-‐RCS link layer key management technology is the most directly usable for ULE [40].

36

3.3.5 DVB-‐RCS Security Framework For ULE-‐Based Encapsulation

In addition to security techniques mentioned above, an additional security framework to secure ULE traffic is proposed [75], while making use of the built-‐in key management mechanism identified in the DVB-‐RCS privacy mechanism. This security mechanism utilizes the features of ULE security extension header and adapts it to the existing DVB-‐RCS link layer security specification, benefiting from mutual authentication and the built-‐in key management system to provide an enhanced and lightweight security mechanism for ULE traffic over DVB-‐RCS.

To secure ULE traffic using DVB-‐RCS data link layer privacy system, a new security extension header is proposed, which is aiming to:

a) associate the encryption key and security information to the ULE SNDU; b) inform the receiver about the used cryptographic context by exchanging sign_on

MAC messages after the successful authentication of RCST; c) hide the traffic characteristics by encrypting the data carried on the SNDU, the

data type field, and the real destination address.

Figure 3-‐3 shows the proposed security extension header for ULE over DVB-‐RCS, with in grey the proposed extensions:

FIGURE 3-‐3: ULE SECURE SNDU

• Type Field (16-‐bit) indicates the type of the extension header (Secure_ULE); • Receiver Destination NPA Address (48 bits) optional field in the standard ULE

header to identify the destination address; present if D = 0 and absent if D = 1; when ‘hiding destination identity’ is enabled, this field is omitted and replaced with the encrypted NPA address field in the security extension header;

• Reserved (10-‐bit) additional field for future use, reserved for header alignment; • Key_id field (6-‐bit) referring to the class Security_Ctxt_Version_Flow in the sign-‐on

MAC message to identify the security context for DVB-‐RCS security which contains two session keys; only one key is used for encryption and decryption of a payload stream;

• Encrypted Destination NPA Address (48 bits), if the destination address NPA field is exist (D=0), it has to be removed from the standard ULE header, D bit changed to



37

1, encrypted NPA field inserted to ULE security extension header which will be encrypted along with the (Protocol Data Unit) PDU;

• Encrypted Next PDU Type field (16 bit), indicate the type of the ULE PDU or the type of the next extension header.

To secure the ULE data streaming, the key_id field (greyed in Figure 3-‐4) is mapped to the proposed ULE security extension header (Figure 3-‐3) to associate the security context identified within the Sign-‐On MAC message to the ULE SNDU stream. Key_id field in the extension header is used to represent the security association between the transmitter and the receiver. As soon as transmitter and receiver will have matched security context, they will be able to use it to encrypt/decrypt both upstream and downstream. The receiver will be able to use the key_id in addition to the address information of the received SNDU to filter the received traffic.

FIGURE 3-‐4: SIGN-‐ON MAC MESSAGE STRUCTURE

Security Policy Database (SPD) contains a list of security policies for incoming and outgoing traffic in both sender side and receiver side. Each security policy contains some security parameters (i.e. cryptographic algorithm and parameters, key information). Security policies will be dynamically distributed through DVB-‐RCS key management process over the MAC messages. Security Association Database (SAD) contains a list of security association (SA) describing the state of the connection. Each SA is a set of security policy instruction to describe the status of the secure connection between the sender and receiver. SA contains important information about the cryptographic context used i.e. key_id, and the other security parameters identified by the NCC to RCST during the negotiation procedure.

38

Efficiency of the proposed security extension header has been evaluated and compared to other type of encapsulation and security mechanisms available for DVB-‐RCS [75].

3.4 Weaknesses of DVB-‐RCS Privacy

After solving the compatibility issue of DVB-‐RCS privacy mechanism and the ULE encapsulation, as described 3.3.5, it is decided to evaluate the DVB-‐RCS privacy mechanism in terms of security, performance, and incompatibility.

DVB-‐RCS privacy mechanism presented in sub-‐section 3.3.2 was identified in the DVB-‐RCS standard published in May 2009 [24]. However, this mechanism is derived, with minor modifications, from the security mechanism of DVB Interaction Channel for Cable TV Distribution Systems (CATV) [20] published in October 2001. Therefore, employing a security mechanism designed for the Cable TV may not be adequate and fully compliant to the security requirements of satellite networks. In addition, designing a security specification based on an old or out-‐dated security framework may provide risks instead of security.

This section pinpoints the main problems, limitations, and vulnerabilities of DVB-‐RCS privacy “Individual User Scrambling” security framework.

3.4.1 Mutual Authentication

A first weakness in the DVB-‐RCS privacy mechanism is the use of one-‐way authentication. Only the NCC authenticates the RCST, there is no provision for mutual authentication. In fact, this makes the satellite network potentially vulnerable for different types of attacks such as man-‐in-‐the-‐middle. For example, RCST can communicate with an illegitimate NCC, exchange security parameters, and exchange traffic. Consequently, the attacker updates the RCST’s cookie causing a denial of service when it connects back to the legitimate NCC.

3.4.2 Security Messages Integrity

DVB-‐RCS Individual User Scrambling uses a message exchange at the MAC layer for security policy agreement, authentication, key agreement, and key update. However, the specification does not provide any mechanism to ensure the integrity of these messages. Hence, an intruder can tamper or generate security messages. Thus, it can, for example, determine the terminal to change its session key.

3.4.3 Data Encryption and Integrity

DVB-‐RCS provides on the fly data encryption/decryption using a symmetric block cipher. However, the specification only supports Data Encryption Standard (DES) with 40-‐bit key length as minimum-‐security requirement and 56-‐bit keys length as an optional. 56-‐bit keys are no longer considered secure since key space is very small, and it can be broken by brute



39

force in relatively short time [85]. Moreover, this security specifications do not provide any integrity and authenticity protection for the data payloads, i.e. using Message Authentication Codes.

3.4.4 Destination Address Protection

Destination address (ATM VPI/VCI or MPE MAC address) is not scrambled. Thus, the traffic can be vulnerable to traffic analysis where the eavesdropper can track the receivers and the volume of their traffic.

3.4.5 Unsigned Diffie-‐Hellman Parameters

The DVB-‐RCS privacy mechanism depends on Diffie-‐Hellman algorithm with unsigned integer scheme, to allow the NCC and RCST to agree on a shared secret. However, the public values are exchanged between NCC and RCST without mutual authentication, i.e. they do not use certificates. Diffie-‐Hellman unsigned key exchange is vulnerable to man-‐in-‐the-‐middle attack [72]. Hence, if the attacker can perform a man-‐in-‐the-‐middle attack, he can also establish two shared secrets, one with the NCC and the other with RCST, while the NCC and the RCTS will think they are sharing the secret between each other.

3.4.6 Key Derivation from the cookies

DVB-‐RCS specification has identified the Quick Key Exchange (QKE) for RCST authentication and derivation of the session key used for the data encryption. Accordingly, the NCC sends its Nonce to the RCST, then the RCST replies with its Nonce value and the authentication value “Auth”. Then, both NCC and RCST derivate the session key directly from the cookie’s value using an HMAC hash function. In fact, this independency of the session key derivation from the authentication process reveals to any eavesdropping party what the session key has been agreed upon. Definitively, this mechanism doesn’t provide forward secrecy: if the cookie’s value is compromised, the secrecy of previously established session keys is affected. For example, the attacker can passively listen to the traffic recording and storing the important values (nonce1, nonce2, and Auth), in order to perform brut-‐force attack against the cookie value. As a result, the obtained cookie’s value can be used to derive any past session keys.

3.4.7 MPE/ ATM Limitation

DVB-‐RCS privacy provides the security mechanism for ATM and MPE encapsulations only. However, MPE is proven to be less efficient with more overhead than the modern encapsulation protocols such as ULE and GSE. In addition, MPE supports only IPv4 traffic and requires Logical Link Control/Sub-‐Network Attachment Point (LLC/SNAP) additional header

40

to support other network layer protocols. In contrast, ULE and GSE provide an easy and efficient encapsulation for any network layer protocols over DVB-‐S and DVB-‐RCS with an improved transmission performance compared to MPE [72].

3.4.8 Multicast Support

DVB-‐RCS privacy mechanism mentioned the use of Explicit Key Exchange (EKE) for multicast (Section 9.4.6.1 of the standard [24]). However, it is not clear how the multicast encryption key is exchanged through EKE messages, and how this key can be linked to a multicast group, or generated from a specific multicast security profile. Also, rekeying of the multicast groups is not defined. Since only one key is used per session, it is expected that this key will support both unicast and multicast traffic to the RCST. Modifications to security specification are proposed by [32] to support multicasting, but it did not address any of the weaknesses discussed above.

41

4 ROBUST SECURITY FRAMEWORK FOR DVB-‐RCS SATELLITE NETWORKS (RSSN)

Based on analysis of the security threats and requirements, and weaknesses of the current satellite security mechanism (in Chapter 3), it is decided to study the current practices for security mechanism used in the modern commercial wireless networks to identify the best mechanisms framework suitable for satellite networks or at least to get some useful hints. The study covered a relevant set of modern wireless technologies including WLAN, WiMax, Bluetooth, Zigbee, and UTMS. Table 4-‐1 summarizes the security review for these wireless technologies.

Technology Mechanism Description Drawback and Analysis

WLAN IEEE802.11i

§ New security architecture called Robust Security Network Association (RSNA) [46]. RSNA is a link-‐layer security mechanism providing enhanced mutual authentication, advanced data confidentiality, data authenticity and integrity, reply protection, and robust advanced cryptographic key management mechanism;

§ Protects unicast, multicast, and broadcast traffics between the

§ Authentication and key derivation process requires multiple round-‐trip messages to perform the authentications and key distribution. This can be bulky time-‐consuming for initial link setup in case of satellite networks.

42

wireless client and the access point or between two wireless stations;

§ Relies on 802.1x for access control, EAP for mutual authentication, CCMP for data confidentiality and integrity;

§ Secure key derivation mechanism consists of 4-‐Way Handshake to derive and agree on the pairwise encryption keys, and Group Key Handshake to transmit the multicast/ broadcast group key from the access point to the wireless client.

•

WiMax

IEEE802.16

§ IEEE802.16 identified a link-‐layer security [36]. It provides one way authentication, to authenticate the user to the network;

§ Support two ways for authentication, either using X.509 certificates or using EAP;

§ For data encryption, it uses DES in either CBC mode or AES-‐CCM mode.

§ It can be vulnerable to some “man-‐in-‐the-‐middle” attacks [68] because there is no mutual authentication for end Users. The new version of Privacy and Key Management protocol (PKMv2) is identified in the enhanced 802.16e specification. However, the new PKMv2 protocol is vulnerable to some attacks [88];

§ It requires each client to hold a unique certificate. For satellite networks, this may introduce some scalability and manageability issues.

Bluetooth

IEEE802.15.1

§ Security provided at both the application layer and the link-‐layer. The current specification defines a security mechanism at the link level only, while the application determines security property to use;

§ Authentication is based on challenge-‐response, and the application decides which type of authentication is required;

§ The data payload encryption is processed with a stream cipher called E0.

§ Bluetooth security is very complex and many applications can be designed and implemented. This makes the technology somewhat complicated and cumbersome to deploy especially when security is a priority.

Zigbee

IEEE802.15.4

§ Basic security mechanism, transceiver holds a list of “trusted peers” along with corresponding the security policy;

§ A simple Message Integrity Code (MIC) is used to provide message authentication and integrity;

§ Data can be protected using different cipher suites such as AES-‐CTR and AES-‐CCM;

§ Simple key management mechanisms with three keying models: i) network keying, where all stations use the same key to communicate. ii) pairwise keying, each pair of nodes sharing a unique key. iii) group keying, single key shared among a group of nodes.

§ This security mechanism is designed for nodes with limited resources. Usually, limited power, memory and processing capability prevent implementing an advanced and complex security solution.


Robust Security framework for DVB-‐RCS Satellite Networks (RSSN)

43

UMTS

§ Universal Subscriber Identity Module (USIM), sets up a protected connection between the user equipment (UE) and the serving network (SN);

§ Both the UE and the SN are mutually authenticated. Set of cryptographic functions called “MILENAGE” is used to provide challenge-‐response authentication, key derivation;

§ Confidentiality and integrity services are based on a block cipher algorithm called “KASUMI”.

§ UMTS security architecture is the lack of integrity for the user data. Integrity is provided only for system signalling;

§ Security architecture doesn’t support public key cryptography. Public key is a useful approach from security point of view. However, they are computationally extensive and usually require more signalling overhead.

TABLE 4-‐1: SECURITY REVIEW, CURRENT COMMERCIAL WIRELESS NETWORKS

Relying on the state of the art for the modern security mechanisms of different wireless networks, this chapter goes on to draw the main objectives and guidelines for a link-‐layer security framework applicable for DVB-‐RCS satellite networks. Its key aspects are:

• Target – A link-‐layer security framework tailored to secure user data in unidirectional broadcast, multicast, and point-‐to-‐point satellite links and designed to efficiently satisfy the security requirements discussed in Section III, considering the characteristics of satellite networks.

• Orientation -‐ to leverage on the mature and robust security technology 802.11i WLAN RSNA [46]; rather than using the current full RSNA framework, specific methods have been designed for every security stage and rationally integrated on the satellite network.

• Security -‐ The resulting security level must be not lower than the one provided in 802.11i WLAN networks;

• Performance – performance must be optimized with respect to the other security practices currently deployed on satellite networks;

• Compatibility and Manageability -‐ It must be compatible with the lightweight encapsulation protocols and the IP network layer techniques deployed on the satellite networks; additionally, it must provide an acceptable level of manageability and extensibility to facilitate the deployment procedures applied by service operators.

4.1 RSSN Framework Description

This section describes in detail the proposal of the new Robust Security Satellite Network (RSSN) framework, for data connectivity over DVB-‐RCS satellite networks. It describes the life cycle model for RSSN framework starting from terminal log-‐on and ending with security termination and terminal log-‐off. It will also highlight the strength points for each phase in the life cycle.

44

Special SNDU is used to provide a way to transport the security messages exchanged during the different phases of RSSN. The structure of the security SNDU is similar to the structure of a normal encapsulated SNDU. It only contains a header that identifies its type as a “Security Message”, as explained in Phase 4. In fact, due to small size of most security messages, the carrier SNDU is sent over MPEG-‐TS frames that also contain data SNDUs.

The proposed RSSN framework envisages six phases: security agreement, mutual authentication, key derivation and distribution, data protection, rekeying, and log-‐off.

4.1.1 Phase 1: Discovery, Logon, and Security Agreement

DVB-‐RCS standard defines RCST discovery and logon procedures. After the RCST powers on, it performs initial synchronization procedures to log on to the NCC and to be registered in the network. During the initial synchronization stage, RCST sends a logon request on the Common Signalling Channel (CSC), through Slotted-‐Aloha random access. Logon request encapsulates the Terminal MAC address and terminal capabilities, including security support, terminal software version, type of supported streams, and frequency range. CSC burst is encoded and identified by a “Preamble” with a variable size for burst detection and identifying the start and end of the burst. A 1-‐bit field in the logon message indicates if the RCST supports security.

When the NCC receives the logon request, it identifies the terminal from the MAC address, checks the validity of the account and other administrative aspects. If the verification of the results is positive, the NCC responds with a unicast Terminal Information Message (TIM) to the RCST. The TIM includes two important tables supporting secure communications. The first table is called Return_interaction_path_descriptor and informs the RCST about the PID to use on the return link for every data stream. It is a 13-‐bit value with 3-‐bits reserved and used to identify the specific MPEG-‐2 stream. The second table is the Logon_Initialize_Descriptor, which provides the basic network functionalities and indicates if security is required through the security_handshake_required 1-‐bit field.

In the proposed RSSN scheme, password is a long term shared secret, witch was previously shared between each RCST and the NCC. The password can be inserted manually by the user behind the RCST, or stored on smart card, or a secure media. On the other hand, the NCC maintains a database of all passwords stored in randomized values as a password-‐equivalent, rather than the clear text password.

To proceed with a secure communication, the NCC and the RCST need to agree the cryptographic algorithms and the security capabilities to be used during the later phases. As well as 802.11i, the proposed RSSN envisages that the NCC and RCST negotiate a set of cryptographic algorithms and security capabilities, called RSN Elements (RSNE). However, a simpler version of the RSNE is proposed to agree on the following information only:

• Mutual Authentication and key management methods, for example 802.1X, EAP method, Hash function, and key length;

• Encryption and integrity cryptographic algorithms, for example CCMP.



45

Unlike 802.11i, where the station gets the WLAN information through the proactive scan, in RSSN scheme the NCC initiates the security negotiation stage by sending a “Sec_Req” message that contains the NCC RSNE proposition for the cryptographic algorithms and parameters, in addition to the NCC identity (NCC-‐ID) that can be MAC address or a temporary ID agreed between NCC and RCST after every successful authentication. The RCST selects which algorithms and parameters to use from the proposed RSNE, by choosing at least one suggestion for every parameter proposed by the NCC. The RCST replies to the NCC with a “Sec_Resp” message, which contains RCST identity (RCST-‐ID) and RSNE selection. Figure 4-‐1 shows the message exchange between NCC and RCST during phase 1 in order to establish security agreement.

FIGURE 4-‐1: MESSAGE EXCHANGE – PHASE 1

4.1.2 Phase 2: Mutual Authentication

Similar to 802.11i, RSSN depends on 802.1X standard [47] for mutual authentication between NCC and RCST. Therefore, the EAP authentication framework [4] is applied. The flexibility of EAP makes it an ideal solution for authentication in the satellite networks, especially in the lower layers, and it provides transparent authentication and key derivation mechanisms. However, EAP is a new concept in the satellite networks and so far no identified EAP methods are identified.

The existing EAP methods are designed for specific frameworks and need a different number of round-‐trip messages to achieve the authentication and key distribution. For example, EAP-‐TLS needs 13 messages, PEAP needs 16 messages, and EAP-‐EKE needs 7 messages. Large number of messages implies that a lot of time is needed for NCC and RCST to authenticate each other, which is inefficient for satellite networks considering the long delay. Hence, a new EAP method (EAP-‐SAT) is proposed, which is optimized for the authentication phase of RSSN framework.

46

Our proposed EAP-‐SAT is derived from EAP Encrypted Key Exchange (EAP-‐EKE) [39] properly modified to take into account peculiar satellite network characteristics. To shorten the authentication delay, EAP-‐SAT foresees just three messages for mutual authentication instead of seven as in AEP-‐EKE. Moreover, EAP-‐SAT presents more efficient key management and add security features. For example, it derives earlier the integrity key (Ki) and it uses this key to protect the integrity of the authentication messages. In fact, this protection is not offered for the first three messages of EAP-‐EKE.

EAP-‐SAT authentication method is based on Diffie-‐Hellman algorithm, and the pre-‐shared “Password”.

The first EAP-‐SAT authentication message (EAPMsg1) {𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃 (𝐾𝐾𝐾𝐾,𝐾𝐾𝐾𝐾,𝑔𝑔|𝑝𝑝|𝑇𝑇 |𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛1)} is sent to the RCST from the NCC. This is a protected message, which means that it is encrypted and integrity protected. Ke and Ki are encryption key and integrity protection key respectively, derived using the following PRF-‐X pseudorandom function 𝐾𝐾𝐾𝐾|𝐾𝐾𝐾𝐾 = 𝑃𝑃𝑃𝑃𝑃𝑃 −𝑋𝑋 (𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇,𝑁𝑁𝑁𝑁𝑁𝑁 − 𝐼𝐼𝐼𝐼|𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 − 𝐼𝐼𝐼𝐼) , where Temp is the output of the hashed Password, computed using HMAC hash function random number generator as a hash key [Temp = PRF (0+, password)], 0+ is a random number generator with a length equal to the output of the hash (160 for HMAC), X is the key size. Since the required keys size (X) has to be larger than the output of the HMAC-‐SHA1 (160-‐bit), multiple iterations of the PRF function are used, and then outputs are concatenated together. g, p, and T are Diffie-‐Hellman values (T= g^y mod p). nonce1 is the random value generated by the NCC.

Upon receiving the first authentication message, the RCST similarly derives the Ke and Ki from the Password to verify the integrity and decrypt the message received. Consequently, RCST generates its Diffie-‐Hellman secret value x and calculates its public key R. Additionally, RCST generates random value, nonce2. However, before sending the reply message to the NCC, the RCST will compute the Shared Secret (𝑆𝑆) = (𝑔𝑔^𝑥𝑥𝑥𝑥 𝑚𝑚𝑚𝑚𝑚𝑚 𝑝𝑝). Therefore, S is used as an input to the keyed hash function to generate the RCST authentication value “Auth-‐RCST” and Auth encryption key (Ka), where

𝐴𝐴𝐴𝐴𝐴𝐴ℎ − 𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 = 𝑃𝑃𝑃𝑃𝑃𝑃 (𝐾𝐾𝐾𝐾, 𝑆𝑆𝑆𝑆𝑆𝑆_𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 𝑆𝑆𝑆𝑆𝑆𝑆_𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 𝐴𝐴𝐴𝐴𝐴𝐴M𝑠𝑠𝑠𝑠1) , 𝐾𝐾𝐾𝐾 = 𝑃𝑃𝑃𝑃𝑃𝑃 − 𝑋𝑋 (𝑆𝑆,𝑁𝑁𝑁𝑁𝑁𝑁 −𝐼𝐼𝐼𝐼|𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 − 𝐼𝐼𝐼𝐼|𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛1|𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛2) .The previously exchanged messages during phase1 (Sec_Req/ Sec_Resp) are used in Auth calculation including the header and the payload. Therefore, Auth value is used to ensure the authenticity of the unprotected security agreement messages of phase1.

Finally, RCST replies to the NCC with the second authentication message (EAPMsg2) {𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃 (𝐾𝐾𝐾𝐾,𝐾𝐾𝐾𝐾,𝑅𝑅|𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛1|𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛2),𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸 (𝐾𝐾𝐾𝐾,𝐴𝐴𝐴𝐴𝐴𝐴ℎ − 𝑅𝑅C𝑆𝑆𝑇𝑇)}

Upon receiving the second authentication message, the NCC verifies the integrity of the protected part using Ki, and use Ke to decrypt the message. Similarly, the NCC computes S and Ka. Furthermore, the NCC computes the Auth-‐RCST and uses it to check the correctness of the received value. If the received Auth-‐RCST value is different from the value computed by the NCC, the authentication of the RCST fails and the authentication phase will be terminated; otherwise, the authentication of the RCST succeeds.



47

For the mutual authentication, similarly to RCST, the NCC prepares its authentication value (Auth-‐NCC) then encrypts it using the computed

𝐾𝐾𝐾𝐾.𝐴𝐴𝐴𝐴𝐴𝐴ℎ − 𝑁𝑁𝑁𝑁𝑁𝑁 = 𝑃𝑃𝑃𝑃𝑃𝑃 (𝐾𝐾𝐾𝐾, 𝑆𝑆𝑆𝑆𝑆𝑆_𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅|𝑆𝑆𝑆𝑆𝑆𝑆_𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅|𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴1|𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴2).

The NCC sends the last authentication message (EAPMsg3) to the RCST to prove its identity

{𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃 (𝐾𝐾𝐾𝐾,𝐾𝐾𝐾𝐾, 𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛1),𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝 (𝐾𝐾𝐾𝐾,𝐴𝐴𝐴𝐴𝐴𝐴ℎ − 𝑁𝑁𝑁𝑁𝑁𝑁)}

Upon receiving the last authentication message, the RCST first validates the integrity of the message, and then decrypts the Auth-‐NCC value. Finally, it compares it to the calculated Auth. The correctness of Auth-‐NCC value proves the NCC identity.

Upon the successful mutual authentication between the NCC and RCST, both are able to generate a common secret called Master Shared key (MSK) using this keyed-‐hash function

𝑀𝑀𝑀𝑀𝑀𝑀 = 𝑃𝑃𝑃𝑃𝑃𝑃 − 512 (𝑆𝑆,𝑁𝑁𝑁𝑁𝑁𝑁 − 𝐼𝐼𝐼𝐼|𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 − 𝐼𝐼𝐼𝐼|𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛e1|𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛2).

MSK is 512-‐bit key used by NCC and RCST to derive the Pairwise Master Key (PMK). PMK is a 256-‐bit auxiliary key that is used during the key derivation and distribution phase (Phase 3) to derive different traffic protection keys. Figure 4-‐2 shows the message exchanges between the NCC and the RCST during the EAP-‐SAT mutual authentication mechanism.

FIGURE 4-‐2: MESSAGE EXCHANGE – AUTHENTICATION – PHASE 2

4.1.3 Phase 3: Key Derivation and distribution

Following the authentication and PMK establishment, both NCC and RCST enter the key derivation and distribution phase. First, this phase ensures the successful completion of authentication phase and confirms the establishment of the PMK. Second, it derives fresh keys to protect the data traffic between NCC & RCST. Third, this phase synchronizes the installation of encryption keys into the NCC and RCST based on their unique ID (NCC-‐ID and RCST-‐ID). As discussed in section V, key management in WLAN 802.11i consists of 6 handshakes for derivation and distribution of the pair-‐wise and group-‐wise encryption keys.

48

Considering the large delay of satellite networks, an efficient mechanism is proposed, which relies on 4-‐message exchange only to agree and distribute the encryption keys used to protect both unicast and multicast traffics. The first two messages between the NCC and RCST are used to agree on the Pairwise Transient Key (PTK), which is used to protect the unicast traffic. The last two messages are used to exchange the Group Transient Key (GTK), which is used to protect both multicast and broadcast traffics. This approach is very efficient for satellite networks, where only a single round-‐trip message exchange is needed to derive the encryption key in case multicast is not required.

The proposed message interactions between NCC and RCST for key derivation and distribution are similar to the four-‐way handshake of 802.11i; therefore, these messages retain the same security features of the 4-‐way handshake. However, all information related to WLAN features have been removed. For example fast authentication, SSID info, wireless domain, etc. [46].

Details of the proposed scheme for key derivation and distribution are shown in Figure 4-‐3:

FIGURE 4-‐3: KEY DERIVATION AND DISTRIBUTION DURING PHASE 3

The messages exchanged in phase 3 are:

First Key Derivation Message (HandshakeMsg1): {𝑁𝑁𝑁𝑁𝑁𝑁 − 𝐼𝐼𝐼𝐼,𝑁𝑁𝑁𝑁 − 𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛,𝑅𝑅𝑅𝑅} is sent from the NCC to the RCST, where NC-‐nonce is a random value generated by the NCC. RC is a reply



49

protection counter with an initial value set to 1. The NCC increases the RC counter by one every time it sends this message. NCC-‐ID is the NCC identity that can be a temporary ID agreed between NCC and RCST after every successful authentication.

Upon receiving the first message, the RCST verifies the received RC value. If the received RC value is less than or equal to the local value stored from previous communication, RCST will discard the message. Otherwise, if correct, the RCST generates its own random value, ST-‐nonce and computes the Pairwise Transient Key (PTK) 𝑃𝑃𝑃𝑃𝑃𝑃 = 𝑃𝑃𝑃𝑃𝑃𝑃 − 384 (𝑃𝑃𝑃𝑃𝑃𝑃, (𝑁𝑁𝑁𝑁𝑁𝑁 −𝐼𝐼𝐼𝐼,𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 − 𝐼𝐼𝐼𝐼)||(𝑁𝑁𝑁𝑁𝑁𝑁 − 𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛, 𝑆𝑆𝑆𝑆 − 𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛)). The derivation of the PTK is the same of 802.11i. However, here it is assumed that the Authentication Server (AS) coexists within the NCC. Therefore, the message interactions are done between the NCC and RCST only.

Then, the PTK is partitioned into three different keys used for unicast traffic protection:

a) Key Confirmation Key (KCK), the first 128-‐bit of the PTK and used to verify the integrity and data authenticity for the messages exchanged during the key distribution phase (Phase 3);

b) Key Encryption Key (KEK), derived of bits from 128-‐255 of the PTK, used to encrypt the messages exchanged during the key distribution phase;

c) Temporary Encryption Key (TEK), consists of bits from 256-‐384 of the PTK, used as a session key for unicast data stream protection between the NCC and RCST.

Second Key Derivation Message (HandshakeMsg2): {𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 − 𝐼𝐼𝐼𝐼, 𝑆𝑆𝑆𝑆 − 𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁,𝑅𝑅𝑅𝑅,𝑀𝑀𝑀𝑀𝑀𝑀1 =(𝐾𝐾𝐾𝐾𝐾𝐾,𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻ℎ𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎2)}. This message is constructed by the RCST and sent to the NCC. It consists of ST-‐nonce, RCST-‐ID, RC, and the Message Integrity Code (MIC1). MIC1 is computed over this message by the RCST using the derived KCK and RC is the updated value of RCST’s reply counter.

Upon receiving message 2, the NCC first verifies the correctness of the RC value. If the reply counter value is not correct, the NCC will discard the message. Otherwise, the NCC uses the NC-‐nonce and ST-‐nonce values to compute PTK and derive KCK, KEK, and TEK, using the same method as the RCST. At the same time, the NCC uses KCK to verify the correctness of the MIC1 value to ensure the integrity of the received message.

Finally, once the NCC and the RCST computed the PTK and derived the Temporary Encryption Key (TEK), the TEK can be used as a session key to protect the unicast data streaming using the agreed unicast cipher suite (See Phase 4). However, in order to support secure multicasting over satellite network, Group Temporary Key (GTK) is generated by the NCC and transmitted to group of RCSTs within the same multicast group. GTK is used to protect the multicast traffic from NCC to RCSTs in the multicast group. Messages 3 and 4 are used to transmit and confirm the GTK.

Third Key Derivation Message (HandshakeMsg3): The NCC sends the third message to the RCST, {𝐺𝐺 − 𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛,𝑅𝑅𝑅𝑅,𝐸𝐸𝐸𝐸𝐸𝐸!"!(𝐺𝐺𝐺𝐺𝐺𝐺,𝐺𝐺𝐺𝐺𝐺𝐺 − 𝐼𝐼𝐼𝐼),𝑀𝑀𝑀𝑀𝑀𝑀2 = (𝐾𝐾𝐾𝐾𝐾𝐾,𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻ℎ𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎3)}, where G-‐nonce is a random value generated by the NCC for this specific multicast group. GTK is

50

generated from Group Master Key (GMK) using a hash function, GTK = PRF-‐128 (GMK, NCC-‐ID||G-‐Nonce). At the same time, NCC encrypts the computed GTK and GTK_ID using KEK. Additionally, NCC uses KCK to compute the MIC over the whole message body.

Upon receiving the third message, distributing the group key, the RCST will first check the reply counter. If it doesn’t match the expected value, the message is discarded. Otherwise, KCK is used to validate the MIC2 value to ensure that there is no data integrity error. If the computed MIC doesn’t match the received MIC, it discards the message. Otherwise, if correct, KEK will be used to decrypt GTK and GTK-‐ID.

Fourth Key Derivation Message (HandshakeMsg4): the RCST sends the fourth message to the NCC, {𝐺𝐺 − 𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛,𝑅𝑅𝑅𝑅,𝑀𝑀𝑀𝑀𝑀𝑀3 = (𝐾𝐾𝐾𝐾𝐾𝐾,𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻ℎ𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎4)}, in order to confirm the reception of the GTK. MIC3 is computed over the received G-‐nonce and the updated RC value. Upon receiving the fourth message, the NCC verifies the RC value. If it is correct, it verifies the correctness of MIC3. Afterwards, the NCC can start protecting the multicast traffic using the GTK and the agreed multicast cipher suite (See phase 4).

4.1.4 Phase 4: Data Encapsulation and Protection

After the generation, distribution, and confirmation of the encryption keys, both the NCC and the RCST are ready to communicate securely. During the data protection phase, the traffic transferred between the NCC and the RCST (Unicast, Multicast, and Broadcast) is protected for data confidentiality and integrity using the encryption and integrity cryptographic algorithms agreed during the security agreement phase (Phase1).

In the proposed RSSN framework, CCMP protocol is used for traffic protection between the NCC and RCST. Generally, CCMP is designed for traffic protection over the WLAN. It encrypts the data at the Media access control Protocol Data Unit (MPDU) level. In WLAN, the MPDU corresponds to the frames that actually get transmitted over the radio link. However, satellite networks have a different structure for the MAC layer, where data has to be encapsulated before being sent over the MPEG-‐TS stream. Therefore, a new mode of operation is proposed for the CCMP protocol in order to protect the encapsulated SNDU.

This phase describes the operation of CCMP protocol with the lightweight encapsulation mechanisms (ULE), used for packing IP datagrams (or other network protocols) over MPEG-‐TS packets. However, similar mode of operation can be used with Generic Stream Encapsulation (GSE) but the description for this operation is omitted due to space constrains.

The data arrives to the encapsulation layer in a form of Payload Data Units (PDUs) such as IP datagrams, Ethernet frames, and any other network layer protocol. The PDUs pass through the encapsulator, which formats each PDU into a Sub-‐Network Data Unit (SNDU), assigns encapsulation headers and any other extension headers that may be required depending on the encapsulation protocol used. At this point, CCMP protocol processes each SNDU to generate a new protected SNDU.

To protect ULE traffic using CCMP protocol, a new security extension header (ULE-‐CCMP) is proposed with the following goals:



51

• To provide a reply protection using a 48-‐bit packet number (PN), • To enable the receiver to derive the nonce value used in the encryption, • To inform the receiver, in case of multicast, which GTK key is used using GTK-‐ID.

Figure 4-‐4 shows ULE SNDU with CCMP extension header (H1).

FIGURE 4-‐4: ULE SNDU WITH THE CCMP EXTENSION HEADER

(BASE HEADER -‐ LIGHT GRAY, EXTENSION HEADER – DARK GREY)

Where:

D is 1-‐bit identifying the presence or absence of NPA address (D=0; NPA is present, D=1; NPA is absent);

Length is a 15-‐bit field that indicates the length in bytes, of the SNDU counted from the byte following the Type field of the base header (T1) up to and the end of CRC; Length includes the size of any extension headers;

T1 is the 16-‐bit base header Type field; in this case, T1 specifying the type identified for the extension header (ULE-‐CCMP header);

NPA is the destination Network Point of Attachment; it is optional field in ULE header.

H1 is the 56-‐bit extension header consisting of ULE-‐CCMP header fields (PN and GTK_ID)

• PN: is the 48-‐bit packet number incremented with each SNDU; PN shall not be repeated for encrypted SNDUs using the same encryption key;

• GTK_ID: 8-‐bit field contains the identifier of GTK encryption key used to protect the multicast traffic;

T2 is the 16-‐bit Type field of the security extension header, identifying the type of the carried PDU, i.e. secured IPv4 datagram, security message exchange;

CRC is the 4-‐byte CRC-‐32 ULE checksum.

The steps for protecting SNDU using ULE-‐CCMP are shown in Figure 4-‐5 and described below.

52

FIGURE 4-‐5: ULE-‐CCMP ENCRYPTION

The unencrypted PDUs (IP packets, or other network protocol packets) are encapsulated using ULE to form Sub-‐network Data Units (SNDUs). Each SNDU carries two headers: ULE base header, and ULE security extension header (ULE-‐CCMP header). To proceed with SNDU protection four steps are identified:

a) the PN is incremented to obtain a fresh PN for each SNDU; then, the fresh generated PN, and GTK_ID are used to construct the ULE-‐CCMP header;

b) Information of ULE base header (including the NPA, if present) is used for computing the Message Integrity Code (MIC); MIC is 64-‐bit computed using CBC-‐MAC to protect the PDU, ULE-‐CCMP header, and ULE base header; MIC is appended to the PDU and the resulting field is encrypted; AES counter mode encryption is used with TEK for unicast traffic or GTK for multicast traffic to encrypt T2 field, the PDU, and MIC; on the other hand, ULE base header and ULE-‐CCMP header are protected by MIC but are not encrypted, since both headers are carrying information required by the receiver in order to de-‐capsulate and decrypt the SNDU; generally, it is important for the counter mode encryption to avoid using the same counter value more than once; therefore, the counter that will be used by the counter mode is constructed using PN, source MAC address, Length field, and 16-‐bit incremental counter, which increments with every block in the counter mode. Figure 4-‐6 shows the nonce structure;



53

FIGURE 4-‐6: ULE-‐CCMP COUNTER STRUCTURE

c) After the encryption, the SNDU is ready for transmission over MPEG-‐2 transport stream cells and the protected SNDUs are segmented into a series of MPEG-‐2 TS sections; these are transmitted over the logical channel using a fixed size MPEG-‐2 TS cells (184-‐bytes payload, 4-‐bytes header).

On the other hand, when the protected SNDUs are delivered to the receiver, first it validates the correctness of the attached CRC, in order to ensure that there are no transmission errors. If any, the receiver will discard the message. Otherwise, the receiver reads the PN in the ULE-‐CCMP header and compares it with the last packet received to ensure that the packet is not replayed. If PN matches the expected packet counter, the receiver uses the TEK/GTK to decrypt the cipher text using AES CTR mode, therefore it restores the unencrypted PDU and MIC value. Afterwards, the receiver verifies if the MIC value is correct by recalculating it over the same data as previously done by the sender. The receiver should obtain the same value of the received MIC using the same encryption key if the data is not altered. Undoubtedly, MICs mismatch is an evidence of attack. Thus, the receiver has to discard the entire SNDU.

If the MIC matches, the receiver removes the MIC and the ULE-‐CCMP header, then de-‐capsulate the ULE SNDU by removing both base and extension headers, then passes the unencrypted PDU to the upper layers. ULE-‐CCMP encryption and decryption process are identical, which makes it simple, easy to implement, and speed up data processing. In addition, it provides strong protection against forgery, eavesdropping, and reply attacks.

4.1.5 Phase 5: Rekeying,

RSSN security framework provides on the fly re-‐keying to update the encryption keys PTK and GTK. Rekeying is always initiated by the NCC, however, RCST can request rekeying when needed. For example, rekeying is mandatory once the packet number (PN), which is used in CCMP-‐ULE encryption, has reached the maximum value (248) and could possibly warp.

Re-‐keying requires the use of the shared Pairwise Master Key (PMK) to drive a fresh PTK. Similarly, it requires the NCC to use the Group Master Key (GMK) to derive a new GTK for multicast traffic protection.

Similar to key distribution and derivation phase, for PTK re-‐keying, the NCC initiates the re-‐keying process by sending the first re-‐keying message to the RCST including a fresh generated NC-‐nonce value. Once the RCST receives the message, it generates a new random value ST-‐nonce and uses both nonces to compute a fresh PTK. Additionally, it will partition the PTK to derive the set of operational keys (KEK, KCK, and TEK). Finally, the RCST constructs the re-‐

54

keying confirmation message including ST-‐nonce value and MIC computed over the full message body, using KCK.

For GTK rekeying, NCC generates a new G-‐nonce value and uses it to compute a fresh GTK. Afterwards, it uses the last valid KEK to encrypt the new generated GTK.

This re-‐keying mechanism allows the establishment of new keys to take place without interrupting the data traffic. The NCC starts using the new generated key to encrypt the unicast traffic after receiving the RCST reply to the re-‐keying message. Similarly, for multicast traffic, the NCC uses the new GTK immediately after receiving the confirmation message from the RCST. At the same time, the RCST uses the same key the NCC used in the last encrypted message for both unicast and multicast traffics.

4.1.6 Phase 6: Security Teardown, log-‐off

At the end of the communication session, the logoff request can be initiated either by RSCT or NCC. However, terminal logoff can be necessary if the terminal lost the synchronization or errors occurred during the security establishment. When a peer receives the logoff request, it initiates deauthentication service, which will terminate the secure communication, and destroy all keys generated as a result of the successful authentication (MSK, PMK, PTK, and GTK).

4.2 RSSN Framework Analysis and Evaluation

RSSN is designed to provide robust security services to satellite networks, considering the specific environment and leveraging on existing and enhanced security procedures.

This section presents a detailed analysis of the proposed RSSN in terms of compatibility of the solution, the security correctness, and a performance evaluation.

4.2.1 Compatibility Evaluation

In developing the RSSN security framework, a series of established cryptographic constructions (protocols, modes of operation, and algorithms) are used, while adapted them to the characteristics of satellite communications. this subsection highlights the elements that give RSSN a very high level of compliance with the characteristics of satellite communications.

For access control and authentication, the NCC and the RCST exchange only three messages within the lightweight EAP-‐SAT authentication method to prove their identity.

The limited number of messages and the request of mutual authentication only once allow to strongly reducing the impact of satellite link characteristics on performance, making it acceptable.



55

For data protection CCMP protocol is used to protect unicast and multicast data travelling over the wireless link. CCMP uses a single key to provide data protection services that include, data confidentiality, data origin authenticity, data integrity, and reply protection. CCMP encryption occurs within the IP encapsulation layer. Thus, it is transparent to the upper layer, allowing the use of different network layer techniques required for satellite networks i.e. Network Address Translation (NAT), PEPs, and IP compression. Additionally, CCMP expands the encapsulated SNDU by 17-‐bytes only, which makes it a lightweight data protection algorithm suitable for satellite networks.

Finally, RSSN depends on EAP authentication and simple key management mechanism. Thus, it provides a high level of flexibility for the satellite operators that improve the manageability and scalability of satellite networks.

4.2.2 Security Analysis

RSSN framework first employs EAP-‐SAT method for the mutual authentication. Then, it relies on combined handshake for pairwise and group key distribution before proceeding for data protection. To analyse the security of the proposed RSSN framework, it is required to prove the correctness of security properties for both. Since data protection phase is built on idealized cryptographic protocol, the analysis of this phase is not presented within this security analysis.

4.2.2.1 EAP-‐SAT Security Analysis

The security of the authentication method is of paramount importance for the entire framework security. Hence, first it is important to verify the compliance of EAP-‐SAT method to the mandatory security requirements identified in EAP framework specification, which are required to be met by any EAP authentication method. Secondly, to carry out a modular proof of the security correctness for EAP-‐SAT using Protocol composition Logic (PCL) [16]. PCL is a provably reliable formal method for proving the security properties of authentication and key agreement protocols.

4.2.2.1.1 Security Compliance

As required by EAP specification, any proposed EAP compliant authentication method must declare the following security requirements:

• Mutual authentication -‐ both NCC and RCST are able to prove their identities based on a pre-‐shared password and agreed IDs;

• Forward secrecy -‐ MSK security is independent on the password security; should the password be compromised no impact on past communications;

56

• Replay protection -‐ if an attacker replays messages from previous authentications, he cannot reveal the password or any of the derived keys, nor he can masquerade any of the legitimate parties;

• Key derivation -‐ MSK is derived from a shared secret that has been established during the authentication phase and that has been derived using secret data from both the NCC and the RCST;

• Dictionary attack resistance -‐ an attacker cannot capture the authentication messages and then use dictionary attack against the password;

• Man in the middle attack -‐ this method is resistant to man in the middle attack by ensuring both integrity and confidentiality of every message;

• Shared state equivalence -‐ NCC and RCST authenticate each other based on equivalent parameters; NCC-‐ID, RSCT-‐ID, Password, and the shared secret; all these parameters are combined to ensure the successful authentication that generates the master shared key.

4.2.2.1.2 Modular Security Correctness Proof

A formal security correctness proof of the complete 802.11i security protocol has been presented in [43]. The proof is modular, comprising a separate proof for each stage of 802.11i security protocol and providing insight into the networking environment in which each protocol section can be reliably executed. However, this proof is formalizing the security of TLS as an authentication mechanism for 802.11i.

A formal modelling of EAP-‐SAT authentication method is presented as set of statements, each specifying a sequence of actions to be executed by the honest parties (NCC and RCST). Then, this formal modelling is used to produce an input for the subsequent security proof operations as in [18].

The following is the formal modelling of EAP-‐SAT authentication method presented in “protocol programming language” based on cords [42]. The match action is used to perform and verify keyed hashes and to perform decryption processes.

𝑁𝑁𝑁𝑁𝑁𝑁 = (𝑌𝑌,𝑋𝑋 ̂,𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃) [

𝑛𝑛𝑛𝑛𝑛𝑛 𝑚𝑚, 𝑦𝑦,𝑔𝑔, 𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛1;

𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚ℎ 𝑔𝑔ˆ𝑦𝑦 𝑚𝑚𝑚𝑚𝑚𝑚 𝑝𝑝 /𝑇𝑇;

𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚ℎ 𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻!"##$%&'(𝑁𝑁𝑁𝑁𝑁𝑁 − 𝐼𝐼𝐼𝐼,𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 − 𝐼𝐼𝐼𝐼)/ 𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇;

𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚ℎ 𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻!"#$(𝑁𝑁𝑁𝑁𝑁𝑁 − 𝐼𝐼𝐼𝐼,𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 − 𝐼𝐼𝐼𝐼) /𝐾𝐾𝐾𝐾|𝐾𝐾𝐾𝐾;

𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠 𝑌𝑌 ,𝑋𝑋,𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻!"(𝐸𝐸𝐸𝐸𝐸𝐸!"(𝑔𝑔, 𝑦𝑦,𝑇𝑇, 𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛1));

𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟 𝑋𝑋 ,𝑌𝑌 , 𝑧𝑧;

𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚ℎ 𝑧𝑧/ ℎ𝑎𝑎𝑎𝑎ℎ1,𝐸𝐸𝑁𝑁𝑁𝑁!"(𝐴𝐴𝐴𝐴𝐴𝐴ℎ − 𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅);

𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚ℎ ℎ𝑎𝑎𝑎𝑎ℎ1/ 𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻!"(𝐸𝐸𝐸𝐸𝐸𝐸!"(𝑅𝑅, 𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛1, 𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛2));

𝑚𝑚𝑚𝑚𝑚𝑚cℎ 𝐸𝐸𝐸𝐸𝐸𝐸!"(𝑅𝑅, 𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛1, 𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛2)/ (𝑅𝑅, 𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛1, 𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛2);



57

𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚ℎ 𝐸𝐸𝐸𝐸𝐸𝐸!"(𝐴𝐴𝐴𝐴𝐴𝐴ℎ − 𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅)/𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻!"(𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆, 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆,𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸1);

𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚ℎ 𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻!"(𝑆𝑆𝑆𝑆𝑆𝑆_𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅, 𝑆𝑆𝑆𝑆𝑆𝑆_𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑀𝑀𝑀𝑀𝑀𝑀,

𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸1,𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸2)/𝐴𝐴𝐴𝐴𝐴𝐴ℎ − 𝑁𝑁𝑁𝑁𝑁𝑁;

𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠 𝑌𝑌 ,𝑋𝑋 ,𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻!"(𝐸𝐸𝐸𝐸𝐸𝐸!"(𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛1)),𝐸𝐸𝐸𝐸𝐸𝐸!"(𝐴𝐴𝐴𝐴𝐴𝐴ℎ − 𝑁𝑁𝑁𝑁𝑁𝑁).

𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 = (𝑋𝑋,𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃)[

𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟 𝑌𝑌 ,𝑋𝑋 ,𝑚𝑚;

𝑛𝑛𝑛𝑛𝑛𝑛 𝑥𝑥, 𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛2;

𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚ℎ 𝑔𝑔ˆ𝑥𝑥 𝑚𝑚𝑚𝑚𝑚𝑚 𝑝𝑝 /𝑅𝑅;

𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚ℎ 𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻!"##$%&'(𝑁𝑁𝑁𝑁𝑁𝑁 − 𝐼𝐼𝐼𝐼,𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 − 𝐼𝐼𝐼𝐼)/ 𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇;

𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚ℎ 𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻!"#$(𝑁𝑁𝑁𝑁𝑁𝑁 − 𝐼𝐼𝐼𝐼,𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 − 𝐼𝐼𝐼𝐼) /𝐾𝐾𝐾𝐾|𝐾𝐾𝐾𝐾;

𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚ℎ 𝑚𝑚/ 𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻!"(𝐸𝐸𝐸𝐸𝐸𝐸!"(𝑔𝑔, 𝑦𝑦,𝑇𝑇, 𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛1));

𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚ℎ; 𝐸𝐸𝐸𝐸𝐸𝐸!"(𝑔𝑔, 𝑦𝑦,𝑇𝑇, 𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛1)/ (𝑔𝑔, 𝑦𝑦,𝑇𝑇, 𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛1);

𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚ℎ 𝑔𝑔^𝑥𝑥𝑥𝑥 𝑚𝑚𝑚𝑚𝑚𝑚 𝑝𝑝 /𝑆𝑆;

𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚ℎ 𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻!(𝑁𝑁𝑁𝑁𝑁𝑁 − 𝐼𝐼𝐼𝐼,𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 − 𝐼𝐼𝐼𝐼, 𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛1, 𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛2)/ 𝐾𝐾𝐾𝐾;

𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚ℎ 𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻!"(𝑆𝑆𝑆𝑆𝑆𝑆_𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅, 𝑆𝑆𝑆𝑆𝑆𝑆_𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅,

𝐸𝐸𝐸𝐸𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃1)/ 𝐴𝐴𝐴𝐴𝐴𝐴ℎ − 𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅;

𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠 𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻!" 𝐸𝐸𝐸𝐸𝐸𝐸!" 𝑅𝑅, 𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛1, 𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛2 , 𝐸𝐸𝐸𝐸𝐸𝐸!"(𝐴𝐴𝐴𝐴𝐴𝐴ℎ − 𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅);

𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟 𝑌𝑌 ,𝑋𝑋 ,𝑤𝑤;

𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚ℎ 𝑤𝑤/ ℎ𝑎𝑎𝑎𝑎ℎ2,𝐸𝐸𝐸𝐸𝐸𝐸!"(𝐴𝐴𝐴𝐴𝐴𝐴ℎ − 𝑁𝑁𝑁𝑁𝑁𝑁);

𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚ℎ ℎ𝑎𝑎𝑎𝑎ℎ2/𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻!"(𝐸𝐸𝐸𝐸𝐸𝐸!"(𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛1));𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚ℎ 𝐸𝐸𝐸𝐸𝐸𝐸!"(𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛1)/ 𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛1;

𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚ℎ 𝐸𝐸𝐸𝐸𝐸𝐸!"(𝐴𝐴𝐴𝐴𝐴𝐴ℎ − 𝑁𝑁𝑁𝑁𝑁𝑁)/𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻!"(𝑆𝑆𝑆𝑆𝑆𝑆_𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅, 𝑆𝑆𝑆𝑆𝑆𝑆_𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅, 𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸1,𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸2).

Following this formal presentation of the EAP-‐SAT authentication method, the definitions of Protocol Composition Logic (PCL) are used to prove the security correctness of this authentication method. Generally, PCL depends on the formula 𝜃𝜃 [𝑃𝑃] 𝑋𝑋 ∅ to prove the security correctness of the communication protocol, which means that starting from state where θ is true, after executing series of actions P by the process X, the final resulting state θ holds. PCL formulas typically ensure the possession of the data by the principles that execute the protocol rules (useful to state the data secrecy), and/or the order of rules executed during the protocol runs (useful to state the protocol session authenticity) [16].

The proof system of PCL combines different axioms and proof rules together with the protocol actions, first-‐order logic, knowledge model, temporal reasoning, and an important invariance rule for proving properties about the actions of principals that execute the rule of

58

the protocol, called the “honesty rule”. Honesty is an essential rule for the principles that executes that protocol because the intruder may perform unpredictable actions with any key that has been compromised.

To ensure the security properties of EAP-‐SAT authentication method, both the NCC (Y) and the RCST (X) are expected to be honest and are the only parties, which recognize and share the corresponding “Password”. However, other principals in the network are expected to be potentially malicious and capable of reading, blocking and modifying messages transmitted over the network.

To characterize PCL states, these definitions below formalize the two security properties, “Key Secrecy” and “Session Authenticity” [43].

Definition1: The authentication theorem requires that on completion of the protocol, the NCC and RCST accede on each other’s identity, protocol completion status, the cryptographic suite selection, each other’s nonces, and the MSK that is generated after the successful authentication. This authenticity property is determined in terms of matching conversations [43]. The basic idea of matching conversations is to guarantee that both NCC and RCST have consistent views of protocol runs. This definition is called “Session Authenticity”. The authentication mechanism is said to provide “Session Authenticity” if ϕ!"#!!"#,!"#$ holds, where:

𝜙𝜙!"#!!"#,!"#! ∷= 𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻 (𝑋𝑋 ) ⋀ 𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻 (𝑌𝑌) ⊃ ∃𝑌𝑌.𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴(

𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 (𝑌𝑌,𝑌𝑌 ,𝑋𝑋 ,𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸1),

𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 (𝑋𝑋,𝑌𝑌 ,𝑋𝑋 ,𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸1),

𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 (𝑋𝑋,𝑋𝑋 ,𝑌𝑌 ,𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸2),

𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 (𝑌𝑌,𝑋𝑋 ,𝑌𝑌 ,𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸2),

𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 (𝑌𝑌,𝑌𝑌 ,𝑋𝑋 ,𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸3),

𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 (𝑋𝑋, (𝑌𝑌 ) ̂, (𝑋𝑋 ) ̂,𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸3),

Definition2: The established secret by the successful authentication (MSK) must be known only to the honest NCC and the honest RCST. This definition is called “Key Secrecy”. The authentication mechanism is said to provide “Key Secrecy” if 𝜙𝜙!"#!!"#,!"# holds, where:

𝜙𝜙!"#!!"#,!"#! ∷= 𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻 (𝑋𝑋 ) ⋀ 𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻 (𝑌𝑌) ⊃

𝐻𝐻𝐻𝐻𝐻𝐻 (𝑋𝑋 ,𝑀𝑀𝑀𝑀𝑀𝑀) ⋀ 𝐻𝐻𝐻𝐻𝐻𝐻 (𝑌𝑌 ,𝑀𝑀𝑀𝑀𝑀𝑀) ⋀ (𝐻𝐻𝐻𝐻𝐻𝐻 (𝑍𝑍 ,𝑀𝑀𝑀𝑀𝑀𝑀) ⊃ 𝑍𝑍 = 𝑋𝑋 ⋁ 𝑍𝑍 = 𝑌𝑌)

In fact, the “Session Authenticity” can be guaranteed only when the “Key Secrecy” is guaranteed. Moreover, by satisfying these two definitions, it can state that the security guarantees for both NCC and RCST equivalently.

Security of the exchanged key material during the authentication is based on actions performed by the honest principles, NCC and RCST. First, the generated secret materials such as nonce, keys, or Auth are sent out either encrypted with encryption key known only for the honest principles or used as an input for keyed hashes. Second, the honest principles are



59

prohibited to decrypt any protected material and send out the output in clear. To characterize these two facts formally, PCL assures that on the execution of the authentication rules, both the key secrecy and session authenticity are guaranteed if the formulas below hold. Formally:

𝛤𝛤!"#!!"#,! ⋀ 𝛤𝛤!"!!!"#,! ⊢ [𝐴𝐴𝐴𝐴𝐴𝐴ℎ𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒 𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃] 𝑋𝑋 ∅!"#!!"#,!"# ⋀ ∅!"#!!"#,!"#!

Where:

𝜞𝜞𝑬𝑬𝑬𝑬𝑬𝑬!𝑺𝑺𝑺𝑺𝑺𝑺,𝟏𝟏 ∷=¬∃𝑚𝑚. 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆(𝑌𝑌,𝑚𝑚) ∧ (𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶(𝑚𝑚,𝐻𝐻𝐻𝐻𝐻𝐻ℎ!"#$"%(𝐸𝐸𝐸𝐸𝐸𝐸 −𝑀𝑀𝑀𝑀𝑀𝑀1,𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑟𝑟i𝑎𝑎𝑎𝑎))) ∨(𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶 𝑚𝑚,𝐻𝐻𝐻𝐻𝐻𝐻ℎ!"#$"% 𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸3,𝑁𝑁𝑁𝑁𝑁𝑁 − 𝐴𝐴𝐴𝐴𝐴𝐴ℎ ⋀

¬∃𝑚𝑚. 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆(𝑋𝑋,𝑚𝑚) ∧ (𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶(𝑚𝑚,𝐻𝐻𝐻𝐻𝐻𝐻ℎ!"#$"%(𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸2,𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅))

𝜞𝜞𝑬𝑬𝑬𝑬𝑬𝑬!𝑺𝑺𝑺𝑺𝑺𝑺,𝟐𝟐 ∷=

𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻 (𝑌𝑌)⋀𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 (𝑌𝑌,𝑚𝑚) ∧ 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶(𝑚𝑚,𝐸𝐸𝐸𝐸𝐸𝐸!"(𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆)) ⊃ (¬𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷(𝑌𝑌,𝑚𝑚) ∧𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶(𝑚𝑚 , 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆)) ∨ (𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅(𝑌𝑌,𝑚𝑚) < 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 𝑌𝑌, 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 ⋀

𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶(𝑚𝑚,𝐸𝐸𝐸𝐸𝐸𝐸!"(𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆)))

First, 𝛤𝛤!"#!!"#,! states that the authentication messages that contain a secret material (Diffie-‐Hillmans values, nonce, and Auth) must not be sent out in clear during the protocol run. Instead, the authentication messages can be only sent out encrypted with a shared secret established between the honest principles. Second, 𝛤𝛤!"#!!"#,! states that the security of the authentication protocol is lost if the honest NCC or honest RCST is tricked into decrypting the message containing the secret materials and sends the output out the contests in clear.

The formal modelling for the authentication method (EAP-‐SAT) presented above shows that the proposed EAP-‐SAT authentication method does not violate these two assumptions. Therefore, the proposed scheme guarantees the security property of the authentication method.

4.2.2.2 Key Derivation and Distribution Security Analysis

The message interactions for key derivation in RSSN are similar to the 802.11i 4-‐way handshake protocol. The only difference is that in 802.11i 4-‐way handshake protocol is used to agree on the PTK between the access point and computer station. In addition, a group key handshake is used to deliver the GTK. However, in RSSN the NCC and the RCST derive the PTK and GTK through combined handshake with 4 messages only. Therefore, if the security of the 4-‐way handshake and group key handshake is guaranteed, the key derivation handshake of RSSN is secure.

The security of the 4-‐way handshake and group-‐key handshake protocols are formally proved in [43]. Similarly to this formal proof of 4-‐way handshake and group key handshake, the security of RSSN key derivation and distribution handshakes is guaranteed only if these formulas hold.

60

For NCC (Y) and RCST (X)

∅!""#,!"# ∷= 𝐻𝐻𝐻𝐻𝐻𝐻(𝑌𝑌,𝑃𝑃𝑃𝑃𝑃𝑃) ∧ 𝐻𝐻𝐻𝐻𝐻𝐻(𝑋𝑋,𝑃𝑃𝑃𝑃𝑃𝑃) ∧ 𝐻𝐻𝐻𝐻𝐻𝐻 𝑍𝑍,𝑃𝑃𝑃𝑃𝑃𝑃 ⊃ 𝑍𝑍 = 𝑋𝑋 ∨ 𝑍𝑍 = 𝑌𝑌 ∧𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁(𝑌𝑌,𝑃𝑃𝑃𝑃𝑃𝑃,𝐸𝐸𝐸𝐸𝐸𝐸!(𝑃𝑃𝑃𝑃𝑃𝑃)) ∧ 𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁(𝑋𝑋,𝑃𝑃𝑃𝑃𝑃𝑃,𝐸𝐸𝐸𝐸𝐸𝐸!(𝑃𝑃𝑃𝑃𝑃𝑃)) ∧ (𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆(𝑋𝑋,𝑚𝑚) ∧𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶(𝑚𝑚, 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆) ⊃ 𝑖𝑖𝑖𝑖L𝑒𝑒𝑒𝑒𝑒𝑒(𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶, 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆)))

𝛤𝛤!"#,! ∷= 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶(𝑌𝑌,𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻!"#(𝑥𝑥, 𝑦𝑦)) ⊃ ¬(𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆(𝑌𝑌,𝑚𝑚) ∧ 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶(𝑚𝑚,𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻!"#(𝑥𝑥, 𝑦𝑦)) ∧𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶(𝑋𝑋,𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻!"#(𝑥𝑥, 𝑦𝑦)) ⊃ ¬(𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆(𝑋𝑋,𝑚𝑚) ∧ 𝐶𝐶𝐶𝐶𝐶𝐶𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡(𝑚𝑚,𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻!"#(𝑥𝑥, 𝑦𝑦))

𝛤𝛤!"#,! ∷= (𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻 𝑌𝑌 ∧ 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 𝑌𝑌,𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻ℎ𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎1 ⊃ ¬𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 𝑌𝑌,𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻ℎ𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎2 ) ∧(𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻(𝑋𝑋) ∧ 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆(𝑋𝑋,𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻ℎ𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎2) ⊃ ¬𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆(𝑋𝑋,𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻ℎ𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎1))

𝛤𝛤!"#,! ∷= 𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻(𝑌𝑌) ∧ (𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆(𝑌𝑌,𝑌𝑌,𝑋𝑋,𝑚𝑚’)) < 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆(𝑌𝑌,𝑌𝑌,𝑋𝑋,𝑚𝑚”))⋀𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶(𝑚𝑚’, 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆1) ∧𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶(𝑚𝑚”, 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆2) ⊃ 𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖(𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆1, 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆2)

𝛤𝛤!"#,! ∷= 𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻(𝑌𝑌)⋀𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆(𝑌𝑌,𝑚𝑚)⋀𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶(𝑚𝑚,𝐸𝐸𝐸𝐸𝐸𝐸!"#(𝐺𝐺𝐺𝐺𝐺𝐺)) ⊃(¬𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷(𝑌𝑌,𝑚𝑚)⋀𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶(𝑚𝑚,𝐺𝐺𝐺𝐺𝐺𝐺)) ∨ (𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅(𝑌𝑌,𝑚𝑚) <𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆(𝑌𝑌,𝐺𝐺𝐺𝐺𝐺𝐺)⋀𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶(𝑚𝑚,𝐸𝐸𝐸𝐸𝐸𝐸!"#(𝐺𝐺𝐺𝐺𝐺𝐺)))

𝛤𝛤(!"#,!) ∷= (𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻(𝑌𝑌 )⋀𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆(𝑌𝑌,𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻ℎ𝑎𝑎𝑎𝑎𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒3) ⊃

¬𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆(𝑌𝑌 ,𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻ℎ𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎4))⋀ (𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻(𝑋𝑋)⋀

𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆(𝑌𝑌,𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻ℎ𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎4) ⊃ ¬𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆(𝑋𝑋,𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻ℎ𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎3))

The precondition 𝛩𝛩!""#,!"# requires that only the honest entities know the PMK. Additionally, PMK will only be sent encrypted. Furthermore, the NCC monotonically increases the sequence number for every key exchange message sent to prevent reply attacks.

Starting from a state in which the precondition (∅!""#,!"#) holds, executing the key exchange rules will guarantee the desired authentication and secrecy properties if these formulas (𝛤𝛤!"#,!,𝛤𝛤!"#,!,𝛤𝛤!"#,!,𝛤𝛤!"#,!, 𝑎𝑎𝑎𝑎𝑎𝑎 𝛤𝛤!"#,!) hold. In fact, assuming these formulas hold, the security property is guaranteed.

𝛤𝛤!"#,!⋀𝛤𝛤!"#,!⋀𝛤𝛤!"#,!⋀𝛤𝛤!"#,! ∧ 𝛤𝛤!"#,! ⊢ ∅!""#,!"#[𝑘𝑘𝑘𝑘𝑘𝑘 𝑒𝑒𝑒𝑒𝑒𝑒ℎ𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎 𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟]𝑋𝑋∅!""#,!"#,!"# ∧∅!""#,!"#,!"#!

Formula 𝛤𝛤!"#,! listed above implies that the NCC and RCST will derive the PTK locally and must not reveal it. 𝛤𝛤!"#,! states that no entity is allowed to perform the role of both the NCC and the RCST. This is a valid assumption in the satellite network. 𝛤𝛤!"#,! states that the sequence number should be monotonically increased and included in both GTK exchange messages (message 3 and 4) to guarantee the key ordering for the RCST. 𝛤𝛤!"#,! states that, the NCC and the RCST must not share or send the GTK. This can be an issue if the GTK is encrypted with the same key used to encrypt the data traffic, because if the TEK of one terminal would be compromised, for any reason, it would affect the security of all the other terminals as well. However, the proposed key derivation mechanism uses KEK to encrypt the GTK and TEK for data traffic encryption. Finally, 𝛤𝛤!"#,! states that, during the GTK distribution no entity is allowed to play the role of both the NCC and the RCST.



61

In conclusion, if the NCC and the RCST derive the encryption key (PTK) locally and do not reveal the MSK, PMK, PTK, or GTK, the proposed RSSN key derivation provides secure key management scheme between the NCC and RCST.

4.2.3 Performance Evaluation

To evaluate the performance of the proposed security mechanism, the cost of security is studied in terms of Data Overhead (DO) then it is compared to other commonly used security mechanisms. Theoretically, DO is the expression of the added quantity of data that need to be sent using the satellite link to provide security services. It is expressed as the ratio between the added information and the total information sent.

DO = AI /TI * 100

Where AI is the added information and TI is the total information.

In the proposed RSSN framework, the DO has three components:

a) the authentication and key agreement components; b) the rekeying components; c) the data protection components.

The authentication and key management components are exchanged only once before initializing the secure communication. Also rekeying components are required every 248 protected SNDUs. Therefore, these components are negligible and only the data protection component will be considered in the analysis of DO.

The data protection represents the quantity of added information by the CCMP-‐ULE header and the MIC and is not influenced by the security parameters that are used. Thus, it is only a function of the encapsulated packet length, because a fixed number of bytes, 9 for CCMP-‐ULE header and 8 for MIC, are added to each SNDU, regardless its length.

In order to provide an extensible and precise performance evaluation of RSSN framework, a simulation framework has been developed based on Omnet++ 4.4.1 discrete event simulation environment [44].

Omnet++ has been used to reproduce a realistic satellite link between a satellite terminal (RCST) and a network control centre (NCC). The simulated environment is configured to envisage a single client PC connected to the RCST and accessing the Internet through the satellite gateway, which is co-‐located with the NCC. Additionally, INET framework 2.4.0 for Omnet++ has been used to provide accurate models for IPv4, TCP, UDP protocols and other application layer protocols like FTP, HTTP, VoIP, and video streaming. Further, INET framework is used to implement the link-‐layer model. Figure 4-‐7 shows the simulated network environment using Omnet++.

62

FIGURE 4-‐7: OMNET++ SIMULATED SATELLITE NETWORK

The developed simulation framework is built on top of EtherMAC link-‐layer model of INET [48] to simulate three different scenarios based on the security mechanism:

• Scenario 1 ULE encapsulation – No security -‐ In this scenario, the aim is to simulate the overhead of ULE encapsulation for IP traffic over DVB-‐S/RCS network; this scenario will produce the baseline traffic for the performance benchmarking without any added security features; the EtherMAC model is configured to add additional bytes to each IP packet before transmission equal to the overhead of ULE encapsulation; for example, adding additional 14-‐bytes for ULE with NPA and 8-‐bytes for ULE without NPA;

• Scenario 2 ULE encapsulation + RSSN security -‐ In this scenario the aim is to simulate the data overhead of the proposed RSSN framework; RSSN authentication and key management components are simulated as a set of MAC layer messages exchanged between the RCST and NCC when the simulation starts; additionally, RSSN data protection overhead including 9-‐bytes for CCMP-‐ULE header and 8-‐bytes MIC is added to each SNDU before transmission;

• Scenario 3: ULE encapsulation + IPSec -‐ IPSec is an end-‐to-‐end solution that provides basic security services for satellite links; in this scenario IPSec overhead with ESP tunnel mode is simulated; it simulate the IPSec overhead with AES-‐128 encryption, HMAC-‐SHA-‐1 authentication code, and an IV of the same size as the encryption block size, as specified in [34]; IPSec data overhead is computed over each IP packet and considers the padding requirements for the chosen AES encryption mode and HMAC-‐SHA-‐1 operation.

For each scenario, four types of data traffic are simulated between the RCST and the NCC: FTP and HTTP over TCP transport protocol and VoIP, and Video Streaming over UDP transport protocol. For each protocol, one hour of traffic have simulated to obtain a realistic user behaviour over satellite network. The evaluation involves the measurement of SNDU size as well as the data overhead for both security mechanisms, RSSN and IPSec on each of the simulated protocols. Finally, the results achieved for each protocol will be assessed. Table 4-‐2 summarizes the simulation setup.



63

Simulation Time 1-‐hours RTT 600ms Bandwidth 4 Mbps MTU 1500 Bytes Link-‐Layer Ether-‐MAC Network Protocol IPv4 Transport Protocol TCP (Reno) / UDP Application Protocols over TCP

FTP: 1MB file transfer every 10 min. HTTP/1.0: Resources Size: 500B -‐ 20KB

Application Protocols over UDP

Video Streaming: Packet length 256, 512, 1024, 1500 Bytes VoIP: 40-‐bytes voice packets

TABLE 4-‐2: SIMULATION SETUP

4.2.3.1 FTP Traffic:

To simulate FTP traffic, the terminal is configured to download 1MB file from the NCC over the satellite link every 10 minutes. In fact the simulation run for 1 hour for each scenario, ULE no security, ULE with RSSN, and ULE with IPSec. For detailed investigation, Figure 4-‐8 shows a zoomed view for the first 10s of the traffic, using all the simulated scenarios and starting the simulation at time 0s. The packets at the bottom present ARP request and TCP establishment handshake (3 packets) for each scenario, while the upper packets presents the FTP traffic.

FIGURE 4-‐8: SIMULATED FTP TRAFFIC (ZOOM VIEW)

RSSN slightly increases the packet size because of the overhead added to the encapsulated SNDU, namely ULE-‐CCMP header for confidentiality (9-‐bytes) and the MIC for the data authentication (8-‐bytes). This adds a fixed size overhead total 17-‐bytes, to each SNDU regardless the packet size. Since FTP uses a large packet size, 17-‐bytes the overhead will have a very minor influence on the total packet size.

IPSec increases the packet size because of the headers added to the original IP packet, namely the ESP header for confidentiality (40-‐bytes) and the new IP header for the tunnel (20-‐bytes). Additionally, IPSec uses block cipher for encryption and HMAC-‐SHA1 for authentication.

64

Thus, IPSec requires original IP packets long multiple of the block size, so that packets may have to be padded to bring them to the block length.

In addition to the increase of the packet size discussed above, Figure 4-‐8 shows in each scenario the connection setup time, which is the time required for communicating security handshakes between the NCC and the RSCT in order to setup a secure connection. It is considered that every two-‐handshake messages require 1 RTT. Although connection setup time is required only once after the terminal log-‐on procedure, it is still important to consider it as part of the cost of the proposed mechanism. Less than 3 seconds are required to setup the secure connection in RSSN due to the exchange of security agreement, authentication, and key distribution messages. IPSec requires at least 4.5 seconds to exchange a total of 9 messages: 6 in phase1 (main mode) and 3 in phase2 (Quick mode)[5].

4.2.3.2 HTTP Traffic

HTTP traffic is evaluated to simulate Internet surfing over the broadband satellite network. In fact, with HTTP it is important to evaluate the traffic on both directions, forward (from NCC to RCST) and return (From RCST to NCC) links since HTTP protocol works on request/response basis. For clarification, Figure 4-‐9 and Figure 4-‐10 show the average SNDU size for HTTP traffic in both forward and return links respectively, using the three simulated scenarios.



65

FIGURE 4-‐9: SIMULATED HTTP TRAFFIC IN THE FORWARD LINK

FIGURE 4-‐10: SIMULATED HTTP TRAFFIC IN THE RETURN LINK

Generally, the analysis of HTTP results proves that RSSN overhead is negligible on the forward link because the 17-‐bytes overhead is very small compared to the packet size, which is on average 1000 bytes. On the return link, where the request packets are very small (Avg. 100-‐bytes) the RSSN overhead is larger. However, in the worse scenario, when the packet size is very small, such as HTTP request packets, the RSSN overhead is only 15%.

In contrast, IPSec increases the packets size in both forward and return links due to the added headers. However, the influence in the packets size in the return link is much higher than the influence in the forward link. This is mainly due to the padding requirements of IPSec. IPSec adds padding data to IP packets to bring them to the block size, 16-‐bytes for CBC and 64-‐bytes for HMAC-‐SHA1. Therefore, the overhead of IPSec is much higher in case of smaller packets.

4.2.3.3 UDP VoIP and Video Traffic

Interactive applications are sensitive to the bandwidth available, data loss, delay, jitter, and the efficiency of data transmission. Thus, the impact of the RSSN security on the interactive multimedia applications including audio and video was evaluated.

66

Voice and video streams are transmitted over the simulated scenarios while fixing all other network parameters (loss, delay, etc.) and monitoring the influence on the packet size.

For voice, VoIPStream model of INET is used to generate a realistic VoIP packet stream over UDP with 40-‐byte payload size, a typical packet length for the voice traffic.

Figure 4-‐11 shows the behaviour for UDP VoIP streaming. Clearly, the difference between the influence in the packet size in both RSSN and IPSec is noticed.

FIGURE 4-‐11: SIMULATED VOIP TRAFFIC

In a further analysis, the impact of RSSN and IPSec on the quality of the transmitted voice streams is analyzed. In fact, the voice quality is affected by the ratio of the VoIP payload to the total packet length [6]. Figure 4-‐12 shows the format and the size change of the VoIP packet with every scenario.

FIGURE 4-‐12: OVERHEAD ADDED TO THE VOIP PDU

As it can be observed, results in Figure 4-‐12 show that the packet size is slightly increased in RSSN traffic. On the contrary, IPSec dramatically increases the packet size to reach 210-‐bytes. As a consequence, the ratio between the actual voice payload and the total packet length decreases, indicating an increase in the wasted bandwidth. i.e. bandwidth that doesn’t carry actual data. The increase in the packet size also impacts the transmission delay, queuing



67

delay, jitter and buffering delay [6], affecting the overall voice quality. Therefore, the use of RSSN when dealing with voice traffic can present a better bandwidth utilization, and reduce the transmission delay. Hence, a better voice quality.

For Video Streaming, INETVideoStreamSvr model is used to generate CBR video streaming traffic. The model is configured to generate different UDP payload sizes, namely 256, 512, 1024 and 1500 bytes. The influence of the added data overhead is measured on the final packet size at every scenario.

The results show that the RSSN overhead is constant (17-‐bytes) over all packet sizes. Moreover, when UDP packets with size equal to the MTU (1500 bytes) have been used, the IP payload has exceed the maximum transmission unit (MTU). Hence, IP fragmentation is necessary. In this case RSSN behaves similarly and increases the size of the fragmented packets by adding 17-‐bytes to each fragment.

In fact, video streaming is very sensitive to parameters of the network such as delay, packet loss, jitter, and channel bit rate. When these parameters exceed certain thresholds, the quality of the video drops abruptly.

By fixing all network related parameters including delay, packet loss, etc. The average UDP throughput for the proposed RSSN is measured in comparison to ULE and IPSec traffic, in order to understand the impact of the security overhead on the video quality. Figure 4-‐13 shows the throughput (bits/sec) for ULE, RSSN, and IPSec for the simulated UDP payload sizes, namely, 256, 512, 1024, and 1500 bytes.

FIGURE 4-‐13: THROUGHPUT VS UDP PACKET SIZE

While both ULE and RSSN traffics show similar throughput, IPSec requires a higher throughput. The bend in the IPSec line is caused by the high IPSec overhead on the

68

fragmented IP payloads. Generally, IP needs to fragment packets with a UDP payload greater than 1472 bytes to avoid the total packet size exceed the MTU.

Table 4-‐3 compares the data overhead added by RSSN and IPSec to the non-‐secure ULE traffic using all evaluated protocols.

Protocol Added Data Overhead %

(Avg.) RSSN IPSec

FTP 1.5 8.8 HTTP (FWD) 4.9 18.6 HTTP (RTRN) 15.3 46.7 VoIP 14.0 54.0 Video 1.0 10.0

TABLE 4-‐3: AVERAGE DATA OVERHEAD RSSN VS. IPSEC

It can be inferred from Table 4-‐3 that RSSN outperforms IPSec with all evaluated protocols. The improvement in the data overhead offered by RSSN consequently results in an enhancement in the bandwidth utilization, providing bandwidth savings up to 31% comparing to the IPSec, e.g. with HTTP traffic on the return link. Furthermore, RSSN enhances the performance of interactive applications and provides all the required security services.

69

5 FUTURE WEB TECHNOLOGIES (WEB 2.0) AND SATELLITE NETWORKS

At the beginning of the Web, pages were rendered server-‐side and every user interaction required a page reload. In the post-‐Facebook era, pages usually change dynamically inside the browser, without triggering a reload. This paradigm has been mainly applied to the World Wide Web (WWW), which now approximates the Social Web envisaged by the World Wide Web Consortium (W3C) [49]. Yet, its implementation is based on a heterogeneous set of specific services, rather than by pursuing a single unified design. Components include: blogs, wikis, Online Social Networks (OSNs), and multimedia sharing platforms. In parallel, legacy websites have also been enriched with such functions. It has been proven that the more that load times are reduced the more a content provider can sell on Internet [69]. Thus, being fast is the true call of every web application: fast to load, fast to use, and fast to update.

This enriched vision has not been limited only to content and speed. Another trend is the creation of applications embedded within Web pages, i.e., Software-‐as-‐a-‐Service (SaaS) platforms [54], where interactive Graphical User Interfaces (GUIs) are operated from the browser. Yet, to issue commands and provide feedbacks to users, they require a non-‐negligible amount of bandwidth and real-‐time constraints for assuring prompt data synchronization with a remote back-‐office.

The growing complexity of the Web content also impacts the network, and vice versa. Some issues that have been resolved by amending the HTTP protocol specification:

a) An increased number of objects per page requires parallelization of the retrieval process to avoid performance degradation;

70

b) The rising volume of data needs an increase in protocol efficiency by reducing overheads;

c) The distributed nature of many contents (i.e., data stored by different content providers), jointly with the need of long-‐held connections for interactivity purposes, requires more flexible policies.

To partially fulfil the requirements i) — iii), the HTTP/1.1 [32] relied on multiple connections for concurrency. However, this can introduce additional hazards, including supplementary round trips for completing the connection setup/teardown phases, delays in the slow-‐start phase of the TCP, as well as connection rationing by the client, e.g., when a client tries to avoid opening too many connections to a single server. Such issues are even more severe when in presence of links having high delays, such as those provided through satellites.

FIGURE 5-‐1: EXAMPLE OF PIPELINING OF HTTP REQUESTS.

Nevertheless, the support of multiple connections is not the only mechanism to improve data rates. Another important methodology is pipelining in which multiple HTTP requests are sent using a single TCP connection without waiting for a response. This can reduce the load times of pages, with potential gains greater over high latency connections, such as satellite networks [73]. This improvement is possible, since several HTTP requests may be sent in a single TCP packet. Hence, pipelining HTTP connections reduces the offered load in terms of TCP Protocol Data Units (PDUs). Figure 5-‐1 shows how pipelining reduces the connection time with the respect to sequential HTTP requests.

However, the gains achievable through pipelining are limited by the HTTP/1.1 protocol specification, since the server must generate responses in the same order that the requests were received. Thus, the entire flow of information belonging to a connection is ruled according to a first-‐in-‐first-‐out policy. This can lead to performance degradation also known as Head of Line (HOL) blocking phenomena Figure 5-‐2.


Future Web Technologies (WEB 2.0) and Satellite Networks

71

FIGURE 5-‐2: HOL BLOCKING EXAMPLE

HOL blocking is a performance-‐limiting event occurring when a line of packets is held-‐up by the first packet, for example in input buffered network switches, out-‐of-‐ order delivery, and multiple requests in HTTP pipelining. This HTTP pipelining requires the proper support both by the client and the server. Flows in HTTP have introduced a series of workarounds:

a) Files Concatenations; on most sites, the major component of download time is not the base HTML file itself, but the number of subsequent HTTP requests to load the page’s supporting files – CSS, JavaScript, images, etc. Each requires extra HTTP requests, and each unique request adds time. The fewer the requests to the server that the browser has to make, the faster the page will load. There is an inherent overhead in each HTTP request. It takes substantially less time to serve one 60K file than it does three 20K files and much less than it does six 10K files. Minimizing CSS and JavaScript files can be done by just concatenating all files into two combined files (one for CSS and one for JavaScript) and minimizing them by data compressors. It allows to quickly going from 10 or more files down to 2 files only, and their size can be greatly reduced. These methods could be used in link-‐specific protocol enhancing proxies.

b) Image sprite; is a collection of images put into a single image. A web page with many images can take a long time to load and generates multiple server requests. Using image sprites will reduce the number of server requests and save bandwidth. For instance, instead of using three separate images, this single image is "img_sprites.gif" is used and using the CSS file, the client can show just the part of the image needed. In the following example the CSS file specifies which part of the "img_sprites.gif" image to show:

img.home { width:46px; height:44px; background:url(img_sprites.gif) 0 0;

72

}

d) Domain sharding; is a well-‐known practice to share content server load between multiple sites. It can also trick browsers into opening many more connections with a server than what is allowed by default. This is important for improving page load times in the face of a page containing many objects. Given that the number of objects comprising a page has more than tripled in the past 8 years, now averaging nearly 85 objects per page [70], this technique is not only useful, it is often a requirement. Modern browsers like to limit browsers to 6-‐8 connections per host, which means just to load one page a browser has to not only make 85 requests over 6-‐8 connections, but it must also receive those requests over those same, limited number of connections. Consider, too, that the browser only downloads 2-‐6 objects over a single connection at a time, making this process somewhat fraught with peril when it comes to performance. This is generally why capacity is not a bottleneck for web applications but rather it is TCP-‐related issues such as round trip time (latency).

e) Resource inlining; is the use of a linked object, often an image, from one site by a web page belonging to a second site. The second site is said to have an inline link to the site where the object is located.

The ability to display content from one site within another is part of the original design of the Web's hypertext medium. The blurring of boundaries between sites can lead to other problems when the site violates the user expectations. Inline linking can also be exploited for malicious purposes.

These techniques are driving significant alterations in the traffic patterns generated by applications. This traffic exhibits new features. Specifically, for a classic Web page is composed of many objects, which have to be retrieved to compose whole content, i.e., the main object containing the HTML code, and (multiple) in-‐line objects linked within the hypertext. Thus, the enriched requirements of the web significantly alter the characteristics of in-‐line objects, which still looking for additional services, e.g., for audio/video streaming, or to interact with an OSN.

Another important feature is increased support of mobility. Thus, network appliances mostly assure connectivity while “on the road” via wireless links, e.g., IEEE 802.11, the Universal Mobile Telecommunication System (UMTS) and satellite networks. In this perspective, mobile nodes impose constraints clashing with the resource-‐consuming nature of the Web technology. This is particularly true for satellite network, potentially leading to additional hazards in terms of performances (e.g., [77] evaluated the performance of OSN accessed through a geostationary satellite link).

Therefore, the process of the utilization of the Web has changed, and it is expected this trend will eventually become the so-‐called Web 2.0. The latter is a hyponym embracing a variety of technologies and development methods, include: the future techniques for server initiated data transmission (Server Push), which transmit the webpage contents from the server to the web browser without an explicit user request; Asynchronous JavaScript and XML (AJAX)



73

technique, which is based on the use of the XML-‐ HTTP-‐Request Javascript object for constant data transmission between the server and the client by means of an indefinitely held HTTP connection; WebSocket protocol, which provides a full-‐duplex communication channel between the server and web browser over a single TCP connection.

Web 2.0 technologies are also set to change the requirements placed on a network – with an increasing emphasis on minimizing webpage download time, and an increasing need to consider on-‐off interactivity. The motivation for transport changes is a growing availability of high-‐speed xDSL/cable access. However, these high-‐speed services differ from most wireless and satellite systems in key ways. Current wireless/satellite systems typically employ dynamic capacity schemes with protocol accelerators and access methods that have been tuned for the existing web traffic. The traffic patterns and protocol behaviour of new web protocols is very different. It is therefore important to assess the implications on the design and operation of satellite systems as the new web is increasingly used. This is the focus of this chapter.

5.1 Real-‐Time Data Server Push Techniques

Several techniques emerged for delivering data from a web server to the browser, without an explicit user action. Like most technologies, their development was driven by explicit user demand. It is then important to analyse the requirements of these new “real-‐time” web applications. The use cases for server push are two: collaborative and informational applications.

Collaborative applications allow users to work together, e.g. work on a shared document, or activity in a chat-‐room. In that sense, social networks are the ultimate collaborative tools, as the updates of friends/followers/connections are automatically delivered to the browser. Users of these applications are millions.

Informational applications are usually less interactive, however users increasingly seek to know what it is happening now. The popular booking.com website let users know in real-‐time how many of them are browsing that page. This is deliberately inserted because it causes a “sense of urgency” to book the hotel room.

Informational applications also include applications that show graphs to the end user. It is possible to update these graphs automatically, without user intervention. Some very popular applications, such as Gmail, show counters in their home page to invite users to sign up.

These two use cases are similar in their need for a fast and cheap way to send updates to the client. The use cases differ in the way the client-‐server communication must be handled. Collaborative applications are bidirectional and symmetrical, as they have usually the same number of messages to be sent and received, while informational applications are unidirectional, as they just receive messages.

74

The core idea behind server push is that a communication channel must stay open between the browser and the server and that this channel must have the lowest possible overhead and latency. However, HTTP/1.1 [32] does not natively support this. HTTP is a request/response protocol, and it was not designed to handle long-‐lived connections, and most major server sites were keen to avoid accumulating state for inactive connections – both because it consumed memory and because it reduces the ability to perform server load balancing: Inside a server every request is usually processed by a worker and after some milliseconds it emits the response. This processing architecture is not compatible with long-‐lived connections, as each connection may keep one worker busy, thus quickly saturating the worker pool.

The first family of techniques leveraged a loophole inside the HTTP 1.1 spec. After receiving a response, the server need not respond immediately, but can wait and reply when it prefers. By issuing this kind of requests in series, it is possible to simulate a communication channel from the server to the browser. This technique, called “long polling”, has been in use for years across most browsers. Unfortunately, long polling has a very high overhead, because full HTTP headers are transferred for every request. Note that usually the undergoing TCP connection does not close, as HTTP/1.1 supports the “keep-‐alive” header to avoid the cost of opening a new connection at each request.

The second technology, which has not seen significant use, is called Server-‐Sent Events (SSE). This is a part of the HTML5 specifications [45]. SEE defines both a Javascript API and a data format to send data through a normal HTTP request. Unlike long polling, the response HTTP body is left open, so new events can be forwarded to the client. SSE is a backward compatible specification and most browsers (excluding IE) implement this.

Both long polling and SSE address the requirements of informational applications. However they lack proper ways of dealing with user-‐generated updates. The only possible technique is a simple AJAX call, which involves header parsing. Because browsers may be restricted not to open more than three connections to the same website, updates cannot be sent concurrently, and so must be queued or batched.

To support a collaborative use case, WebSocket [51] has been included inside the HTML5 spec. Like SSE, this is composed of a Javascript API and a data format. Unlike SSE, both the request and the response are left open, thus leading to a full-‐duplex channel. The WebSocket specification is much more complicated, and it allows transferring both data and controlling packets. Web servers started to support this in 2013.

Most web development frameworks were not designed to support a long-‐lived connection, but focus on the request/response cycle. In the last year, leading web application frameworks, such as Ruby on Rails [38], Django (Python)[53], or Symphony (PHP)[44], have been deployed side-‐by-‐side with a new generation of technologies to deal with concurrent requests. The most popular is the socket.io library [35] that runs on top of node.js, a server-‐side Javascript environment built for asynchronous I/O.

The development of server data push was driven by a reduction of the cost of sending an update. The overall cost may be evaluated in terms of network capacity consumed, and the time and memory consumed for both the server and the client.



75

5.2 AJAX Web Applications

The classical HTTP request/response model, where each web object is singularly requested by the client interface, has been shown to not scale to modern complex webpages and introduces a significant overhead for webpage loading. In addition, it introduced a poor cross-‐layer interaction with the lower layers, in particular the transport layer protocols (i.e. TCP) contributing to poor performance for web applications [42].

This diversity of applications and functions of the Web 2.0 and classical model of HTTP has determined the spreading of techniques to facilitate the real-‐time web contents based on HTTP models.

AJAX (Asynchronous JavaScript and XML)[37], is one of these techniques based on HTTP to exchange pieces of Javascript code that perform dynamic functions. AJAX is an application that introduce an intermediately layer between the client interface and the webserver in order to eliminates the request/ response cycle of HTTP. Garret [37] defined AJAX as a several technologies that are incorporating together to create the interactive webpages:

• HTML/ XHTML pages with CSS style files for the page presentation; • Document Object Model (DOM) for the dynamic display and real time interactions

of the webpage; • XML file for the interchange of webpage data and XSLT file for its manipulation; • formats; • XMLHttpRequest object for asynchronous communication and data retrieval; • JavaScript file or other client-‐side scripting language files to bind all these

technologies together.

76

FIGURE 5-‐3: ASYNCHRONOUS INTERACTIONS OF AJAX WEB APPLICATION MODEL

With AJAX, developers can move some of the page requesting process to the client interface and eliminates the request/ response direct interactions with the web server as in the classical HTTP model. To this aim, AJAX introduces an intermediary layer between the client interface and the web server, namely, “AJAX Engine”. Instead of requesting the webpage directly from the web server, the client interface loads an AJAX engine that is responsible for both communicating with the web server on behalf of the client interface, and rendering the webpage that the user sees. The AJAX engine allows the user's interaction with the web applications to happen asynchronously and most of the times independent of the communication with the web server Figure 5-‐3.

With AJAX model, the asynchronous connection between the client interface and the web server is handled at the client side by JavaScript code. Thus, every user action that would generate an HTTP request in the case of classical HTTP model, now takes the form of a JavaScript call to the underlying AJAX engine instead. Because part of the application's processing is moved at the client side, any response to a user action that doesn't require a trip back to the web server (e.g. editing some data in memory, data validation, or even some navigation) is handled by the AJAX engine itself. Depending on the data available to the engine, the client handler changes the content or structure of the webpage through the Document Object Model (DOM). In fact, this improves the web application application's response time by saving some round trips between the client and server. If the AJAX engine requires something from the server in order to respond (e.g. requesting a new data, submitting data, or reloading the web application) the engine handles those requests asynchronously, without interrupting the user's interaction with the application.



77

The asynchronous communication between the client and server, combined with the reflection mechanism provided by the DOM, together allow AJAX to provide on-‐the-‐fly data validation, producing a sophisticated graphical controls or forming a data and contents based on the client side components, which allow updating parts of the webpage without reloading the entire page.

To provide an intuitive web browsing experience to the users, AJAX Long Polling (ALP) technique has been introduced to update the results user sees in his web application automatically. ALP is a technique in which when request is sent to the server by Ajax engine, the server waits for the data requested to be available while retain the connection open, and as soon as the data is available, it is positively sent to client. This technique introduces a continuous real-‐time streaming between the server and client. It reduces the number of HTTP requests; client is not asking over and over again for new data, it asks once and waits for an answer. In most cases this approach can reduces the latency in which data becomes available to the client. However, ALP relies on the underlying TCP connection not closing down by sending “keep-‐alive” messages to avoid the cost of opening a new TCP connection for each request. Unfortunately, ALP has a very high overhead due to the need to transfer the full HTTP header at each request.

5.3 WebSocket Protocol

In order to support the collaborative paradigm of Web 2.0, WebSocket protocol [31] has also been identified by HTML5 specifications. The WebSocket Protocol is designed to address the requirements of existing two-‐way web applications in the context of the existing HTTP infrastructure. It enables a single TCP connection to use bidirectional multiple messages simultaneously between the client and the server. It aims to allow the web browser and web server to communicate with less effect of delay and packet-‐loss rate.

WebSocket is designed to work over port 80 and support HTTP proxies and intermediaries. However, the implementation does not limit the WebSocket only to HTTP model, but it could use a dedicated traffic patterns for interactive applications that do not match the standard HTTP traffic.

The protocol consists of a handshake messages for connection establishment followed by framing messages, layered above the transport layer. Once the client and server have both completed a successful handshakes, the data transfer starts through the established two-‐way communication channel. Data is sent from each side independently from the other, each transmitted data unit is called “message”. Message is composed of frames, and it doesn’t correspond to any particular network framing since the protocol allows the messages to be coalesced or split by proxies or intermediary network devices. Since WebSocket protocol only defines the protocol header, generally it can send/ receive any data type. Thus, client can request the server to use a specific sub-‐protocol within the WebSocket connection (i.e. chat or

78

booking protocols) by identifying the sub-‐protocol within the handshake messages, while the connection appears to the web server as a regular HTTP GET request.

The WebSocket is a frame-‐based protocol, where the application layer frames are layered on top of WebSocket, which is really just a layer on top of TCP that does the following [31]:

• Creates a security model for the connection between the webpage and WebSocket enabled server.

• Identify the connection parameters for every host including, port number, services, addressing, and protocols.

• The framing mechanism layered on top of the transport layer, creates the packets with variant lengths.

• Includes handshake mechanism that is designed to work in presence of proxies and other intermediate boxes.

WebSocket protocol is independent from transport layer protocols. However, it can be used to avoid the delay of TCP acknowledgements, especially in networks with a large delay as in case of satellite. Because WebSocket enables both browser and server to transfer bidirectional-‐multiplexing messages, it acts as same as TCP stream without caring about payload content. Moreover, WebSocket doesn’t allow connection establishment between the client and server over a pre-‐existing protocols i.e. SMTP and HTTP, while it allows the server to upgrade this pre-‐existing protocol. This is achieved by connection handshake, while limiting data transfer before successful handshakes.

Data is transmitted over WebSocket connection is parsed as sequence of frames. The framing layer of WebSocket defines each frame type with an op-‐code identifying the frame type (data or control frame), payload length, and designated locations for “Extension data” and “Application data”, which together define the “Payload data”. Data frames are transmitted either by the client or by the server after the successful handshake for opening a new connection and before the connection termination by the endpoint. Endpoint terminates the connection and then terminates the underlying TCP connection.

5.4 New HTTP Paradigms: HTTP/2.0 (SPDY)

To cope with the more traffic intensive behaviour of Web 2.0 application, several initiatives from private industry and standardization bodies recently started a review of HTTP and the related protocol stack to make it more suited to the new web. SPDY (Speedy Protocol)[8] is prototypal protocol implementations from Google™ that seek to make HTTP more responsive, more network-‐friendly and more suitable to the design of new web applications. This experimental protocol has been taken by the Internet Engineering Task Force (IETF) and Worldwide Web Consortium (W3C) as an input to the definition of HTTP/2.0, a new standard to improve HTTP performance using the experience cumulated in the last years with web traffic.

HTTP/2.0 is intended as a leap forward with respect to HTTP/1.1, defining a completely new protocol, which is not required to maintain backward compatibility with HTTP/1.1. HTTP/2.0



79

is expected to supersede HTTP/1.1 in all the user cases where HTTP/1.1 is currently employed. At the present time, the scope and content of the standards are being developed within the relevant working groups. There are, as yet, no formal standards, so this analysis is based on the available material only.

HTTP/2.0 aims to adopt the “Single Connection” paradigm. A single connection per domain should be sufficient to transport all the data for a web page, as long as is multiple objects can be multiplexed onto the same flow. If a stream identifier is associated with a message, the server can insert more small messages into the same response. This reduces sensibly the packet overhead. In addition, this mitigates the head of line blocking problem with persistent HTTP/1.1 which more important objects for visualization to be queued behind less important ones to the same TCP connections.

The gain in multiplexing and prioritizing objects of a web page is clearly dependent on the type of page. Web pages more fragmented will probably benefit more of serializing object into the same connection. However, the benefits of HTTP/2.0 can be significant.

SPDY leverages on the reduction of the TCP connections allowing multiple SPDY streams over a single TCP connection. With this strategy, SPDY is in charge to drive stream priority in order to accelerate transfer of the “high-‐priority” contents in despite of other ones. Expected performance is more oriented to provide a better user experience reducing transfer time of the high-‐priority contents.

5.4.1 SPDY Request Prioritization

SPDY request prioritization allows server to decide which resources are more important than another so it will handle them earlier or holding back less important resources. The client can recommend a priority to the server, helping it to make the right decision. A good prioritization can maintain progressive rendering, resulting in a better user experience.

While SPDY aims to decrease the page load time by multiplexing the page objects over a single connection, one side effect of such a multiplexing is that some high-‐priority resources might be delivered slowly due to the concurrent delivery of some non-‐critical resources. To avoid this issue, SPDY provides a scheme to allow client to indicate a priority for the requested resources; for example, a java script used to request another page or image could be requested by client with the highest priority in order to accelerate subsequent requests. Efficiency of SPDY prioritization depends on a number of implementation details [83], for example:

• How to select criteria to assign priority to requests (client-‐side); • How to set buffer size at the server side to hold the low priority resources while

processing the high priority resources.

80

The current SPDY specification does not define how the clients make these decisions, and leaves them up to the browser implementations.

5.4.2 SPDY Stream Prioritization

SPDY offers a stream priority mechanism allowing stream creator to assign an integer from 0 to 7 to each created stream. The 0 value represents the highest priority while 7 represent the lowest priority. Both sender and recipient will process the streams in the order of highest priority to lowest priority.

Stream priority informs the server which streams are most important to the client, but it is still poorly suited in several cases [61]; for example the server is transferring two resources i.e. script1 and script2 where script2 cannot be executed until script1 is completely transferred to the client, or video chunks that will be played in order. In these cases, the browser may prefer to specify a specific order for the objects: for example, ordering HTML before script1 before script2 or video-‐chunk-‐1 before video-‐chunk-‐2 and so on. Moreover, the sequential transmission of some high priority resources can improve on performance since a large script can be interpreted and executed more quickly if it does not compete for bandwidth with another large HTML transfer.

In this example below, SPDY is multiplexing multiple browser tabs from a single user connected to a SPDY proxy, with parent pointers and priorities (P=6, P=3) as shown in Figure 5-‐4.

FIGURE 5-‐4: RELATIONS, SERIALIZATION AND PRIORITIZATION IN SPDY

Tab1 and Tab2 are two browser tabs with different priorities loading together in parallel, where Tab1 is the foreground tab and Tab2 is in the background. Tab1 require two JavaScripts, “a.js” and “b.js”, where loading of “a.js” depends on “b.js” depends on Tab1.htm. In the background tab (Tab2), the two images “a.jpg” and “b.jpg” have the same parent (Tab2.htm), they are transferred simultaneously, and share the transmission capacity. Since both tabs tab1.htm and tab2.htm have no parents, so transmission of both tabs always scheduled before any other resources in their trees, but bandwidth allocation for the child objects within each tree remains similar to what required by the root of the tree. For example, if the transfer of tab2.htm is still in progress and tab1.htm is selected so the download of a.js will be scheduled before tab2.htm completes.

SPDY priority mechanism aims to improve performance by serializing the transmission of some objects and resources on the critical path. Client browser can ensure that resources needed immediately do not compete for bandwidth capacity with less important resources



81

transfer. Requested resources with a lower priority are queued waiting to fill any spare bandwidth with useful data. This scheduling mechanism is not possible in HTTP1.1 currently used. Any request, once issued, cannot be reprioritized or reordered on a single connection. In addition, it is essential to find a way to ensure the concurrency to keep the client-‐server pipe full. While the browser might serialize the transfer itself, the many small transfers typical of page loads would significantly limit utilization. With ordering and reprioritization in SPDY, browsers can jointly optimize both the transfer pipeline and resource priority, rather than being forced to accept poor utilization or poor transfer schedules.

5.4.3 SPDY Server Push

With a traditional HTTP transfer, server can only send a resource to the client when the client explicitly sends the corresponding request. When client requests an HTML page, the server knows that the client will also need the associated Java scripts and CSS files for that page, but it cannot start sending them until the client explicitly request those resources as well. Such a behaviour wastes time making the overall page loading time longer, especially in case of network with large latencies (i.e. satellite). Server push is a feature of SPDY protocol (ver. 3) that allows the server to proactively send some resources to the client without waiting for the client request. Pushing of resources avoids the round-‐trip delay for resource request with a relevant improvement on the page loading time. Then, the entire objects correlated one with other should be pushed to the client before it discovers the need to send requests for such objects. SPDY enables the server to send multiple replies to the client for a single request. The browser validates and caches pushed responses in same way that it would cache any other response.

Push option of SPDY is expected to particularly improve on performance over satellite networks since it well exploits satellite channel characteristics. Broadcast/multicast forward link can issue push resources without any particular congestion problem. In addition, broadcast channel should be used to send the same request to multiple terminals at once increasing efficiency Cashing proxy implementation at the user terminal to cash the pushed objects from the server will increase the efficiency of the broadcast channel avoiding pushing the same objects many times over the broadcast channel. In fact, many users should simultaneously (or within of a short time-‐range) access the same web page (i.e. web page with embedded video of a live press conference) can receive the pushed objects from the cash proxy instead of utilizing the broadcast channel to receive similar resources.

On the other hand, since the pushed resources have no request headers associated with every object, so server push strategy helps to reduce user-‐experienced latency by reliving the client from sending a separate request header for each object, which in satellite link is at least half second (request-‐response round-‐trip).

82

5.4.4 SPDY Flow Control

In the current versions of HTTP/1.0 or HTTP/1.1, there is no interleaving of Request/Response pairs so any flow control issues are handled by the underlying TCP congestion control mechanism at the transport layer. While SPDY multiplexing multiple streams over a single TCP connection, so each Request/Response pair uses a separate stream. Multiple streams share the same TCP connection.

This interaction among multiple streams introduces different issues i.e. prioritization, head of line blocking, and flow control, perhaps flow control is the most complex aspect [66]. Since streams interaction is not visible to the TCP layer to handle any of these issues, handling of streams interaction.

Flow control for Multiplexing in SPDY follows these principles:

• Flow control is hop by hop not end-‐to-‐end. • Flow control is depends on window update control messages. • Flow control is declared by the receiver and will be advertised to the sender. For

example, a client, a server or a proxy (when they acting role as a receiver) they will advertise their flow control preference to the sender, which will regulate the transmission as per that preference.

SPDY implements a flow control mechanism at the framing layer relying on a data transfer window kept by the sender of each data stream. The data transfer window is a 32 unit that indicates the amount of data bytes the sender can transmit to the recipient [55].

After a stream is created, and before transmitting any data frames, the sender starts with the default initial window size. This window size is used to measure the buffering capability of the recipient. The sender can only send data frame with length less than or equal to the transfer window size. After sending every data frame, the sender can decrements its transfer window size by the amount of data transmitted. When the window size becomes less than or equal to 0, the sender will pause the data frames transmission. At the other side of the stream, the recipient sends a “WINDOW_UPDATE” control back to notify the sender that it has processed some data and freed up buffer space to receive more data.

The “WINDOW_UPDATE” control frame is used to implement a per-‐stream flow control in SPDY. Flow control in SPDY is per hop, which is between the two SPDY endpoints. If there are one or more intermediate points between the client and the server, flow control updates are not forwarded by these intermediates. Flow control only applies to the data portion of data frames, while recipients must buffer all control frames received. In case recipient fails to buffer the control frame, it will issue a stream FLOW_CONTROL_ERROR error for that stream. Figure 2 shows a typical window update control frame, which is composed of the following fields:

• Control bit: The control bit is always 1 for this message. • Version: The HTTP/2.0 version number. • Type: The message type for a WINDOW_UPDATE message is 9.



83

• Length: The length field is always 8 for this frame (there are 8 bytes after the length field).

• Stream-‐ID: The stream ID that this WINDOW_UPDATE control frame is for. • Delta-‐Window-‐Size: The additional number of bytes that the sender can transmit

in addition to existing remaining window size. The legal range for this field is 1 to 2^31 -‐ 1 (0x7fffffff) bytes.

1 Version 9 0 (Flags) 8 (Length)

X Stream-‐ID (31-‐bits) X Delta-‐Window-‐Size (31-‐bits)

FIGURE 5-‐5: WINODOWS_UPDATE CONTROL FRAME

The window size as kept by the sender must never exceed 231 Bytes. If a sender receives a “WINDOW_UPDATE” that makes the window size to exceed this limit, it will send FLOW_CONTROL_ERROR RST_STREAM to terminate this stream. At the beginning, when SPDY connection is established, the default initial window size for all streams is 64KB. Both endpoints can use the SETTINGS control frame to adjust the initial window size for the connection.

Depending on “WINDOWS_UPDATE” messages to advertise the receiver preference of flow control could be an issue in satellite network due to the considerable delay on the return link.

Since flow control is hop to hop and not supporting end-‐to-‐end connection so this make it no very efficient in case of satellite network since the sender cannot satisfy the flow control preferences for every client behind the user terminal where it can receive the “WINDOWS_UPDATE” messages.

5.5 Impact of The Future Web Technologies On Performance Of

Satellite Networks

After introducing the key characteristics of the future web technologies, it is sought to understand and evaluated the implications for satellite networking of the introduction of such technologies and its related TCP/IP stack modifications. The purpose was to evaluate, the suitability of the new technologies to satellite network and whether the satellite research community should take part in this definition.

Server-‐side push technology determines additional content that may benefit a user in future and uses network/client/server resources to deliver this content to reduce the future download latency. This trade-‐off resembles pre-‐fetching of content by http-‐level protocol enhancing proxies, which can pre-‐fill a cache with content before a user requests the content. However there are differences. One difference is the decision on which content is sent – in the

84

one case the accelerating proxy decides (e.g. based on heuristics of user demand and understanding of the satellite network capacity, in the other case the content provider decides (with better heuristics on content demand but less understanding of the specific characteristics of the links. For example, loading and Return link Resource Management (RRM) interactions for satellite).

The algorithms used in pre-‐fetching systems may be subject to Intellectual Property Rights, making this an area where there is little published research or open algorithms. For high-‐speed fixed networks the merits of server push and prefetching is clear, for wireless technologies there are concerns that this reduces control of the volume/rate of traffic. These concerns also apply to networks that use satellite technology. The concerns are aggravated because encryption of the transfer streams could mean there is currently little opportunity for the wireless/satellite operator to intercept the protocol and then influence the decisions made at the server.

In the satellite scenario a round-‐trip-‐time of 600ms is typical, including all processing times, because of the long propagation delay. This leads to a reduced responsiveness in these Real-‐Time web applications. In particular collaborative applications are not usually tested in regime of high delays, and they may behave incorrectly. In order to prevent these problems, applications should employ Operational Transformation Algorithms [9] to enforce consistency of edits in a shared document. Unfortunately, most applications do not employ them.

AJAX application can provide a faster data transfers and lower overhead compared to the classical HTTP model. Moreover, the JavaScript Object Notation (JSON) is increasingly preferred to the more complex XML as a transfer language. However, The main limiting factor of the modern web technologies, including AJAX is the network-‐induced latency, which is strictly related to the Round Trip Time (RTT) between the client and the server. As the RTT increases, the responsiveness of web protocols degrades. This is particularly critical when the Internet access is through satellite, as the RTT might be several times the one of terrestrial connections (RTT is about 600ms for a GEO satellite).

AJAX depends on two main technologies, asynchronous communications and Document Object Model (DOM) manipulation. Thus, it expected that the faults associated with these two technologies become more common and widespread in case of Internet access through satellite. AJAX implementations often assume that server response comes immediately after the client request, with nothing occurring in-‐between. However, this is a reasonable assumption under networks with a good performance, when the network performance become inconsistent due to variant RTT, high bit error rate as in satellite networks, AJAX applications may occasionally face some unintended interleaving of server messages, swapped call-‐backs, and incorrect DOM manipulation. All such faults are hard to reveal and require dedicated techniques.

Some AJAX techniques (i.e. ALP), maintains multiple parallel persistent connections between users and the web server. This reduces the overhead implied by frequently opening of TCP connections, as at least 3 handshakes are required for every connection (SYN, SYN-‐ACK and



85

ACK). However, the multiplication of TCP connections per page has serious consequences on the satellite networks:

• First, the aggregate of connections behaves aggressively with respect to other traffic (i.e. it behaves as an aggregate of TCP flow rather than a single flow).

• Second, it increases the per-‐connection setup overhead, including the signalling to setup a connection and start-‐up latency.

• Moreover, it increases the per-‐connection load to the network. This is an issue for intermediaries that need to monitor user traffic or track connection state, such as gateway or PEPs, and need to track up hundreds of connections per user. Fewer longer-‐lived flows offer better performance anyway, and require much less state in the satellite system.

At the time of writing, the HTTP/2.0 (SPDY) specification is far from finished and many points remain under discussion within the HTTPbis WG1. However, some presently open issues that expected to impact on satellite networks can be highlighted.

Server Push is still a debated topic within the HTTPbis WG. Although it can be used to anticipate client requests, it could also transmit data that the client is not able to receive or use. Several people fear that Server Push may lead to large amounts of undesired data to the client.

Since Server Push is a server-‐side optimization, it assumes a server has good knowledge of the network characteristics and user expectations. In any non-‐cabled environment the path characteristics may be hard to be predict a priori, being a function of many parameters (propagation conditions, system load, SLA-‐enforcement, etc.), and therefore different optimizations may be need when a path includes a satellite, mobile cellular or wireless network. The way in which these impact the design and usage of Server Push will need to be determined before the effect on satellite networks can be fully understood.

In addition, major server sites are keen to avoid accumulating state for inactive connections – both because it consumed memory and because it reduces the ability to perform server load balancing.

Many satellite networks rely on protocol enhancing proxies (PEPs) to perform TCP and HTTP/1.1 acceleration. These have often become regarded as essential components for satellite networks that support web access. In networking terms, these boxes are a proxy/middle-‐box that works as an intermediary between the content server and the client.

Transport layer PEPs (e.g., split TCP) have been shown to work effectively with SPDY, and are hence expected to continue to work with HTTP/2.0 The main issue is that HTTP/2.0 has motivated changes in the transport protocols, and that any future transport PEP needs to be

1 https://tools.ietf.org/wg/httpbis/

86

able to accommodate these changes to avoid the pitfalls of ossification (i.e. down-‐grading the transport to an old version so that the PEP can accelerate the transport, whereas a native transport with no transport PEP would have achieved higher performance).

The role of the intermediary in HTTP/2.0 and in particular how HTTP/2.0 interacts with HTTP/1.1, still needs to be specified. The use of session encryption (TLS) ensures that a HTTP/2.0 client and server explicitly acknowledge the presence of any intermediary that is allowed access and manipulates data transmitted between the server and the client. This form of middle-‐box interception is a much-‐requested feature, because many network administrators wish to protect their network and filter and/or disallow certain sites.

Defining the (trusted) interaction of HTTP behaviour with middle-‐boxes creates a range of problems, such as how to ensure confidentiality while granting access to data to third parties and how to provide end-‐to-‐end control of a flow that needs to be operated from within the network.

In present satellite systems, the interception of application layer protocols is a key function of application layer PEPs, and used by products such as Turbo Page™2. The use of intermediaries will need to be different, and this suggests that the currently combined role of applications and transport PEPs could be better viewed as two separate roles, with the possible use of a “standard” configured proxy for web acceleration.

PEPs can also influence the quality of service requested in the lower layer satellite service, defining how flows are mapped to lower layer functions. Such PEPs need to be aware of flow traffic patterns/requirements. Present systems often rely on deep packet inspection. This could not be studied in the current project, but as the transport layer evolves (possibly away from TCP) and there is increased use of encryption (e.g. TLS used by HTTP/2.0) and automated compression, access to upper layer protocol headers will become impossible at PEP. Satellite networks therefore need to differentiate traffic using other mechanisms, such as support of Differentiated Services packet marking.

SPDY does not offer a single protocol or solution. Instead, it should be viewed as a toolkit of methods that are dynamically tuned by the client and server, and where the set of methods and tuning are both expected to evolve over time. This model can make it hard to understand why a particular choice were made by a server, but is expected to be addressed as the protocol evolves (e.g. some satellite characteristics are also common to the more common mobile cellular use-‐case). However, it re-‐enforces the need for any satellite-‐specific optimizations to avoid ossification.

2 TurboPage with Active Compression, Hughes®, http://www.hughes.com/technologies/satellite-‐

systems/hughes-‐technology/turbopage-‐withactivecompression

87

6 HTTP/2.0 OVER SATELLITE: AN ALTERNATIVE END-‐TO-‐END OPTIMIZATION TECHNIQUE

There is still a lack of literature examining the performance analysis of HTTP/2.0 (namely SPDY) over a wide variety of network scenarios. Hence, this study specifically focuses on the multiplexing ability of SPDY when used over a satellite channel. While this emphasizes benefits of exchanging data within a single SPDY stream relying upon a single TCP connection, the aim is also to explore the impact of header compression when juxtaposed over a network characterized by high access delays. Investigating a satellite use-‐case has the additional benefit of increasing the understanding of SPDY in terms of HOL blockings due to loss, as well as poor performances due to large propagation delays influencing the congestion control of the TCP.

Nevertheless, since SPDY can dramatically reduce the number of open connections, its deployment in satellite networks can lead to additional benefits. For instance, typical transport-‐layer enhancements like Performance Enhancing Proxies (PEPs) can experience a reduced workload, i.e., in terms of TCP connections to be handled to serve multiple Web sessions.

In conclusion, this study aims at evaluating the feasibility of using SPDY to increase performances of Web data over broadband satellites. From the authors’ best knowledge, this is the first study evaluating SPDY over satellite links. The contributions are:

88

• To bring out lights and shadows of SPDY protocol when used over large delay-‐bandwidth channels;

• To showcase the creation of an ad-‐hoc testbed, which can be reused for similar investigations;

• To provide an earlier comparison among the most popular websites accessed via HTTP and SPDY.

• To assess performance gap between satellite and terrestrial (xDSL-‐like) in order to understand if satellite role can be reviewed for the future Internet.

6.1 Testbed Description

It was aimed to analyse how SPDY traffic interacts with various Bandwidth-‐on-‐Demand (BoD) mechanisms and evaluate the efficiency of usage of satellite link resources. All performed tests are based on the Satellite Network Emulation Platform (SNEP), developed by TLCSat group1 at the University of Rome, which emulates a DVB-‐RCS network [28] with Bandwidth on Demand. SNEP is briefly described in the following section. In addition, an Apache web server with SPDY is setup to investigate the impact of multiplexing, header compression, and server push functions of SPDY. The testing web server is accessed through a SPDY supported web browser (Google Chrome and Firefox).

6.1.1 Satellite Network Emulation Platform (SNEP)

FIGURE 6-‐1: SATELLITE NETWORK EMULATION PLATFORM (SNEP).

The Satellite Network Emulation Platform (SNEP) [28] is a satellite Virtual Network where the behaviour of components of a DVB-‐RCS network is emulated on a virtual environment managed by the VMware vSphere Hypervisor ESXi software [87]. Each virtual node emulates a single component of a typical VSAT satellite network with DVB-‐RCS or terrestrial link technology as return channel. The core components of SNEP are:

1 http://tlcsat.uniroma2.it


HTTP/2.0 Over Satellite: an Alternative End-‐to-‐End Optimization Technique

89

• The Gateway (access router); • The Network Control Centre (NCC) or Hub; • The Satellite; • The Satellite Terminals (ST); • The User Terminals (UTs), connected to the STs through a Local Area Network

(LAN).

A separate image of a Linux file system is developed for each component and used to instantiate the component in SNEP. Figure 6-‐1 shows an example of interconnections between emulated nodes in SNEP and real external nodes or external networks (Wi-‐Fi, etc.). Connection to external entities is required to test the interoperation of the DVB-‐RCS network with other systems. To this purpose, the physical Ethernet interfaces of the hypervisor are logically attached to every subnet of the emulated network, so that real hardware can be connected in each emulated segment. Moreover, a VPN can be used to bridge an external interface onto the emulated LAN.

SNEP be accessed remotely through a public web interface [28]. The remote user can access several configuration web interfaces for configuring the platform configuration, executing tests, generating real-‐time plots, and configuring a target satellite scenario.

SNEP is implemented by a series of software modules in user and kernel space (a stable version of kernel 2.6 is currently used). Ethernet frames are brought at user space from an Ethernet interface in promiscuous mode and processed by an application-‐layer agent. DVB-‐RCS signalling messages are separated from the rest of the traffic to operate BoD methods. The DVB-‐RCS messages are used to negotiate the bandwidth allocated to satellite terminals (STs). A set of commands to the kernel through the Linux traffic controller [28] implements the actual bandwidth regulation. Moreover, in order to emulate the DiffServ queuing system of DVB-‐RCS [80], packets are stored in a buffer that implements multiple parallel queues. Individual queues may receive priority for traffic scheduling on the Ethernet interface.

6.1.2 SPDY Web Server & Web Client

An Apache web server with SPDY/3 is setup at UNIROMA’s laboratory. The web server is configured with the “Server Push” feature. When the Server Push is enabled (named XAssociated-‐Content in SPDY/3), the server is allowed to send HTTP objects without a request. For example, upon the initial requests for the main page, all the other objects related to that page can be sent without solicitation from the client.

SPDY web server is configured with access to different static HTML pages. One of these pages (https://tlcweb.eln.uniroma2.it/spdy_Demo.html) contains a picture made up of many smaller images. As the page is accessed, the server sends the images before a request is explicitly submitted for them, thus saving several round-‐trips.

90

For what concerns the hardware, both the Web client and the server are based on quad-‐core PCs with 32 gigabytes RAM. Therefore, hardware performance is not a limiting constraint in any of the performed tests.

To capture data, the Wireshark sniffer with the SPDYShark extension is used enabling to decode protocol messages and to inspect its relevant parameters. When TLS/SSL encryption is used, Wireshark is configured to use the proper SSL keys to decrypt/decode the gathered data.

Web Server and Client configurations are detailed in Table 6-‐1 and Table 6-‐2, respectively.

Parameter Value Operating System Ubuntu 12.04 LTS/ i686. Linux kernel 3.2

TCP configuration

TCP Cubic (configurable TCP parameter will be selected to optimise performance over satellite) tcp_moderate_rcvbuf IW = 10

Web Server configuration

Apache/2.2.22 SPDY: Mod_SPDY 0.9.3.3 Server Push (X-‐Associated-‐Content header) enabled with different percentage for the pushed objects. Apache KeepAlive settings enabled / disabled Default Apache configurations

TABLE 6-‐1: WEB SERVER CONFIGURATIONS.

Parameter Value Operating System: Ubuntu 12.04 LTS/ i686. Linux kernel 3.2

Web Browser Google Chrome 26.0.1410.40 Mozilla Firefox (24.0)

Benchmarking and Analysis tools

Chrome browser is equipped with the following tools: Page Benchmarking tools for Chrome; Speed Tracker for Chrome; SPDY Indicator; Google Chrome Developer Tool (GCDT). Wireshark SPDYShark (SPDY module for Wireshark) TABLE 6-‐2: WEB CLIENT CONFIGURATIONS.

6.2 SPDY Evaluation Over DVB-‐RCS Satellite Links

To effectively pursue the vision of the future Internet, satellites must also handle Web traffic, which is increasing both in terms of volumes and complexity. In fact, modern web pages do not primarily rely on the main object containing the HTML code, but they also need several in-‐line objects.

The evolution of the Web heavily requires in-‐line objects embedding interactive services, and content-‐rich graphic elements. As a consequence, the legacy page-‐by-‐page model should be updated, along with related protocols, such as the HTTP.

To partially full such issues impairing the original HTTP, the HTTP/1.1 introduced multiple connections to increase concurrency, and pipelining to send multiple object requests over a



91

single TCP connection without waiting for a response. Even if such additions improve the performance over satellites, they are not definitive. In fact, the server must generate responses ordered as the requests were received, thus limiting gains and possibly leading to blocking. Nevertheless, parallelism of HTTP/1.1 is usually limited (i.e., 6-‐8 connections in standard browsers), and not supported by-‐default by many servers.

On the contrary, SPDY is engineered to reduce download times of content-‐rich pages, as well as for managing wireless channels, which can be characterized by large RTTs and high packet losses. Especially, to overcome to HTTP limitations, SPDY introduces:

• Multiplexed requests -‐ the number of concurrent requests that can be sent over a single connection is unbounded and properly handled by a framing layer;

• Prioritization -‐ retrievals of in-‐line objects composing a page can be properly scheduled, as to avoid congestion or to enhance the Quality of Experience (QoE). For instance, the client could fetch contents enabling to understand a page, even if incomplete;

• Header Compression -‐ since the more sophisticated pages may need up to 100 requests, enforcing compression prevents bandwidth wastes due to duplicated headers;

• Server push -‐ contents can be pushed from servers to client without additional requests.

From an architectural point of view, the previous features are grouped within a high-‐level framing layer, which tunnels data into a single SSL/TCP connection. Hence, SPDY could be a suitable solution for the delivery of Web contents over satellite links. While the performance of HTTP has been extensively studied in literature both for wired [52] and satellite networks [42], a complete understanding of SPDY is still an open research problem. Moreover, many works focus on evaluating the protocol over wired and IEEE 802.11/cellular mobile scenarios [41]. For what concerns satellites, from own best knowledge, [1] and [2] are the only previous attempts.

Therefore, this evaluation compares HTTP and SPDY when used over a satellite link. To this aim, the Satellite Network Emulation Platform (SNEP) is used to conduct tests on a realistic DVB-‐RCS environment, with different Bandwidth on Demand (BoD) schemes [12]. The contributions of this work are:

a) to understand the most relevant behaviours of SPDY when used over a realistic DVB-‐RCS channel;

b) to provide a comparison between HTTP and SPDY emphasizing the impact of inline objects;

c) to understand whether SPDY could be a suitable tool to enhance satellite communications in place of middleboxes.

92

6.2.1 Methodology

Planned measurements aim at comparing the behaviour of SPDY with the most popular versions of the HTTP protocol, especially when different BoD mechanisms are deployed in the DVB-‐RCS return link. To this aim, a single user terminal (UT1) is connected to the virtual satellite terminal (ST1), which is implemented by SNEP. The available bandwidth is 4 Mbit/s and 1 Mbit/s, for the forward and the return link, respectively. The round-‐trip propagation delay is set equal to 520ms, which is typical for a GEO satellite link. Besides, SNEP introduces an additional delay taking into account the MAC layer, i.e., the TDMA overhead and latencies due to the framing of the DVB-‐RCS. Tested BoD methods are:

• CRA (Constant Rate Assignment) -‐ all the time slots are permanently assigned to the target station for the whole simulation duration;

• RBDC (Rate Based Dynamic Capacity) or VBDC (Volume Based Dynamic Capacity) -‐ slots are dynamically assigned to the return link, depending on the traffic incoming to the satellite terminal: RBDC considers the ingress data rate, while VBDC uses the cumulative volume of queued data to compute capacity requests;

• Mixed -‐ a mix of the previous.

The values used for each BoD scheme are summarized in Table 6-‐3

BoD Scheme Values (avg. on 50 repeated trials) CRA 228 slots at a constant rate RBDC 228 rate-‐based slots VBDC 228 volume-‐based slots Mixed 18 CRA slots, 105 RBDC slots, 105 VBDC slots

TABLE 6-‐3: PARAMETERS USED FOR EMULATING THE DIFFERENT BOD SCHEMES.

To have a fair assessment, some parameters ruling the behaviour of the browser (Mozilla Firefox Ver. 24.0) were modified, both for the case of HTTP and SPDY. In fact, default values are optimized for the wired Internet. In more details:

• network.http.connection-‐retry-‐timeout : defines the amount of time before considering a connection attempt aborted. Upon expired, the browser will open a parallel backup connection. Since this parameter is set to 250ms by default, having an RTT of more than 520ms would lead to unneeded TCP connections. Thus, it has been set to 0 in these trials (i.e., deactivated);

• network.http.pipelining : enables HTTP pipelining, i.e., the browser can send multiple GET without waiting for a server response. Pipelining has been enabled and set to 32 simultaneous requests, at the maximum;

• network.http.speculative-‐parallel-‐limit : normally, set to 6, it specifies the number of half-‐opened sockets to be kept for frequently used destinations (e.g., Google APIs). To avoid unpredictable behaviours of the browser, as well as to reduce overheads on the satellite link, this parameter is imposed to 0;

• network.http.spdy.timeout : defines the amount of time to wait after the page is considered received completely and the used TCP connection is closed (i.e., the



93

RST/FIN ). The default value is 180s and is generally suitable to handle AJAX-‐based interactive contents. However, since these tests are aimed to verify performance during the page load, this value has been reduced to 5s, as to not add noise to the measured times. It is pointed out that this value is equal to the default keep-‐alive option of the “Apache 2.2.2” used in these tests, as to guarantee a fair scenario.

To emphasize the most critical behaviours when retrieving pages with different protocols, ad-‐hoc HTML pages are created for testing purposes. Specifically, to stress the iterations of the request-‐response exchange, each page contains a very large number of in-‐line objects, i.e., 640 small images. The main object implementing the hypertext (index.html) has a size of 24.8 Kbytes. It is pointed out that the test page has been crafted to highlight performance aspects of HTTP/SPDY when acting over high RTT links.

The Web server has been configured to support SPDY and different versions of HTTP, i.e., HTTP1.0, HTTP1.1, SSL/HTTP1.0, and SSL/HTTP1.1. It is underlined that since SPDY uses SSL by default, this choice has been made to provide a more fair comparison. Trials have been performed with an instrumented Firefox browser, and each trial has been repeated 50 times.

6.2.2 Results

This sub-‐section presents the outcome of the performance evaluation of the different version of HTTP and SPDY using an emulated DVB-‐RCS satellite access. For the sake of conciseness, some results are present only using the BoD method defined as “mixed” (see sub-‐section 6.2.1). Nevertheless, 6.2.2.3 offers a vis-‐à-‐vis comparison among the different BoD schemes.

Since it will be largely used in the rest of this sub-‐section, the Page Loading Time (PLT) can be defined as: 𝑃𝑃𝑃𝑃𝑃𝑃 = 𝑇𝑇!! − 𝑇𝑇! where 𝑇𝑇!! is the time at which the last i-‐th inline object composing the page is completely received (i = 642 in these tests), and 𝑇𝑇! is the time when the first GET for the index.html is performed.

6.2.2.1 Analysis of Header Compression

Native header compression is one of the most important design choices of SPDY, since it allows reducing the amount of transferred bytes. Figure 6-‐2 summarizes the amount of data transferred to retrieve the test page.

94

FIGURE 6-‐2: IMPACT OF THE HEADER COMPRESSION PER PROTOCOL.

Even if SPDY only needs 416 Kbytes to complete the transfer, such a result is very close to the cases when HTTP is adopted (~508 Kbytes). On the contrary, the real issue preventing the effectiveness of compression is due to SSL encryption, which accounts for overheads needed for the additional handshaking. In fact, the usage of SSL with the “traditional” HTTP leads to a significant increase of the transferred data: ~871 Kbytes for SSL/HTTP1.0 and ~659 Kbytes for SSL/HTTP1.1. Thus, the optimized design of SPDY in managing encryption definitely plays a role.

6.2.2.2 Analysis of TCP Connection

Understanding how TCP connections are managed by different protocols is mandatory to enhance their behaviours over satellite. Hence, Figure 6-‐3 compares different evolution of the transport layer against the time.



95

FIGURE 6-‐3: DIFFERENT MANAGEMENT SCHEMES OF TCP CONNECTIONS PER PROTOCOL.

For the case of HTTP1.0, which does not allow connection reuse, the browser opens the first TCP flow to send a GET for the index.html. As soon as it is received and parsed, a batch of 6 parallel connections is spawned to retrieve the needed in-‐line objects. The process is then iterated until the completion of the whole page. This leads to a PLT of 131s (out of the graph scale), which is not acceptable. A similar evolution happens for the case of SSL/HTTP1.0 (again out of the graph scale). Yet, the need of performing additional exchanges for the SSL signalling makes the first connection longer. Besides, encryption overheads account for longer transfer times, thus resulting into a PLT of 198s.

When using HTTP/1.1, the first steps are still the same of the previous cases. Specifically, it uses a connection to retrieve the main object, and then uses the maximum allotted of 6 parallel TCP connections to retrieve additional contents. Then, it exploits the feature of connection reuse, and each one remains open to download 100 objects (which is a limit imposed by the Apache Web Server). Recalling that the test page is composed of 642 objects, after hitting the limit of 600 items (i.e., 100 objects x 6 connections), a new batch of TCP connections is created. Such connections are mostly underutilized, since they are used to retrieve only a small fraction of data (equivalent to 42 objects only). However, compared to HTTP1.0, the overall performance achieved in terms of PLT is better of an order of magnitude, i.e., PLT ~10s. The additional 5s, for which the connections remain active are due to timeouts of Apache (i.e., the parameter network.http.spdy.timeout, as discussed in Section 6.2.1). Also SSL/HTTP1.1 behaves similarly, with times inflated by the overheads due to SSL (as explained earlier), accounting for an additional time of ~2s in the PLT compared to the plain HTTP1.1.

96

Finally, in the SPDY case, the single-‐connection setup is clearly depicted. Thus, all objects are multiplexed into a unique TCP conversation. Once the page is completely received, the TCP connection is kept open by the browser for 5s, as to maintain the same timeout period for an easier comparison. Its reduced overheads, and utilization of a unique (longer) connection, enable to better exploit the available bandwidth (even without using parallelization/pipelining). Then, SPDY has a PLT of 9s, which is similar to HTTP1.1, but with a simpler complexity in the transport layer and supporting security. This is a plus, since satellite links are usually accessed through Performance Enhancement Proxies (PEPs) or middleboxes.

Another important aspect to understand how the different Web protocols behave over a DVB-‐RCS link concerns the analysis of the throughput. Figure 6-‐4 focuses on the HTTP1.0. Results indicate that the average rate is ~9 Kbyte/s. A deeper analysis reveals that the main cause is due to the usage of separate connections (one per object, 642 on the overall). Therefore, for each connection, a set-‐up and teardown have to be performed, also worsened by the high values of the RTT, and impairments due to the slow-‐start. Similar considerations can be made when SSL is used.

HTTP1.1 SSL/HTTP1.1

FIGURE 6-‐4: THROUGHPUT ANALYSIS OF HTTP1.0

Figure 6-‐5 considers HTTP1.1. Since it implements pipelining and connection reusing, the latency impacts less on the behaviour of the TCP. As a result, the achieved throughput is more than 200 Kbyte/s. Also in this case, SSL accounts for an overhead, slightly reducing the overall performances.



97

HTTP1.1 SSL/HTTP1.1

FIGURE 6-‐5: THROUGHPUT ANALYSIS OF HTTP1.1

Finally, Figure 6-‐6 shows the evolution of SPDY. Since, it uses a single connection, the delays introduced by the satellite network are absorbed (with the acceptation that they are experienced once, and not on a per-‐flow basis). Therefore, the achieved throughput is ~250 Kbyte/s, which is the best-‐obtained value in these tests.

FIGURE 6-‐6: THROUGHPUT ANALYSIS OF SPDY

6.2.2.3 Analysis of Bandwidth on Demand Impact

Figure 6-‐7 shows how the different BoD schemes impact on the PLT, for each protocol. Since previous results clearly show degradations due to the joint use of SSL and HTTP, the evaluation of the BoD scheme only considers the plain HTTP/HTTP1.1 and SPDY. In essence, the BoD increases the latency experienced by the application, which worsen the PLT. To highlight its impact, data transfers are performed on the return link.

As showcased, SPDY always outperforms the HTTP, and improvements increase for higher values of the RTTs, which characterize the VBDC and the RBDC schemes. In particular, SPDY

98

is resilient enough to the increased latencies. In the worst case (i.e., the VDBC with an RTT of 1.6s), its PLT is ~21 s, that is only 10s greater than when using CRA. On the contrary, all the flavours of HTTP are greatly impaired by the VBDC, with a PLT ranging from ~150s (for HTTP1.1) to ~300 s (for HTTP1.0).

FIGURE 6-‐7: PLT VS. DIFFERENT BOD SCHEMES.

To assess more in depth user experience, the “Time to the first paint” can be evaluated. This parameter indicates the time when browser starts to render the web page. As a user-‐level qualitative metric, this time is more representative than the overall page load time, since it is a better indication of content readiness (first objects starts to appear on the browser window). Results are shown in Figure 6-‐8. In general, HTTP starts rendering the page faster than SPDY, since the latter needs an additional time for object multiplexing, header compression, and framing process. From result analysis, it is possible to conclude that the rendering start is constrained by security-‐related operations. Therefore, with SPDY the time of the first paint is very close to time needed to perform the overall transfer. From a different perspective, joining results in the Figure 6-‐8 with those in Figure 6-‐7, it is possible to state that with SPDY the time to complete a web page transfer is very similar to time to the first paint with HTTP.



99

FIGURE 6-‐8: TIME TO THE FIRST PAINT.

Another important feature introduced by SPDY is server push. Pushing method consists on proactively transmitting a number of objects without waiting for the corresponding requests from the client. In this way, the PLT can be reduced by eliminating the round trip time between a client request for a resource and the corresponding server’s response, while using at best available bandwidth. Server push configuration is usually set with the scope to send at once all the resources believed important for the client. However, SPDY basic mechanisms already envisage multiplexing with priority of multiple objects on a single connection. Therefore, expected advantages are not significant. Several tests have considered SPDY with different percentage of pushed objects over different BoD settings. This feature in HTTP (S) is not available. Results in Figure 6-‐9 show that SPDY download time is quite independent from the percentage of pushed objects. Again, overall performance depends on the experienced RTT, so that CRA outperforms the other schemes since leading to an RTT close to the two-‐way propagation delay only. On the other hand, VBDC provides the worst performance due to an overall RTT of about 1.6s. While the page load time is not particularly impacted by server push, the time required by the browser to start rendering (defined as time to the first paint) increases proportionally to the percentage of the pushed objects. This is due to resource encoding and header processing required by pushing process. The increase of time to the first paint as a function of an increasing percentage of the pushed objects is shown in Figure 6-‐10.

100

FIGURE 6-‐9: SPDY PAGE LOAD TIME WITH DIFFERENT PERCENTAGES OF SERVER PUSH

FIGURE 6-‐10: SPDY TIME TO THE FIRST PAINT WITH DIFFERENT PERCENTAGES OF SERVER PUSH

6.2.2.4 Analysis of the Resource Utilization

After a characterization of SPDY performance and the impact of different BoD schemes, this evaluation focuses on the network related performance in term of the resource utilization of the DVB-‐RCS links [76]. The overall transmission rate has been first monitored on both forward (web page download) and return (web requests and signalling) links. In addition, time-‐slots actually allocated on the return link have been tracked for the different application



101

protocol configurations. Without lost of generality, the mixed DAMA algorithm, as presented in Table 6-‐3, is considered for simulations.

Figure 6-‐11 reports throughput (Kbit/s) on both satellite downlink and uplink. SPDY bandwidth profile presents a spike in the downlink corresponding to the download of all objects multiplexed on a single connection and sent at once. This behaviour reduces also traffic measured on the return link, thanks to the limited number of active connections and the low number of requests generated by the client. Then, download terminates in few seconds as already proved in the previous simulation tests.

HTTP/1.1 with pipelining leads to a web download spread over a longer interval time. Although pipeline allows sending multiple object requests together, object downloads are still sequentially sent, limiting the maximum achievable rate over the TCP connection (application-‐limited rate). In addition, signalling over the return link is increased: it is about one half of the traffic over the forward link.

HTTP/1.0 (no pipelining) presents even worse performance in terms of both achieved data rate and traffic over the return link:

• Download is performed at about 50 Kbit/s out of the 4 Mbit/s available; • Traffic on the return link is very close to the amount of data downloaded; then, a

higher request of shared return link resources will be needed.

As usual, HTTPS presents the worst performance. Even SSL signalling leads return link traffic to exceed the amount of downloaded data. This result demonstrates that the lower PLT is in particular associated to a much better exploitation of the available bandwidth if using SPDY.

102

FIGURE 6-‐11: BANDWIDTH UTILIZATION DURING WEB PAGE DOWNLOAD

Finally, Figure 6-‐12 shows the dynamic assignment of available slots on the return link (using the mixed DAMA BoD) when web page download is performed four consecutive times varying the configuration. SPDY allows a better utilization of the resources getting a large number of slots for a limited time interval: at around 15s all the available slots are used to send most of data. The overall oscillatory trend is due to the burst nature of the TCP transmission on links with large delay-‐bandwidth product. In general, simulation outcomes show how SPDY transmission based on multiplexed objects allows a rapid allocation of the needed resources, limiting the impact of the DAMA allocation control loop.



103

FIGURE 6-‐12: RETURN LINK SLOTS

To opposite, with the other configurations, overall transfer is segmented into sequential smaller data chunks (i.e. a single web object) on different TCP connections. As a consequence, when a new connection is established, slots are requested proportionally to the carried data (a smaller amount than in the SPDY case). Then, when connection terminates, previous assigned slots are released, to be requested again when a new connection is established. Definitively, the average number of slots is much lower (black lines in Figure 6-‐12), while the overall transfers last a longer time period.

6.2.2.5 Analysis of Multi-‐Terminal Traffics

This evaluation aims to assess the behaviour of SPDY when bandwidth on the satellite return link is variable due to Bandwidth on Demand (BoD) allocation, when multiple satellite terminals are competing for resources. Three additional satellite terminals (RCST1, RCST2 and RCST3) generate competing traffic sharing the satellite DVB-‐RCS return channel. An IP traffic loader is installed on each competing satellite terminal (RCST1, RCST2, and RCST3) with the aim to simulate a real user’s activity by generating random web browsing of different websites and file downloads. In more details, 8 UTs are connected to each competing RCSTs. The total generated traffic dynamically varies over time and in average requires the

104

75% and the 35% of bandwidth on forward and return link respectively. Overall traffic profiles are shown in Figure 6-‐13. On the other hand, UT connected to the target satellite terminal (RCST4) is used to browse the SPDY enabled server.

A capture of RCST4 traffic activity is also shown in Figure 6-‐13. Resource assignment processed relies on the RBDC, which allows to dynamically allocating return link time slots (228 in total) depending on the rate of data filling RCST buffers.

FIGURE 6-‐13: SNEP MULTI-‐TERMINAL TRAFFIC GENERATION

Figure 6-‐14 presents the average download time for the different configurations, together with the variation range. The black lines indicate the maximum and minimum values for page download time resulted from the test run for 50 iterations. In addition, results for multiple RCST are compared to the ones achieved in previous test, when target RCST does not compete for return link bandwidth.

Dynamic bandwidth variations mainly affect performance of both HTTP and HTTPS: page download time is increased by 22% and 24% respectively. HTTP with pipelining is more resilient to bandwidth variations (page download time increased by 11%). The rationale is that pipelining allows sending more objects together over a single connection reducing the overall transmission time. Then, the probability that page download time interval is overlapped with a traffic peak coming from a competing RCST is lower. To opposite, HTTP



105

and HTTPS require a longer time for transmission of the same objects increasing the chance of competition on the bandwidth with other RCSTs.

SPDY object multiplexing leads to a transmission similar to a single file transfer (i.e. FTP). As a consequence, considering that initial TCP settings are optimized for the satellite link (IW=10 MSS and slow start threshold= bandwidth-‐delay product), SPDY tries to use all the available resources in a short time. Then, competing traffic constantly limits SPDY transfer transmission rate with respect to the case of absence of concurrent traffic. This explains the 56% increase of the download time, although it is still much lower than the one experienced with the other configurations.

106

FIGURE 6-‐14: WEB PAGE DOWNLOAD TIME IN A MULTIPLE RCST SCENARIO

FIGURE 6-‐15: SPDY PERFORMANCE DETAILS IN MULTIPLE RCSTS CONFIGURATION

Figure 6-‐15 details SPDY results providing page download time achieved in every run for the multi-‐terminal scenario. Page download time over 50 iterations varies from 13.5s to 31.5s depending on the variations of the bandwidth utilized by the other terminals during the specific run. For comparison, Figure 6-‐15 includes also results related to 50 test iterations in a configuration where target RCST can exploit all the available bandwidth without competition with other RCSTs.



107

6.3 Impact of SPDY on The Satellite Network Architecture

The previous study (Section 6.2) compared the behaviours of different flavours of HTTP and SPDY over a DVB-‐RCS satellite link. Results indicated that, owing to its single-‐connection architecture, SPDY is a promising solution to access the Web when using satellites. However, Also, it has reduced TCP footprints, which can interact with other important architectural components and middleboxes usually deployed in satellite service providers.

Satellite networks are critical test benches for applications and transport protocols, having transmission characteristics much different compared to terrestrial networks, for which most of Internet protocols (included SPDY) have been designed. In particular, HTTP protocol over TCP results particularly impaired over satellite links due to the high experienced latency. In fact, TCP protocol has been originally designed to efficiently support long data transfers over terrestrial links (characterized by limited delays). TCP probes available bandwidth (congestion control mechanism) by gradually increasing its transmission rate after the reception of packet ACKnowledgements (ACKs), sent by data receiver. Therefore, the rate growth relies on a Round Trip Time (RTT) basis, which is more than 0.5s over geostationary satellite links. On the other hand, HTTP transfers, which make use of TCP, are characterized by a set of relatively small objects, often carried by 2-‐3 IP packets. With HTTP/1.0 protocol, each object is managed by a separated TCP connection, while HTTP/1.1 introduces possibility to group a set of object requests into a single connection that is kept open for a given time interval. In general, small data transfers terminate before TCP achieves the maximum achievable throughput, significantly affecting overall performance.

Several mitigation solutions have been proposed in literature, which imply the change of transport protocol (connection splitting) to a more optimized one for the air interface. Some solutions are focused at transport layer (larger initial window [65], fast connection open [74], TCP proportional rate reduction [64]), new congestion control algorithms (i.e. Vegas, Laminar, Compound, Cubic [79] TCP-‐Noordwijk [10], etc.). The rationale of this approach is to speed up data transfer, which is impaired on high delay-‐latency links, with protocols allowing a faster start-‐up (e.g., larger window, or a transmission window not clocked by ACKs). In this way, especially smaller objects may be transferred in shorter time and more efficiently. Objects of this kind are typically those transferred during an HTTP session, so that the connection establishment and the initial phases are critical.

A second solution consists in a multiplexing approach, in which several TCP connections are merged together on a single one. This approach can also be combined with the previous one, so that the multiplexed connection can also use a specific “accelerated” transport protocol. Multiplexing of several connections over a single one reduces the number of the initial handshakes of TCP connections (connection establishment 3-‐way handshake), both avoiding overhead and additional RTTs. It also allows using an already established TCP connection, which at steady state may have a large window, for the transfer. At the same time this

108

technique can also reduce the workload network nodes in terms of number of TCP connection to be handled.

All these kinds of solutions (and many others) fall under the PEPs class, which is nowadays an important component of a satellite network (and typically integrated within the edge nodes of the network). PEPs employ connection splitting, so that newer and more optimized transport protocols can be used on the air interface, including features of compression, secure tunnelling, etc. which disrupt the end-‐to-‐end TCP semantic. Moreover PEPs may perform higher layer operations, such as pre-‐fetching and Deep Packet Inspection (DPI) at HTTP or TCP level.

As the SPDY protocol implements the multiplexing solution at application layer, it can introduce meaningful benefits also into a satellite network. In fact, this characteristic of SPDY is not related to the lower transport layer, or any PEP mechanism that may be implemented. SPDY peculiar mechanisms may save few round-‐trip messages to transport a web page and transmit in a more efficient way larger objects, having a noticeable effect on the transfer performance.

Differently from PEPs, SPDY does not require architectural changes in the network limiting interoperability problems. However, there are a few literature studies addressing performance analysis of the SPDY protocol over complex network scenarios, and in particular satellite ones, where it is already introduced a better performance than standard web protocols. Hence, this study aims to fill this gap with particular focus on the SPDY when used over a satellite channel. This work will emphasize benefits of exchanging data within a SPDY stream relying upon a single TCP connection (multiplexing feature), over a network characterized by high access delays. This study is a necessary initial stage, and will validate the key concepts of the SPDY protocol (standalone) over satellite, independently from lower layer optimizations.

To verify the applicability and benefit in the use of SPDY in a satellite-‐based scenario additional testing activities are required. Should the SPDY protocol underperform or present issues at this early stage, neither all the other available capabilities are usable. At the same time, this early check is a pre-‐requisite to further study and assess the integration of the SPDY protocol within the PEPs nodes and all IP-‐based functions typically present in a VSAT satellite network (Shaping, firewalling, billing per service, etc.).

6.3.1 Analysis of SPDY Multiplexing

Performed tests aim to provide an assessment of SPDY multiplexing performance over satellite links against traditional HTTP transfers [77]. The core of this study is to demonstrate classic HTTP inefficiency to manage short transfers especially when the experienced latency becomes high. On the contrary, multiplexing makes a set of short transfers into a longer transfer better exploiting TCP transfer.

Two different static HTML webpages (Page-‐A & Page-‐B) built ad-‐hoc with different number of objects have been considered. The rationale is to demonstrate that multiplexing improvement



109

grows as the number of objects increases. Then, a detailed analysis of request-‐response loops under all the target configurations together with the evaluation of the web page load time are provided.

In order to stress web request-‐response iterations, the first webpage (Page-‐A) is structured as an index.html of 24.8 Kbytes and 640 small images. The second webpage (Page-‐B) is lighter and structured as an index.html of 18.4 Kbytes and 21 small images.

Page benchmarking tool, installed on Google Chrome browser in a single user terminal (UT1), which is connected to the virtual satellite terminal (ST1) of the Satellite Network Emulation Platform (SNEP). The benchmarking tool is used to access the testing webpages described in Table 6-‐4 it is configured to close the connection and clean the browser cache before every test’s iteration in order to ensure that all page objects are requested and downloaded from the server from scratch. SPDYShark debug tool is configured to capture all the transmitted packets between the endpoints.

Page-‐A • Consists of 640 small images • Index.html 24.8 Kbytes • 640 small images totalling 333 Kbytes.

Page-‐B • Consists of 21 small images • Index.html 18.4 Kbytes • 21 small images totalling 138.5 Kbytes

TABLE 6-‐4: TESTING WEBPAGES COMPONENTS

6.3.2 Results

Page load time represents the best metric to quantify the user experience in downloading a web page. Therefore, results in Figure 6-‐16 present the average download time of the Page-‐A (blue bars) and page-‐B (red bars) for the different protocol configurations. In addition, detailed protocol performance indicators of the tests are summarized in Table 6-‐5 and Table 6-‐6.

110

FIGURE 6-‐16: WEBPAGES LOADING TIME OVER DIFFERENT PROTOCOL CONFIGURATIONS.

In case of 640 objects (Page-‐A), SPDY acceleration is much evident and provides 80% to 96% reduction in download time if compared with other protocols. The reason for such a great improvement is that SPDY drastically reduces the number of connections, efficiently exploiting multiplexing of the objects. It opens 4 connections among which only one is used for actual data transmission, while the other 3 connections are established by the browser as backup. HTTP/1.0 manages a connection for every object, while HTTPS has a number of connections equal to the double of the downloaded objects, due to the security additional procedures involved since a self-‐signed certificate is used, which has to be verified by the browser before initiating any connection. In both HTTP cases, connections carry a few bytes (only 5-‐9 packets per connection) and lasts less than 3s in average.

Under these conditions, considering satellite RTT of about 560ms, TCP manages transfers within Slow Start phase providing an actual transmission rate well below the available capacity over the current satellite systems. Note that performed simulations envisage a very large bandwidth (4 Mbit/s in both communication directions) in order to assess the nominal efficiency of the different protocol configurations.

HTTP/1.1 is able to limit to 12 the total number of connections (Chrome allows 6 persistent connections and Apache server sets a KeepAlive threshold of 5s for each connection). Then, the overall number of connections is closer to the 4 measured in the SPDY configuration. Nevertheless, SPDY still allows a better utilization of the TCP connection achieving higher throughput per connection: 312 Kbit/s against the 11 Kbit/s with HTTP1.1 for the server-‐to-‐client (S>C) transfers.

Definitively, it is possible to conclude that SPDY approach, based on multiplexing, results much better than other ones in case of a large number of objects composing the web page.



111

Page A HTTP1.0 HTTP1.1 HTTPS SPDY No. Of Connections 642 12 1291 4 Av. Duration of Data Connection (s) 1 33 2 12 Av. Throughput / Connection (C>S) bit/s 4852 5882 5626 102152

Av. Throughput / Connection (S>C) bit/s 7361 11019 4598 312335

Total Bytes Transferred 1187119 868021 2996331 613633 Av. Bytes/ Connection 1849 72335 2321 610126 Av. Bytes Transferred (C>S) 735 25102 1276 150368 Av. Bytes Transferred (S>C) 1114 47233 1045 459758 Av. Packets/ Connection(C-‐>S) 5 59 8 548 Av. Packets/Connection (S-‐>C) 5 57 6 752

TABLE 6-‐5: STATISTICS ON PAGE-‐A DOWNLOAD

In the second test with 21-‐objects page (Page-‐B), performance comparison results quite different than in the previous case. As a general comment, the lower number of objects makes multiplexing effect less significant. In fact, differences on the number of connections observed in the different configurations are shortened, but with SPDY still representing a lower bound (4 total connections irrespective from the number of objects). From Figure 6-‐16, SPDY outperforms only HTTPS, while providing a page loading time similar to HTTP/1.0. Instead, HTTP/1.1 apparently results the most efficient configuration employing only 3.7s against the 6.7s of SPDY. The rationale of such an outcome relies on the SPDY TLS session management, which takes at least 3 RTT for the initial establishment. On the other hand, SPDY provides secure communications at the cost of an initial delay. Then, a fair performance evaluation must take into account that both HTTP/1.0 and HTTP/1.1 do not provide any security to transferred data.

Page B HTTP1.0 HTTP1.1 HTTPS SPDY No. Of Connections 23 6 27 4 Av. Duration of Data Connection (s) 1 4 2 7 Av. Throughput / Connection (C>S) bit/s 5909 5745 5509 8897

Av. Throughput / Connection (S>C) bit/s 39251 53158 14549 167297

Total Bytes Transferred 175844 167930 243485 163401 Av. Bytes/ Connection 7645 27988 4870 156226 Av. Bytes Transferred (C>S) 968 31855 1280 7889 Av. Bytes Transferred (S>C) 6678 25258 3590 148337 Av. Packets/ Connection(C-‐>S) 9 19 9 58 Av. Packets/Connection (S-‐>C) 9 22 8 118

TABLE 6-‐6: STATISTICS ON PAGE-‐B DOWNLOAD

Finally, statistics of both Table 6-‐5 and Table 6-‐6 demonstrate how SPDY always allows the best throughput per connection, for both traffic directions. That is, after the initial delay for security establishment, SPDY guarantees the most efficient data transmission, since it keeps

112

alive the connection with data multiplexing reaching a close to optimal TCP window. These results are directly linked to the application protocol used (SPDY or HTTP based) and unrelated to the TCP protocol underneath which is common during all tests.

6.4 SPDY as an Alternative End-‐to-‐End Optimization Technique

Satellite communications are well suited for multicast/broadcast applications, while presenting drawbacks in supporting traditional Internet applications. In past years, research community presented a lot of proposals [57][49][56][29], at both architectural and protocol level, to make satellite networks attractive as a terrestrial ADSL alternative [17][62]. Main issues rely on difficult to allow a convenient commercial offer (cost of satellite bandwidth), need for adaptation of technologies designed for terrestrial networks and dealing with physical impairments that cause degraded performance if compared with terrestrial networks. Then, satellite networks represented a weak option to provide Internet access, requiring ad-‐hoc countermeasures. Such countermeasures in the best case led to additional costs for either service or network providers (in some cases for both), which inflate customer leases. Two complementary approaches were proposed and were developed in parallel:

Satellite Resource Optimization includes proposals of efficient resource allocations, advanced traffic shaping to limit traffic, ACM. In this case costs for the design and deployment of technology are relevant, with a low-‐lever impact on the system.

Performance optimizations – PEP architectures, including proposal of ad-‐hoc protocols, caching/pre-‐fetching, compression and other higher layer enhancement. In most cases, these optimizations require the introduction of specialized network elements and/or various protocol adaptations.

In general, efforts and investments to efficiently address all the above issues did not bring to effective solutions allowing an actual market penetration. Then, in practice, satellite continued to represent just gap filler for some specific scenarios (rural areas, oceans, deserts, aircraft, etc.), or backup solutions in case other terrestrial network become not available.

To achieve an efficient satellite Internet solution, it is necessary to propose a bandwidth per user in the same order of magnitude of terrestrial systems, while proposed price should be still kept low.

From a commercial point of view, terrestrial broadband access is provided with a contention ratio of 1:N. It means that N users share the same capacity (assuming for instance C Mbit/s). At a given time, the sum of all the capacity in use by the N users must always be less than or equal to C. Of course, in the worst case when all N users are simultaneously accessing web contents at a sustained rate, each one will only achieve C/N Mbit/s. From a statistical analysis, users do not transmit simultaneously, so that actual capacity experienced by each users is higher than C/N. ADSL system dimensioning envisages that N is kept as low as economically possible, with a general overprovision of capacity C (which is possible if considering ADSL2+ standards allowing up to 20 Mbit/s). The goal is to provide a nominal capacity C to each user (exploited for most of time), although it is actually shared among N users



113

When considering recent broadband access by satellite (i.e. Tow-‐way Ka-‐Sat platform2), although allowing a much higher throughput compared to older satellite platforms, the cost per Mbit is still much higher than in terrestrial cases. Therefore, with the aim to preserve a competitive commercial offer (compared to terrestrial ADSL), it is not possible to reduce the contention ratio below a certain threshold (to not compromise performance experienced by users) or further increase the maximum per-‐user capacity (overprovision) as in the terrestrial systems. Fixing N and C values for satellite as a cost-‐performance trade off, the only way to guarantee an acceptable Quality of Experience (QoE) is to invest on traffic control methods (in compliancy to Service Level Agreements -‐ SLAs) in order to avoid harmful effects of traffic peaks and carefully utilizing shared resources, avoiding any possible resource wasting (network underutilization). Maximization of resource utilization in the return link is usually addressed by Bandwidth on Demand (BoD) algorithms, dynamically assigning transmission slots based on actual needs. To this extent, the amount of dynamic slots used by users shall be reduced, to contain the cost of the service. For the reason, envisaged emulation platform includes DVB-‐RCS link layer, where return link time-‐slots are assigned through Demand Assignment Multiple Access (DAMA) schemes [57].

This study considers the newest SPDY protocol to perform some tests over an emulated DVB-‐RCS link [78]. The goal is to assess performance gap between satellite and terrestrial (xDSL-‐like) link. The latter aspect will allow to understand if satellite role can be reviewed for the future Internet.. In particular, test configuration focuses on the Volume Based Dynamic Capacity (VBDC) algorithm, which requests capacity on the basis of the actual bytes stored in the satellite terminal buffer, then maximizing resource utilization. SPDY performance over VBDC is then a good meter to evaluate effectiveness with respect to terrestrial systems, in particular to assess its benefit with regard to protocol timings and performance as well as the resource utilization in co-‐existence with DAMA. In additional, testing real SPDY implementation allows to evaluate if a specialized tuning of Web client/server can further increase performance over satellite.

6.4.1 Test Setup

Satellite Network Emulation Platform (SNEP), have been setup to emulate a fully star-‐based DVB-‐RCS network, or simple point-‐to-‐point xDSL links. In satellite configuration, represented in Figure 6-‐17, each virtual node emulates a single component of a typical VSAT satellite network adopting DVB-‐RCS standard, whereas for terrestrial link emulation, the satellite node is disabled.

2 Europe’s first High Throughput Satellite (Eutelsat), “http://www.eutelsat.com”

114

FIGURE 6-‐17: SNEP CONFIGURATION FOR SATELLITE EMULATION

Attached to the SNEP platform, two customized Virtual machines were configured: an Apache Web Server with SPDY/3 support and a reference Client (Chrome).

The Apache server is configured with mod_spdy 0.9.4.1, hosted by an Ubuntu 12.04 O.S., with pre-‐configured Initial TCP Window size of 10 packets. The Web page used for testing consists in a complete mirror (including dynamic content and Javascripts) of the European Space Agency (ESA) institutional home page (http://www.esa.int). This testing page represents a good reference page of a typical web portal, and it is used for all the following analysis. The main page in fact contains several heterogeneous objects as shown in the structure reported in Figure 6-‐18. The Chrome client starts downloading by sending GET request for index.html then the browser will request 2 CSS files, 9 Javascripts, 79 images, and 3 TTF font files. One Javascript file (JS1) will request 20 images interactively (AJAX) to complete the page download.

FIGURE 6-‐18: WEB TEST PAGE OBJECTS HIERARCHY

The full web page has been moved to the local server, so that specific Apache and SPDY parameters can be fine-‐tuned (in particular SPDY is not available on the real ESA web server) and controlled locally. Apache web server has a local Certificate used to establishing secure connections, which has been exported in Wireshark tool in order to inspect the traffic (together with the SPDYShark plugin used to decode the SPDY messages and inspect parameters of SPDY framing and streaming layers when SPDY is in use) and enable statistics. The server is accessed through the SNEP emulated satellite or terrestrial link.



115

Concerning the client, benchmarking extension required to measure the test performance has been included in order to support SPDY with server push. In addition, Chrome browser starts a backup connection by default after 250ms in parallel to the first established connection, to avoid the 3s required for SYN retry in case of losses. In operative satellite networks, the average actual value for RTT is always greater than 650ms, so parallel connection is erroneously established, causing some confusion in the browser behaviour. In order to solve this issue, authors rebuild the Chrome from source code with some modifications to SPDY start-‐up module and increasing parallel connection default value from 250ms to 2000ms.

Finally, the last adaptation for the testbed concerns the pre-‐connections. Chrome browser learns the websites history and the required resources (number of domains used in every website and recurrent domains) to start TCP pre-‐connections to these websites. During these tests the Chrome browser is started without pre-‐connections option, to avoid both any performance inefficiency due to unwanted connections and misuse of satellite resources.

It is possible to selected into the SNEP: i) terrestrial, ii) fixed rate satellite (satellite best-‐case scenario) and iii) on demand bandwidth satellite configurations. The detailed parameters adopted for testing are presented in Table 6-‐7, with the indication of reference set of protocols used for the first comparative tests.

Test setup Bandwidth Average RTT Protocols

ADSL Download: 4Mbit/s, Upload: 384kbit/s,

50 ms (reported as a reliable European average value [17])

HTTPS (with default options for server and client)

Satellite with Fixed bandwidth assignment

4/1 Mbit/s Forward/ Return link

660 ms Constant Rate Assignment -‐ CRA

HTTPS; HTTPS w/ pipelining; SPDY

Satellite with on demand bandwidth assignment

4/1 Mbit/s Forward/ Return link

660ms + BoD access delay for Volume-‐based requests VBDC algorithm (variable)

HTTPS; HTTPS w/ pipelining; SPDY

TABLE 6-‐7: CONFIGURATION OF SNEP FOR DIFFERENT SETUP CONSIDERED

HTTPS/1.0 is referred to the HTTPS protocol implementation without changing both the default configuration of Apache and the Web browser settings, as baseline in all test configurations. In this case (which represents the majority of practical real-‐life cases) the KeepAlive for SSL is not established.

To enhance performance over satellite, HTTP/1.1 over SSL was then introduced (HTTPS/1.1), enabling both pipelining option in the client browser and KeepAlive option in the apache server to enable HTTP – Pipelining. This optimization was proposed for satellite transfers to offer a consistent reference to compare standard HTTP with security versus a default SPDY configuration over satellite. Among all the SPDY features, default configuration envisage only multiplexing.

116

Page-‐benchmarking tool, installed on Google Chrome browser, was used to access the testing webpage described above. Benchmark tool is configured to close the connection and clean the browser cache before each run. The rationale is to ensure that all page objects are requested and downloaded from the server (Cold Loading). Each test is repeated for 50 times and results are averaged providing a single averaged value.

In a second set of tests, the focus has been on how SPDY can be further tailored to the satellite environment and if there are additional margins for improvement. To this aim, default SPDY was compared with an ad-‐hoc setup of SPDY with push (modification at server side), data compression and partial content caching (at client side and updating some objects lifetime property at server side).

6.4.2 Results

The first test concerns the initial assessment on the use of SPDY in a satellite realistic scenario, with comparison to a terrestrial ADSL reference case. The complexity of the dynamic page, and the necessity of establishing an SSL secure relation before sending data, lead to a Page Load Time (PLT) of around 7 s in the ADSL case. Performance comparison with satellite transfers relying on both HTTPS versions and SPDY is shown in Figure 6-‐19. When using HTTPS without pipelining over satellite, PLT becomes unacceptable: more than 40 s in case of a fixed bandwidth assignment (Constant Rate Assignment -‐ CRA) and more than 1 minute in case of DAMA VBDC algorithm. This outcome summarizes a performance assessment for the “old-‐style” web protocols, which makes satellite not suitable to support Internet access. To opposite, when introducing pipelining and especially with the use of SPDY, the PLT reduction is significant (as low as 13 s) and represents a very good result. In fact, considering that satellite delay is (at-‐least) ten times higher, PLT is only 2 (with CRA) or 3 (with VBDC) times higher. Performance is considered satisfactory also because part of the page is usually displayed much earlier than PLT (first paint), giving to user a good interactivity sensation, even when using VBDC. In addition, with VBDC optimization of resource utilization is achieved, which is a key improvement for reduction of bandwidth costs.



117

FIGURE 6-‐19: TERRESTRIAL VS. SATELLITE PAGE LOAD TIME

The second test run focuses on possible optimization of SPDY tailored to satellite link characteristics. Specifically, object pushing and local caching have been progressively enabled in the configuration. Such mechanisms co-‐exist with the default SPDY multiplexing behaviour (and security), which already led to good performance of first test. As far as caching is concerned, freshness lifetime has been configured for Javascript and CSS files only, to allow the browser to cache these resources in the HTTP cache disk. All other page resources including HTML and images are downloaded from the server normally. This represents a very likely case, where the user is returning the next day on the same Web portal, where the style and the main components remain the same and only part of the content is updated. Then, starting from the worst satellite case (SPDY over VBDC), Figure 6-‐20 reports performance improvements with the addition of SPDY features. PLT is reduced of about 4s by server push, selecting the page root elements of Javascript and CSS. If also local caching is enabled (which is the default clients setting) in addition to push, performance improvement becomes much more significant with an average PLT of about 12s. Finally, this latter configuration is run for comparison also over CRA (satellite with dedicated access representing the best case scenario) providing the maximum performance improvement: PLT equal to 8s, just 1s higher than result of HTTPS over terrestrial links.

118

FIGURE 6-‐20: SATELLITE SPDY OPTIMIZATIONS

To complete the analysis, a last test run provides the amount of resources required (in terms of assigned bytes) on the return link during the web page download, when VBDC is considered. The overall bytes-‐budget is presented in Figure 6-‐21. The first contribution to the return link occupation represents the amount of bytes transmitted by the browser (measured by means of the Chrome benchmarking tools) with different protocol configuration. Such a value represents the “neat” amount of bytes sent by the web server.

The second stacked value (waved blocks) represents the network level bytes, measured by Wireshark network analysis tool considering IP packets sent on the emulated modem Ethernet interface. These bytes are related to application, transport and network specific overheads. Finally the last contribution is measured at the satellite data link level and it includes effective slots assigned with VBDC including DVB-‐RCS framing overhead and possible overprovisioning of slots when sent bytes do not exactly match RCS TDMA slots capacity.



119

FIGURE 6-‐21: REDUCTION OF RETURN LINK USAGE DUE TO SPDY

Optimized SPDY allows a great reduction of resource effectively used on the satellite link at all layers, and especially at the most significant layer for the satellite operator, the link layer. In fact, requested capacity is more than 200 Kbytes lower than the about 350 Kbytes needed when running traditional HTTPS.

This study provided a performance assessment of the SPDY protocol to perform realistic web page transfers over satellite. Results show that an optimized version of SPDY, including multiplexing, compression, pushing and caching features, allow a significant reduction of the Page Load Time (PLT), while minimizing resources requested on the satellite return link. In particular, PLT is very close to the value measured when performing the same transfer over an ADSL-‐like link with standard secure protocols.

These results make broadband satellite network suitable to act as an alternative access technology in the future Internet, without the need of additional architectural block (e.g., PEPs). In addition, minimization of the used resources provides a framework to make satellite competitive also in terms of costs and users contention ratio.

120

7 CONCLUSION

Security is a paramount requirement in satellite communication. This thesis analyzed the currently available security techniques for DVB-‐RCS satellite networks. After reviewing the existing security techniques available for modern commercial wireless networks, a suitable robust security framework is proposed for security IP traffic over DVB-‐RCS networks. The proposed security framework is inspired from the robust security mechanism of IEEE802.11i WLAN. However, the special characteristics of satellite networks were considered during the design of each phase of the framework. The proposed security provides mutual authentication, data confidentiality, data integrity, reply-‐attack protection, and lightweight key exchange mechanism. In addition, it supports different network layer protocols, encapsulation protocols, and compatible with other network devices and techniques that are widely used in satellite networks, such as PEPs, NAT.

The proposed security mechanism is evaluated considering the main three aspects required: compatibility, security, and performance. For compatibility, the security framework is evaluated considering the special security requirements for satellite network. For security, a formal correctness proof of the framework is presented using Protocol Composition Logic (PCL), which demonstrated the correctness of the security framework. Third, the performance of the framework is evaluated using Omnet++ simulation platform with different realistic protocols over emulated satellite network. Finally the performance is compared to IPSec protocol, which is commonly used in satellite network.

HTTP request/response transmission mechanism is not in general efficient over satellite link because of the high RTT (half second). Actual RTT is further inflated when BoD techniques are adopted reaching up to 2 s in case of VBDC, as analyzed in section 6.2. This means that any iteration (i.e. reception of index.html) is managed in a second-‐based time scale. Such an order of magnitude is completely not compliant to web performance over terrestrial links. In addition, distribution of single web objects on different connections further increases the above harmful effect, since TCP congestion control is tailored for long data transfers, while


Conclusion

121

small transfers are managed in slow start phase strongly underutilizing available resources. HTTP/1.1 offers KeepAlive, and with pipelining options enabled in the browser (leveraging as well on the 6 parallel connections) improves performance. In fact, pipelining allows managing multiple objects over a single connection reducing TCP overhead and avoiding multiple request-‐response loops. Parallel connections, on the other hand, aim to overcome TCP slow start by arranging simultaneous transfers. The latter could cause some scalability problems depending on the network characteristics. SPDY approach aims to actually transform web transfers in a single larger data transfer, which can be more efficiently served by TCP. At the same time TCP Initial Window (IW) is properly increased in order to accelerate start up phase without affecting scalability. Based on these considerations, the following conclusions can be drawn:

• Management of a single connection improves throughput, benefits increase for higher delays. Due to its multiplexing functionalities, SPDY allows a better utilization of the available resources by replacing small object transfers to a single bulk transfer. As a consequence, data rate in only constrained by TCP (and not more by multiple HTTP request-‐response loops) and DAMA allocation control procedure can avoid to restart by 0 up on each object transfer bringing a further delay contribution. This explains the huge improvement over RBDC and VBDC algorithms.

• Parallel multiple connections help performance by saving time from sequential TCP connection establishment. This applies to traditional HTTP. This is driven by browser and server settings.

• Most of the modern websites use many different domains, and SPDY works per domain. This means SPDY can’t reduce connections or multiplex requests across the different domains.

• Discussion on the relation between browser settings and performance, selected browser greatly impacts on performance. Settings are of a paramount importance and must depend on some physical parameters. Web browsers are optimizing their default settings depending on the basic characteristics of terrestrial broadband networks, which are different than satellite networks. For a better performance, stellate network user has to change some settings in the browser.

Presented results demonstrate effectiveness of the SPDY mainly based on multiplexing. As the number of Web page objects increases, SPDY performance improvements become relevant with respect to all the past web protocol configurations. With a limited number of objects, SPDY performance is more similar to that achieved by HTTP/1.0 and HTTP/1.1 in terms of overall page load time. This is due to the initial SPDY signalling exchanges for establishing secure session (SSL protocol). Nevertheless, at the cost of a small increase of the web page load time, SPDY provides both security and a better management of TCP connections (higher throughput). Furthermore, SPDY allows also introducing additional mechanisms and

122

optimization (compression, priority, etc.), which can further enhance web applications performance and shall be investigated.

Performance Enhancing Proxies (PEPs) are designed and used. PEPs are widely deployed in present satellite networks. They have been crucial to providing acceptable performance using the traditional HTTP. To accelerate performance, PEPs operate at multiple layers influencing the lower layers (e.g. Radio Link), the transport (e.g. TCP Splitting) and applications (e.g. compression, pre-‐fetching, and http proxy). Considering SPDY, it is important to differentiate the PEP functions into Transport, Application, and Physical layers. This suggests that the need of both applications and transport PEPs could be reviewed or completely offloaded when SPDY is implemented.

123

8 BIBLIOGRAPHY

[1] A. Cardaci, L. Caviglione, A. Gotta, N. Tonellotto, “Performance Evaluation of SPDY over high Latency Satellite Channels”, PSATS 2013, LNICST 123, pp. 123-‐134, 2013, Institute for Computer Sciences, Social Informatics and Telecommunications Engineering, Springer, 2013.

[2] A. Cardaci, N. Celandroni, E. Ferro, A. Gotta, F. Davoli, L. Caviglione, “SPDY – a new Paradigm in Web Technologies: Performance Evaluation on a Satellite Link”, in Proceedings of the 19th Ka and Broadband Communications Navigation and Earth Observation Conference, Florence, Italy, FGM Events LLC 239, Oct. 2013.

[3] Aboba, B. and W. Dixon, “IPsec-‐Network Address Translation (NAT) Compatibility Requirements”, RFC 3715, March 2004.

[4] Aboba, Bernard, et al., “Extensible authentication protocol (EAP)”, RFC 3748, June 2004.

[5] Alshamsi, A.; Saito, T., “A technical comparison of IPSec and SSL” Advanced Information Networking and Applications, 2005. AINA 2005. 19th International Conference on, vol.2, no., pp.395-‐398 vol.2, 28-‐30 March 2005.

[6] Barbieri, Roberto, Danilo Bruschi, and Emilia Rosti. “Voice over IPsec: Analysis and solutions”, Computer Security Applications Conference, 2002. Proceedings. 18th Annual, pp. 261-‐270. IEEE, 2002.

[7] Bellare, Mihir, and Phillip Rogaway. “Entity authentication and key distribution” Advances in Cryptology -‐ CRYPTO’93. Springer Berlin Heidelberg, 1994.

[8] Belshe, M., Peon, R. SPDY protocol (draft 3): http://www.chromium.org/spdy/spdy-‐protocol/spdy-‐protocol-‐draft3 (Online accessed Dec. 2014)

[9] C. A. Ellis, and C. Sun, "Operational Transformation in Real-‐Time Group Editors: Issues, Algorithms, and Achievements", Proc. of ACM 1998 CSCW, pp. 59-‐68, Nov 1998, Seattle (US).

124

[10] C. Roseti, M. Luglio, F. Zampognaro, “Analysis and Performance evaluation of a burst-based TCP for Satellite DVB RCS links”, IEEE/ACM Transactions on Networking, Vol. 18, Issue 3, pp. 911-921, Jun. 2010.

[11] Caragata, Daniel, Emil Sofron, Ion Tutanescu, and S. E. Assad. "Secure IP multicast over satellite." In Electrical and Electronics Engineering (ISEEE), 2010 3rd International Symposium on, pp. 49-‐53. IEEE, 2010.

[12] Caviglione L.; Gotta A.; Abdel Salam A.; Luglio M.; Roseti C.; and Zampognaro F., “Performance Evaluation of HTTP and SPDY over a DVB-‐RCS Satellite Link with Different BoD Schemes” 6th International Conference on Personal Satellite Services 2014, 28-‐29 July 2014, Genova, Italy.

[13] Caviglione, L.: “Can satellites face trends? the case of web 2.0. In: Satellite and Space Communications”, 2009. IWSSC 2009. Int. Workshop on. (2009) 446 –450

[14] Comtech EF Data, “Streamline Encapsulation Support”, Software Release Notification, 2009.

[15] Cruickshank, H., et al. “Securing multicast in DVB-‐RCS satellite systems”, Wireless Communications, IEEE 12.5 (2005): 38-‐45.

[16] Datta, Anupam, et al. “Protocol composition logic (PCL)”, Electronic Notes in Theoretical Computer Science 172 (2007): 311-‐358.

[17] DSL-Forum, http://www.broadbandforum.org

[18] Durgin, Nancy, John Mitchell, and Dusko Pavlovic, "A compositional logic for protocol correctness. "Computer Security Foundations Workshop, IEEE. IEEE Computer Society, 2001.

[19] EBU/ETSI, “Digital Video Broadcasting (DVB); Implementation guidelines for the use of MPEG-‐2 Systems, Video and Audio in satellite, cable and terrestrial broadcasting applications”, ETR 154, Sep. 1997.

[20] ETSI, “Digital Video Broadcasting (DVB); DVB interaction channel for Cable TV distribution systems (CATV)”, ETSI ES 200 800 V1.3.1 (2001-‐10).

[21] ETSI, “Digital Video Broadcasting (DVB); DVB specification for data broadcasting” ETSI EN 301 192 V1.4.1 (2004-‐06).

[22] ETSI, “Digital Video Broadcasting (DVB); Framing structure, channel coding and modulation for 11/12 GHz satellite services”, EN 300 421 V1.1.2 (1997-‐08).

[23] ETSI, “Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE) Protocol”, ETSI EN 102 606 v. 1.1.1, Oct. 2007.

[24] ETSI, “Digital Video Broadcasting (DVB); Interaction Channel for Satellite Distribution Systems”, ETSI EN 301 790 v. 1.5.1, May. 2009.

[25] ETSI, “Digital Video Broadcasting (DVB); Second Generation DVB Interactive Satellite System (DVB-‐RCS2)” ETSI TS 101 545-‐1, V1.1.1, (2012-‐05).


Bibliography

125

[26] ETSI, “Digital Video Broadcasting (DVB); Second generation framing structure, channel coding and modulation systems for Broadcasting, Interactive Services, News Gathering and other broadband satellite applications (DVB-‐S2)”, ETSI EN 302 307, V1.2.1, (2009-‐08).

[27] ETSI, “Digital Video Broadcasting (DVB); Support for use of the DVB Scrambling Algorithm version 3 within digital broadcasting systems” DVB Document A125, Nov. 2013.

[28] F. Belli, M. Luglio, C. Roseti, and F. Zampognaro, “Evaluation of TCP performance over emulated multiple RCST DVB-‐RCS scenario”, In proc. Of Intl Workshop on Satellite and Space Communication (IWSSC), pp. 424-‐428, Sept 2009, Siena (Italy).

[29] F. Belli, M. Luglio, C. Roseti, G. Savone and F. Zampognaro, “Performance evaluation of TCP Noordwijk over satellite systems for fixed and mobile services”, 15th IEEE International Workshop on Computer Aided Modelling Analysis and Design of Communication Links and Networks (CAMAD2010), 3-‐4 Dec. 2010, Miami, Florida.

[30] Fairhurst, G. and B. Collini-‐Nocker, “Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-‐2 Transport Stream (TS)”, RFC4326, December 2005.

[31] Fette, I., and A. Melnikov. “RFC 6455: The WebSocket Protocol” IETF, December (2011).

[32] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P.,Berners-‐Lee, T., “RFC 2616, Hypertext Transfer Protocol – HTTP/1.1”, (1999).

[33] Forcier, Jeff, Paul Bissex, and Wesley Chun, “Python web development with Django”, Addison-‐Wesley Professional, 2008.

[34] Frankel, Sheila, R. Glenn, and S. Kelly, “The AES-‐CBC cipher algorithm and its use with IPSec. RFC 3602”, September, 2003.

[35] G. Rauch, “Socket.io”, open source software, MIT License, http://socket.io.

[36] G. Totsline, “Issues When Using IPSec Over Geosynchronous Satellite Links”, SANS Institute Reading Room, Ver. 1.4 August 12, 2002.

[37] Garrett, Jesse James, "Ajax: A new approach to web applications." (2005): 1-‐6.

[38] Guide, A. Pragmatic, "Agile web development with Rails." (2006).

[39] H. Cruickshank, P. Pillai, M. Noisternig, S. Iyengar, “Security Requirements for the Unidirectional Lightweight Encapsulation (ULE) Protocol”, RFC 5458, IETF, March 2009

[40] H. Cruickshank, P. Pillai, S. Iyengar. “Security Extension for Unidirectional Lightweight Encapsulation Protocol”, IETF, draft-‐cruickshank-‐ipdvb-‐sec-‐05 (expired), (2008).

126

[41] H. Kim, G. Yi, H. Lim, J. Lee, B. Bae, S. Lee, “Performance Analysis of SPDY Protocol in Wired and Mobile Networks", In Ubiquitous Information Technologies and Applications, pp. 199-‐206, Springer Berlin Heidelberg, Jan. 2014.

[42] H. Kruse, M. Allman, J. Griner, D. Tran, “Experimentation and modelling of HTTP over satellite channels", International Journal of Satellite Communications, vol. 19, no. 1, pp. 51-‐ 68, 2001.

[43] He, Changhua, et al. “A modular correctness proof of IEEE 802.11i and TLS.” Proceedings of the 12th ACM conference on Computer and communications security. ACM, 2005.

[44] http://www.symfony-project.org/ (accessed online December 2014).

[45] I. Hickson, “Server-‐Sent Events”, W3C Editor’s Draft, http://dev.w3.org/html5/eventsource/, Jan 2013, (accessed online December 2014).

[46] IEEE Standard for “Information technology-‐Telecommunications and information exchange between systems Local and metropolitan area networks-‐Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications," IEEE Std. 802.11-‐2012 (Revision of IEEE Std. 802.11-‐2007), vol., no., pp.1,2793, March 29 2012.

[47] IEEE Standard for Local and metropolitan area networks -‐ Port-‐Based Network Access Control," IEEE Std. 802.1X-‐2010 (Revision of IEEE Std. 802.1X-‐2004), vol., no., pp.C1,205, Feb. 5 2010.

[48] INET Framework. http://inet.omnetpp.org, (accessed online December 2014).

[49] Interoperable PEP (I-‐PEP) Transport Extensions and Session Framework for Satellite Communications: “Air Interface Specification”, Oct. 2005.

[50] J. Border, M. Kojo, J. Griner, G. Montenegro, “Performance Enhancing Proxies Intended to Mitigate Link-‐Related Degradations”, RFC 3135, IETF, June 2001.

[51] J. Callas, L. Donnerhacke, H. Finney, D. Shaw, and R. Thayer, “Open PGP Message Format”, RFC 4880, Nov. 2007.

[52] J. Heidemann, K. Obraczka, J. Touch, “Modelling the performance of HTTP over several transport protocols”, IEEE/ACM Transactions on Networking, Vol. 5, No. 5, pp. 616-‐630, 1997.

[53] Kent, S., and K. Seo., “Security Architecture for the Internet Protocol (RFC 4301)”, (2005).

[54] Knorr, E. Software as a Service: The Next Big Thing. http://www.infoworld.com/article/06/03/20/7610312FEsaas1.html (2009), (accessed online December 2014).

[55] M. Belshe, Twist, R. Peon, M. Thomson, A. Melnikov, “Hypertext Transfer Protocol version 2.0”, IETF, draft-‐ietf-‐httpbis-‐http2-‐01, (Jan. 2013).

[56] M. Luglio, C. Roseti, F. Zampognaro, “Analysis and Performance evaluation of a burst-‐based TCP for Satellite DVB RCS links”, IEEE/ACM Transactions on Networking, Vol. 18, Issue 3, pp. 911-‐921, Jun. 2010.


Bibliography

127

[57] M. Luglio, C. Roseti, F. Zampognaro, Performance evaluation of TCP-‐based applications over DVB-‐RCS DAMA schemes, International Journal of Satellite Communications and Networking, Volume 27 Issue 3, Pages 163–191, Published Online: 2 Mar 2009, DOI:10.1002sat.930.

[58] M. Noisternig, B. Collini-‐Nocker, P. Pillai, L. Liang, H. Cruickshank, “Transmitter and receiver processing specification for a unified ULE security extension”, IWSSC 2009.

[59] M. Noisternig, B. Collini-‐Nocker. “A lightweight security extension for the Unidirectional Lightweight Encapsulation (ULE) protocol”, IETF, draft-‐noisternig-‐ipdvb-‐ulesec-‐01, (2008).

[60] M. Noisternig, P. Pillai, H. Cruickshank. “Security Extension for Unidirectional Lightweight Encapsulation”, IETF, draft-‐noisternig-‐ipdvb-‐sec-‐ext-‐01.txt, (2009).

[61] M. Piatek, “Proposal for Stream Dependencies in SPDY”, Draft 1, https://docs.google.com/document/d/1pNj2op5Y4r1AdnsG8bapS79b11iWDCStjCNHo3AWD0g/edit , (Oct. 2012), (accessed online December 2014).

[62] M. Siekkinen, D. Collange, G. Urvoy-‐Keller, and E.W. Biersack, “Performance limitations of ADSL users: a casa study”, in proceedings of the 8th Passive and Active Measurements Conference, 2007.

[63] Marks, Roger B. “IEEE standard 802.16: a technical overview of the Wireless MAN air interface for broadband wireless access”, IEEE communications magazine (2002).

[64] N. Dukkipati, M. Mathis, Y. Cheng, M. Ghobadi, “Proportional Rate Reduction for TCP”, ACM SIGCOMM, 2011.

[65] N. Dukkipati, T. Refice, Y. Cheng et al., “An Argument for Increasing TCP's Initial Congestion Window”, ACM SIGCOMM Computer Communications Review, vol. 40 (2010), pp. 27-‐33, 2010.

[66] O. Mazahir, J. Padhye, W. Chan, R. Peon, R. Trace, S. Loreto, G. Montenegro, “HTTP 2.0 Principles for Flow Control”, IETF, draft-‐montenegro-‐httpbis-‐http2-‐fc-‐principles-‐01, (Dec. 2012).

[67] Omnet++ “www.omnetpp.org”

[68] Perez, Fabian Andre. "Security in current commercial wireless networks: A survey." School of Electrical and Computer Engineering, Purdue University West Lafayette (2004).

[69] R. Kohavi, and R. Longbotham, “Online experiments: Lessons learned”, IEEE Computer, 40(9), pp. 103-‐105, 2007.

128

[70] R. Secchi, A. Sathiaseelan, and G. Fairhurst, “Evaluating Web Traffic Performance over DVB-‐RCS2”, 4th ICST conference on Personal Satellite Services (PSATS), Mar. 2012, Bradford.

[71] R. Shirey, “Internet security glossary”, Version 2, RFC4949 (Informational), 2007.

[72] Raymond, Jean-‐Fransico, and Anton Stiglic, “Security issues in the Diffie-‐Hellman key agreement protocol”, IEEE Transactions on Information Theory 22, pp. 1-‐17, (2000).

[73] Ruben Santamarta, “A Wake-‐up Call for SATCOM Security”, Technical White Paper, IOActive, 2014.

[74] S. Radhakrishnan, Y. Cheng, J. Chu, A. Jain, B. Raghavan, “TCP Fast Open”, CoNEXT, ACM, 2011.

[75] Salam, A.A.; Luglio, M.; Roseti, C.; Zampognaro, F., “DVB-‐RCS security framework for ULE-‐based encapsulation”, Wireless Communications and Mobile Computing Conference (IWCMC), 2013 9th International, vol., no., pp.131-‐136, 1-‐5 July 2013.

[76] Salam, A.A.; Luglio, M.; Roseti, C.; Zampognaro, F., “Resource Optimization Over DVB-‐RCS Satellite Links Through the Use of SPDY” 10th International Workshop on Resource Allocation, Cooperation and Competition in Wireless Network RAWNET/WNC3 2014, 25-‐29 May 2014, Hammamet, Tunisia.

[77] Salam, A.A.; Luglio, M.; Roseti, C.; Zampognaro, F., “SPDY Multiplexing Approach on Long-‐latency Links” IEEE Wireless Communications and Networking Conference (WCNC), 2014, pp. 3492, 3497, 6-‐9 April 2014, Istanbul, Turkey.

[78] Salam, A.A.; Luglio, M.; Roseti, C.; Zampognaro, F., “SPDY over satellite: performance optimization through an end-‐to-‐end technology” 37th International Conference on Telecommunications and Signal Processing (TSP) 2014, 1-‐3 July 2014, Berlin, Germany.

[79] Sangtae Ha, Injong Rhee, and Lisong Xu, CUBIC ”A New TCP-‐Friendly High-‐Speed TCP Variant”, ACM SIGOPS Operating System Review, Volume 42, Issue 5, July 2008, pp. 64-‐74, 2008

[80] SatLabs System Recommendations, “Quality of Service Specifications”, http://www.satlabs.org.

[81] Sheffer, Y., et al. “An EAP authentication method based on the encrypted key exchange (EKE) protocol” RFC 6124, Zhou, et al. Expires January 16, 2014 [Page 78] TEAP July 2013 February 2011.[RFC6678. 2011].

[82] T. C. Hong, W. T. Chee, R. Budiarto,“A Comparison of IP Datagrams Transmission using MPE and ULE over MPEG-‐2/DVB Networks”, (ICICS 2005), 2005.

[83] T. Dierks, C. Allen, “The TLS Protocol -‐ Version1.0”, IETF RFC 2246, January 1999.

[84] T. Ylonen, C. Lonvick, “The Secure Shell (SSH) Transport Layer Protocol”, RFC 4253, Jan 2006.

[85] Van De Zande, Paul. “The Day DES Died”, SANS Institute, July (2001).


Bibliography

129

[86] W. Sun, “DVB-‐S2”, Incospec Seminar 2010, available at: http://www.incospec.com/resources/downloads/CTID2010/Files/DVB-‐S2%20at%20Incospec%20Seminar.pdf, (accessed Sept 2014).

[87] VMware, VMware vSphere Hypervisor, http://www.vmware.com/products/ vSphere-‐hypervisor/overview.html, US.

[88] Xu, Sen, and Chin-‐Tser Huang, “Attacks on PKM protocols of IEEE 802.16 and its later versions” In Wireless Communication Systems, ISWCS'06 3rd International Symposium on, pp. 185-‐189, IEEE, 2006.

end‐to‐end security and resource optimization for broadband satellite networks

Documents