FRAC: Design and Implementation of an Advertisement-based ... · FRAC: Design and Implementation of...

FRAC: Design and Implementation of an

Advertisement-based Community Network Sharing

Framework

Lakshman Swaroop Babu

A thesis submitted to the faculty of the

Virginia Polytechnic Institute and State University

in partial fulfillment of the requirements for the degree of

Master of Science

in

Computer Engineering

Yaling Yang, Chair

Yiwei T. Hou

Patrick R. Schaumont

Jeffrey H. Reed

May 16, 2013

Blacksburg, Virginia

Keywords: ad-supported Wi-Fi, public Wi-Fi, hotspots, dd-wrt.

Copyright 2013, Lakshman Swaroop Babu

FRAC: Design and Implementation of an Advertisement-based

Community Network Sharing Framework

Lakshman Swaroop Babu

(ABSTRACT)

There has been an overwhelming interest in public Wi-Fi due to the increasing number of

mobile users and a growing perception that Wi-Fi provides better connection experience at

lower costs. Moreover, end users increasingly expect Wi-Fi to be free, thereby motivating

a strong transition in leading markets to provide free-to-the-end-user Wi-Fi. Providing

free internet to the users is a challenge as potential solutions must be self-sustainable and

provide sufficient financial returns. Framework for Advertisement-based Community Wi-Fi

access, called FRAC is a self-sustainable advertisement-based community network sharing

framework which has the competence to provide significant financial returns. FRAC provides

free internet access to its users by motivating Wi-Fi access point (AP) owners to share their

internet service for benefits. FRAC builds on privately or commercially-owned, existing Wi-

Fi infrastructure. The users accessing the internet using this framework provide a strong

customer base for online marketing and advertising which provides the revenue to sustain

this framework.

This thesis describes the design and implementation of a prototype of the FRAC system. The

design of key features of the framework such as user authentication, advertisement delivery,

quality of service, messaging and security, are described, based on which an overall design of

the framework is provided. The prototype developed includes a browser extension to support

browser-based devices like laptops, netbooks and embeddable software that can be installed

on wireless routers with Linux-based dd-wrt firmware.

Acknowledgments

I am grateful to my advisor, Dr.Yaling Yang for the her continued guidance, support and

motivation throughout my academic and professional endeavors. I also thank her sincerely

for her insights, suggestions and advice which motivated me to pursue this project. I would

like to thank my project team for their inputs, support and technical help. I would like

to thank Dr.Jeffrey Reed, Dr.Patrick Schaumont and Dr.Thomas Hou for serving in my

committee and for their valuable inputs and suggestions. I would like to thank my dear

friends whose support helped me complete my graduate work and without whom life would

not have been the same. Finally, I would like to thank my parents and my brother for their

never-ending love, unmatched support, great many sacrifices and their absolute confidence

in me.

iii

Contents

1 Introduction 1

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3.1 Leading Markets and Smart Phones . . . . . . . . . . . . . . . . . . . 5

1.3.2 Low Income Communities . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3.3 Emerging Markets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4 Thesis Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Background 7

2.1 Chrome Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Online Advertising and Revenue Models . . . . . . . . . . . . . . . . . . . . 9

2.2.1 Effective Advertising . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.2 Revenue Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

iv

2.2.3 Ad Serving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3 Iptables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4 DD-WRT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.5 Cross-Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.6 Browser Plugins and Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.7 Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Related Work 14

3.1 Protocols and Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1.1 Wireless Internet Service Provider roaming (WISPr) . . . . . . . . . 15

3.1.2 Wi-Fi CERTIFIED Passpoint . . . . . . . . . . . . . . . . . . . . . . 16

3.1.3 802.1X & Extensible Authentication Protocol (EAP) . . . . . . . . . 16

3.1.4 RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1.5 Diameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2 Wi-Fi sharing solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2.1 Captive Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2.2 Hotspot management systems . . . . . . . . . . . . . . . . . . . . . . 21

3.2.3 Network access control mechanisms . . . . . . . . . . . . . . . . . . . 21

3.2.4 Wifidog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.5 Chillispot & Coovachilli . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3 Initiatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3.1 FON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

v

3.3.2 Boingo and Google, enabling free-to-the-end-user Wi-Fi . . . . . . . . 24

4 Design Requirements 26

4.1 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2 Quality Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.3 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.3.1 Basic Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.3.2 Additional Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5 Design 35

5.1 Architecture and Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.1.1 HOST AP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.1.2 CLIENT APP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.2 FRAC Design Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.2.1 JSON Unified Messaging Protocol (JUMP) . . . . . . . . . . . . . . . 37

5.2.2 CLIENT Authentication Mechanism . . . . . . . . . . . . . . . . . . 39

5.2.3 Maintaining Connectivity . . . . . . . . . . . . . . . . . . . . . . . . 40

5.2.4 Advertisement Delivery Mechanism (ADM) . . . . . . . . . . . . . . 41

5.2.5 CLIENT Isolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.2.6 Quality of Service (QoS) . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.2.7 Security and Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.2.8 Billing Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

vi

5.3 FRAC SERVER Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.4 HOST AP Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.5 Browser-based CLIENT APP Design . . . . . . . . . . . . . . . . . . . . . . 58

6 Implementation 60

6.1 CLIENT APP Implementation . . . . . . . . . . . . . . . . . . . . . . . . . 61

6.1.1 Background Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6.1.2 Extension UI/ Popup . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.1.3 Content Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.1.4 Enforcing Video Advertisements on CLIENT browser . . . . . . . . . 66

6.1.5 JavaScript Obfuscator . . . . . . . . . . . . . . . . . . . . . . . . . . 68

6.2 HOST AP Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

6.2.1 Implementation Features . . . . . . . . . . . . . . . . . . . . . . . . . 69

6.2.2 Router compatibility with dd-wrt . . . . . . . . . . . . . . . . . . . . 69

6.2.3 Cross Compiling & MIPSEL architecture . . . . . . . . . . . . . . . . 69

6.2.4 LibHTTPD Web-Server API . . . . . . . . . . . . . . . . . . . . . . . 70

6.2.5 Implementing JUMP using JSON-C . . . . . . . . . . . . . . . . . . . 70

6.2.6 Wifidog Iptables API and Utility functions . . . . . . . . . . . . . . . 70

6.2.7 HTTPClient Web-Client API . . . . . . . . . . . . . . . . . . . . . . 71

7 Evaluation 72

7.1 Model Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

vii

7.2 Design Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

7.3 Implementation Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

8 Future Work 78

8.1 Future Work on FRAC Prototype Software . . . . . . . . . . . . . . . . . . . 78

8.2 App-based CLIENT APP Design . . . . . . . . . . . . . . . . . . . . . . . . 78

8.3 Plugins: NPAPI vs. NativeClient (NaCl) . . . . . . . . . . . . . . . . . . . . 79

8.4 Automatic Network Discovery and Selection . . . . . . . . . . . . . . . . . . 81

8.5 From Prototype Software to Production Software . . . . . . . . . . . . . . . 81

8.6 Effective Advertising . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

9 Conclusion 83

Bibliography 84

Appendix 89

A JSON Unified Messaging Protocol 89

viii

List of Figures

1.1 FRAC Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Chrome extension architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1 802.1X Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2 RADIUS Authentication and Authorization Flow . . . . . . . . . . . . . . . 19

3.3 Wifidog Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.1 CLIENT Authentication Mechanism . . . . . . . . . . . . . . . . . . . . . . 40

5.2 Video Advertisement Delivery Mechanism . . . . . . . . . . . . . . . . . . . 42

5.3 Banner Advertisement Delivery Mechanism . . . . . . . . . . . . . . . . . . . 43

5.4 CLIENT Expiry Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.5 CLIENT Initiation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.6 Initial Router Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.7 Modified Router Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.8 Proposed QoS Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.9 FRAC SERVER design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

ix

5.10 CLIENT database example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.11 HOST database example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.12 HOST AP design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.13 Browser-based CLIENT APP design . . . . . . . . . . . . . . . . . . . . . . 58

6.1 Working screen showing CLIENT APP with an video advertisement published

on the Chrome browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6.2 CLIENT APP: Popup-based User Interface . . . . . . . . . . . . . . . . . . . 65

6.3 Current Tab Video Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

8.1 Oveview of an App-based CLIENT APP design . . . . . . . . . . . . . . . . 79

8.2 Native Client Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

x

Chapter 1

Introduction

1.1 Motivation

Overwhelming interest in public Wi-Fi has created a global trend which has led to the

proliferation of public hotspots, community and municipal Wi-Fi deployments. The telecom

industry has become more bullish about investments into public Wi-Fi in recent times.

According to the survey conducted recently by Wireless Broadband Alliance (WBA) and

Informa Telecom & Media[1], around 43% of the telecom companies are positively open to

investments into public Wi-Fi. Furthermore, 18 of the world’s largest 20 telecom companies

have recently announced new initiatives to deploy their own Wi-Fi hotspot networks.

The accelerated momentum and support for public Wi-Fi can be attributed to the following

reasons. There is a whole new world of Wi-Fi enabled devices which include smartphones,

tablets, e-readers and consoles in the market today. This has created a significant impact

on the Wi-Fi usage behavior due to an increasing perception that Wi-Fi typically provides

better connection experience at much lower costs than mobile broadband services. The

number of mobile users using Wi-Fi has increased over the years. For example, ChinaMobile

saw an increase of Wi-Fi traffic by 102.5% year-on-year in H1 2012[1].

1

Lakshman Swaroop Babu Chapter 1. Introduction 2

This has led to drastic increase in Wi-Fi hotspots and public Wi-Fi deployments in major

cities and towns. Apart from these improvements, end users increasingly expect Wi-Fi to

be a free service. There has been a strong transition to provide free-to-the-end user Wi-Fi

in leading markets. Though these trends vary over different regions and markets, there is a

definite diminishing willingness to pay for Wi-Fi access.

Deploying public Wi-Fi networks and hotspots requires significant capital investment to

cover the cost of installation, operations, maintenance and service. Local governments, mu-

nicipalities, other organizations and companies which sponsor these Wi-Fi deployments are

pursuing various solutions to generate additional revenue to shape long-term sustainability

and maintenance of these networks.[2]

The problem we are trying to solve is to provide free public Wi-Fi to users while trying

to break-even on initial investments and operation costs for public Wi-Fi networks. In this

work, we propose an advertisement based public Wi-Fi framework called FRAC, to create a

self-sustainable public Wi-Fi network which provides free internet access to its users and has

the competence to provide significant financial returns. We take advantage of existing Wi-Fi

infrastructure such as wireless routers with internet service subscription, which are privately

or commercially owned. These internet access subscribers become part of our framework and

provide network access for free public use by sharing their excess bandwidth in exchange for

compensation. The users accessing the internet build a strong customer base for online

marketing and advertising through our framework.

1.2 Overview

FRAC is elaborated as “Framework for Advertisement-based Community Wi-Fi access”.

The key elements in our framework include CLIENTs, HOSTs and ADVERTISERs and the

INTERMEDIARY.


Internet

HOST AP

HTTP

SERVER

HTTP

CLIENT

HOST AP HOST AP

CLIENT_APP CLIENT_APP CLIENT_APP

FRAC_SERVER

DB

DB server

AD server

Web Server

AP Firewall Router

Background

UI Popup

Content Script

AD

Displayed

Browser

Figure 1.1: FRAC Overview

CLIENT represents anyone who is interested to access free internet through our framework.

These clients connect to the host’s wireless access points via software portals installed on the

client. HOSTs represent subscribers who have internet access services from internet service

providers (ISPs) or other sources and are willing to share their excess internet bandwidth

with CLIENTs. We provide suitable compensations for the HOSTs in exchange for publish-

ing advertisements or other messages to the CLIENTs during their Internet access period.

ADVERTISERS represent any party interested to advertise, promote, send messages, get

consumer opinions or create an awareness about any product, service or feature using the

FRAC network. They buy advertising space on the framework to reach a captive audience

and they are the sponsors of the system. The organization which essentially coordinates be-


tween HOSTs, CLIENTs and ADVERTISERs in this framework is the INTERMEDIARY.

The main source of the revenue comes from developing creative high value advertisement

models and promotion schemes, planning and management of the advertisement delivery

process which is handled by the INTERMEDIARY.

The elements in FRAC have to communicate with each other in a reliable manner for the

system to function. Standardized design and implementation is critical for this system to

scale and support more CLIENTs and HOSTs, and to address problems and concerns in this

framework which forms the basis of this work.

INTERMEDIARY uses a set of servers to perform its functions, we refer to these set of

servers as FRAC SERVER. CLIENTs/CLIENT device communicates with other elements

in the framework using a CLIENT APPLICATION (CLIENT APP) on the device (such as

smartphones, laptops). HOSTs install software on their wireless routers which enable them to

be a part of FRAC, these modified HOSTs devices are referred to as HOST APs in the frame-

work. ADVERTISERs publish their advertisements and promotions on the FRAC SERVER

which is delivered to the CLIENTs through the HOST APs. Figure 1 illustrates an overview

of this framework and how advertisements are delivered to the CLIENTs.

The impact of our framework is three fold which makes it self-sustainable:

• Providing free Internet access to CLIENTs.

• Providing benefits to HOSTs to share their superfluous internet bandwidth and deliver

advertisements to the CLIENTs.

• Providing an effective medium for online marketing and advertising for potential AD-

VERTISERs who pay for advertising space on our framework.


1.3 Use Cases

In this section, we discuss some of the potential use cases for our proposed model.

1.3.1 Leading Markets and Smart Phones

Wi-Fi has become the primary form of connectivity for smartphone users globally. Based on

a recent survey conducted by Informa and mobidia [3][4], Wi-Fi accounts for around two-

thirds of the smart-phone originated data traffic globally. This provides a wide user base to

deploy our model in leading markets around the globe.

1.3.2 Low Income Communities

There have been many government and private efforts to provide internet globally as a

basic utility service to low income communities to improve their standard of living. But

these efforts lack self-sustainability and require significant capital investments and continued

financial requirements for day-to-day operations. This framework provides a self-sustainable

way which motivates subscribers to share their excess internet bandwidth with low income

groups.

1.3.3 Emerging Markets

In emerging markets like India, China and Brazil where customers are typically price sensi-

tive, Wi-Fi is the technology of choice for most users due to better connection experience at

lower costs. Our approach has immense potential as it reduces the initial deployment costs,

builds on existing infrastructure, offers free Wi-Fi service to users and offsets internet costs

for subscribers.


1.4 Thesis Organization

The rest of this thesis is organized as follows. Chapter 2 presents the background concepts

and theory. Chrome extension architecture, online advertising and revenue models, iptables,

DD-WRT firmware, cross-compilers and web services are elaborated. Chapter 3 discusses the

related work on Wi-Fi Sharing Solutions, Protocols and Standards and Initiatives. Chapter

4 defines a broad outline of the FRAC system based on which we formulate the important

functions and quality requirements to be considered in the FRAC design. Chapter 5 examines

the design of the main features in the FRAC system based on which the overall design of key

elements are provided. Chapter 6 presents the implementation of the prototype version of

the FRAC system. Chapter 7 provides an evaluation the FRAC system model, design and

implementation. Chapter 8 discusses the future work and enhancements to our model and

design. Chapter 9 concludes the thesis.

Chapter 2

Background

2.1 Chrome Extension

Chrome extensions are browser extensions, which are small software programs written in

HTML, JavaScript and Cascading Style Sheets (CSS) along with Chrome Application pro-

gramming interface (API) to enhance the functionality of the Chrome browser[5]. Extensions

are provided with Chrome APIs which provide tight browser integration. Further, they can

also use other standard web APIs such as JavaScript, Asynchronous JavaScript (AJAX),

JavaScript Object Notation (JSON). AJAX provides a way to exchange data with a server,

and update parts of a web page without reloading the whole page.

Extensions can interact with other web pages using content scripts. They can send cross-

origin AJAX HTTP requests to remote servers outside its origin whereas web pages are

limited to the same origin policy. They interact with browser features, detect browser events

and have an User Interface (UI). Each extension consists of a packaged folder which contains

a manifest file, HTML, CSS and JavaScript files and other required files such as image files.

7

Lakshman Swaroop Babu Chapter 2. Background 8

2.1.1 Manifest

The manifest file provides information about the extension such as version, name, type,

scripts and security policies. It describes how the extension is wired.

2.1.2 Architecture

Chrome extensions have a two layered structure. It has a background page which holds

the main logic of the extension. It can also contain other pages to support other functions

such as extension UI and content scripts. The background page can be persistent/always

open or event based. The UI pages are ordinary HTML pages, displayed in a popup or

a webpage. The views in UI are stateless and communicate with the background page to

retrieve information which is then displayed. Content scripts allow extensions to interact

with webpages, they are basically JavaScript code which are a part of every loaded page on

the browser and they execute on the context of the webpage. They can communicate with

the extension and load/inject scripts, data onto the webpage on the Chrome browser. Pages

within the extension can communicate easily by making direct function calls to each other

as they all execute in the same process. Chrome extensions allow easy storage of data using

web storage API such as localStorage and sessionStorage[5].


Background Page

(background.html)

Popup/

Extension UI

UI/Popup.html

Content Script

(contentscript.js)

Figure 2.1: Chrome extension architecture

2.2 Online Advertising and Revenue Models

Online advertising is a rapidly growing industry which involves marketing, promoting prod-

ucts and services over the internet. The information and content published has many flexi-

bilities which include animations, dynamically mutable, location-based, behavioral-targeted,

user-interaction and it is not limited by location or time which has led to many different

types of online advertising.

2.2.1 Effective Advertising

We focus only on a few types of online advertising which include display advertising, video

marketing and interactive advertising which are related to this work. Display advertising

mainly consists of text, logos, and photographs such as banner ads and rich media ads.

Video marketing specializes in creating videos which influence user’s decision on a product.


Interactive advertising is an emerging market which uses creative ideas and interactive media

to communicate with consumers and promote brands, services. According to the Internet

Advertising Bureau (IAB), display-based advertising is still quite popular and dominates

the advertisement industry which includes banner ads and video ads [9]. Further, IAB

also reports a tremendous growth in mobile advertising in the United States indicating the

emerging advertising market in smartphones, tablets and other smart devices.

Advertisement formats, size and placement play an important role in making advertisements

effective. Popular advertisement formats include floating ads, pop-ups, frame-based ads[10]

.

2.2.2 Revenue Models

Revenue models describe how businesses make money by online advertising. The common

pricing models in display advertising and video marketing include Cost per Mille (CPM),

Cost per View (CPV), Cost per Click (CPC), Cost per Action (CPA) and effective CPM.

CPM is the cost per thousand impressions or loads of an advertisement. CPM is a popular

and effective pricing model for video ads, as advertisers pay for exposure of their message

to a specific audience. CPV is the cost for each unique user view of an advertisement. CPC

represents the cost when a user clicks on an advertisement and is redirected to the advertiser’s

website[11]. CPA is performance-based and advertisers only pay for the number of users

who complete a transaction. IAB’s revenue report for HY2012 indicates that performance-

based pricing models such as CPC, CPA are preferred revenue models [9] but there is still

a substantial market for impression-based pricing models such as CPM. Further, IAB also

points out that hybrid pricing models have diminished in popularity. This provides an

overview of the trends in the online advertising industry.


2.2.3 Ad Serving

The technology and services involved in serving, counting and choosing advertisements for

optimizing profits and evaluating the progress of advertisement campaigns constitute ad

serving. An ad server is typically a web server which is responsible for performing these

functions. The content of the ad server is updated constantly to dynamically serve new

advertisements. Multiple publishers upload their advertisements to this central ad server

and they can track the distribution of their advertisements across the web.

2.3 Iptables

Linux systems have a host based firewall called Netfilter. The management of this Linux

firewall is controlled using the iptables program, which handles packet filtering rules that

can be enforced or removed from the Firewall. Iptables is used to set up, maintain and

inspect the firewall, and provide packet filtering and network address translation (NAT) for

the Linux kernel. It can perform stateful packet inspection, filter packets based on MAC

address (media access control), provides system logging features and rate-limiting features

at improved speed and reliability. Iptables are used to handle IPv4 packet filtering and

ip6tables are used for IPv6 packet filtering.[7][6]

All the packets are inspected by iptables and pass through a set of queues or tables. Several

tables can be defined to control certain types of packets. Each of these tables contains a set

of built-in or user defined chains or rules which match a set of packets. These tables and

associated chains process the packet as per the rules specified.

iptables -A INPUT -s 0/0 -i eth0 -d 192.168.1.1 -p TCP -j ACCEPT

This iptables command allows the firewall to accept TCP packets from any IP address to IP

address 192.168.1.1 coming into interface eth0.


iptables -A INPUT -s 0/0 -i eth0 -d 192.168.1.1 -p TCP -j DROP

Similarly for the next command, the same set of packets are the dropped at eth0.

2.4 DD-WRT

DD-WRT is a Linux-based open source firmware compatible with a great variety of wireless

routers and embedded devices [14]. DD-WRT is one among the most popular third party

firmware projects which can replace pre-installed firmware on many commercial routers in the

market. It provides easy handling and several features such as IPv6 support, advanced QoS,

RADIUS authentication, VLAN support, daemon-based services, etc. within the framework

of the hardware platform used. DD-WRT allows us to customize the home router. Since it

is Linux-based, additional enhancements can be added using programs and scripts to extend

the functionality.

2.5 Cross-Compiler

A compiler is a software program that transforms source code into object code or binary,

and is executable. Compiler runs of a specific platform which is referred to as the HOST

platform, the platform on which the executable or binary file generated by the compiler runs

on is called TARGET platform. A native compiler runs on a platform and produces a binary

that can run on the same platform, i.e. HOST and TARGET are the same. When the HOST

and TARGET platforms are different, then the compiler is a cross-compiler[13].

Cross-compiling is used if the TARGET platform has very limited resources and cannot

install a native compiler or if the native compiler for that TARGET machine has limited

packages and features. In this work, MISPEL cross-compiler (MIPS architecture in little-

Endian format) is cross-compiled on x86 platform [12] to run software on routers.


2.6 Browser Plugins and Extensions

Plugins add new features to an existing software application. Common browser plugins

include Adobe Flash Player, Quick Time Player, Java. These plugins allow third parties to

extend their software support to web browsers. Extensions on the other hand, extend the

functionality of the browser. Each browser has its own architecture and APIs to develop

the extension and as such extensions are specific to browsers. For example, they can modify

the browser UI, process loaded webpages on the browser or even change data on the page,

etc. There are development frameworks which can build cross-browser extensions but the

APIs provided may not provide all the flexibilities that a particular browser-specific API can

provide.

2.7 Web Services

A web service is a method of interaction between web-enabled devices over the internet. The

two main web service interaction paradigms are Simple Object Access Protocol (SOAP) and

Representational State Transfer (REST) based on which many web services are implemented.

SOAP provides a framework for exchanging structured information and uses XML for its mes-

sage format. It suggests a communication-oriented model. SOAP provides versatile trans-

port protocol support but is considerably slower as it uses the verbose Extensible Markup

Language (XML) format. REST is predominantly used for implementing web services and

follows a resource-oriented model. REST uses a client-server model via standardized HTTP

interface.[8]

Chapter 3

Related Work

In this section, we discuss the related work on Wi-Fi sharing in recent years. Wi-Fi hotspots

are the most common form of sharing internet access today. A typical hotspot offers internet

access over a wireless local area network using a router with internet subscription. This

typical configuration is set up in many households today but are used for only residential

purposes. There are many solutions, standards and initiatives which extend the concept of

a hotspot to provide service for a much larger user base.

The related work can be broadly classified into three sections, Wi-Fi Sharing Solutions,

Protocols & Standards and Initiatives.

3.1 Protocols and Standards

We will discuss various standards and protocols that are related to Wi-Fi sharing which

include WISPr, Hotspot2.0, 802.1X, and authentication protocols like RADIUS, Diameter,

EAP.

14

Lakshman Swaroop Babu Chapter 3. Related Work 15

3.1.1 Wireless Internet Service Provider roaming (WISPr)

Since it is difficult for a single internet service provider to build infrastructure that offers

global access to its subscribers, roaming between service providers is necessary to provide

global internet access to all the users. Wireless Internet Service Provider roaming (WISPr) is

a draft protocol submitted to the Wi-Fi Alliance that allows users to roam between wireless

ISPs by facilitating inter-network and inter-operator roaming. This allows Wi-Fi enabled

devices to roam into public Wi-Fi hotspots for internet access and services.

WISPr recommends the use of a browser-based Universal Access Method (UAM) which

allows a subscriber to access the network only with a Wi-Fi network interface and web

browser on the user device, and does not require any client software on the subscriber

device. This ensures compatibility for all Wi-Fi products. WISPr also recommends the

use of RADIUS as the recommended backend AAA protocol to support the requirements

of WISPr. Although the WISPr specification is no longer available from the Wi-Fi alliance

and was not really a standard or protocol, the UAM protocol is widely used to access public

IEEE 802.11 Wi-Fi networks.

Recently, the Wireless Broadband Alliance (WBA) released WISPr 2.0 which further en-

hances and corrects the inter-working problems with WISPr 1.0 [15]. The scope of WISPr

2.0 is limited to specification of client software to public WLAN interface. WISPr 2.0 recom-

mendations are a front end to authentication protocols such as Radius and Diameter. WISPr

2.0 requires IP communication with the gateway prior to authentication. WISPr 2.0 extends

support to EAP authentication. It is implemented using a client software and uses a mix

of secure and unsecure HTTP transactions. WISPr transactions are always initiated by the

client software which passes parameters to the access gateway through the parameters of a

HTTP Request. The access gateway responds to these requests by passing XML parameters

in the HTTP response.

Although FRAC design considers certain recommendations from WISPr such as planned

use of a mix of secure and unsecure HTTP control messages, using attribute-value pairs


for messaging but has major design differences as it is not a typical public Wi-Fi network.

FRAC uses RADIUS for authentication, JSON for messaging rather that XML and a client

software to communicate with other elements rather than a browser-based UAM.

3.1.2 Wi-Fi CERTIFIED Passpoint

Wi-Fi certified Passpoint (or) Hotspot 2.0 was developed to address the requirements for

seamless Wi-Fi access in public hotspots and to improve the user experience. A certi-

fied device manages the network association, authentication, sign-up and security in the

background, completely transparent to the user. This includes features like automatic net-

work discovery and selection, seamless network access with EAP authentication, and WPA2-

Enterprise security. Passpoint empowers service providers to fully leverage Wi-Fi ubiquity

in client devices, and offer a more compelling service to the customers. Typically subscribers

have to search and connect to a public hotspot, request connection and enter authentication

credentials every time they connect to a hotspot. Wi-Fi certified passpoint devices provide

features such as automatic network discovery and selection to connect to FRAC Hotspots

or HOST APs without the need to manually search and connect to a HOST AP.

3.1.3 802.1X & Extensible Authentication Protocol (EAP)

802.1X is the IEEE standard for port-based network access control. It provides a mech-

anism to verify network credentials and restrict access to services offered by the LAN to

authenticated and authorized users. 802.1X was defined originally for wired networks but

was adopted to wireless LANs to address the security concerns because of its robust security

framework, authentication mechanisms and data privacy capabilities. 802.1X operates at the

data link layer. It is capable of providing secure exchange of user credentials and prevents

unauthorized network access since the authentication is completed before the IP address is

assigned.[18]


The authentication mechanism involves three parties - supplicant, authenticator and authen-

tication server. The supplicant represents the software on the user device that implements

the client side of 802.1X, and requests access to the network. The authenticator is typically

a network device and the authentication server runs software supporting RADIUS and EAP

protocols. The supplicant provides credentials to the authenticator which is the access gate-

way. The authenticator sends these credentials to the authentication server for validation

and the authenticator allows supplicants only if their user credentials are verified. To ensure

the secure passing and validation of data/credentials and to simplify creation and mainte-

nance of additional authentication methods, EAP was created. 802.1X works in conjunction

with EAP.

Supplicant

EAP

2

RADIUS/DIAMETER

Internet or Other LAN Resources

3

Authenticator Authentication Server

Figure 3.1: 802.1X Authentication

EAP is an authentication framework, mainly designed for use in network access authentica-

tion where the IP layer may not be available. It provides reliable transport for authentication

protocols using different EAP methods. It only supports a single packet in flight and cannot

support bulk data like TCP. EAP uses server initiated authentication mechanism, which

adds additional messages per authentication process. Once an EAP method has been se-

lected, both the supplicant and authentication server must communicate using this EAP

method. EAP messages are transported between the supplicant and the authenticator over

a layer 2 authentication protocol specified by 802.1X - EAP over LAN (EAPoL).


EAPoL is an encapsulated form of EAP that prefixes an Ethernet header onto EAP messages

so that they can be transmitted over an Ethernet network directly by a LAN media access

control (MAC) service between the supplicant and authenticator. The authenticator com-

municates with the authentication server, which understands RADIUS messages via EAP in

RADIUS. This is a Layer 3 transmission which provides a secure channel for authentication

messages and port authorization between the authenticator and authentication server.[17]

EAP provides improved security through layer 2 authentication, but since FRAC is a public

Wi-Fi system offering free Wi-Fi using EAP might be an overkill. Every user would have to

configure 802.1X login settings which creates a support issue for the owner. Additionally, the

hotspot owner would have to setup an authentication server to provide 802.1X capability.

Further, EAP uses a server initiated authentication mechanism which increases message

overhead.

3.1.4 RADIUS

Remote Authentication Dial-In User Service (RADIUS) is a widely deployed networking

protocol that enables centralized authentication, authorization and accounting (AAA) man-

agement for network access [19][20]. AAA refers to a security architecture to enable control

over access to services and resources in the network. Two protocols which provide this

functionality are RADIUS and Diameter.

RADIUS is used to manage access to the internet or internal networks. It is supported

by VPNs, wireless access points, Ethernet switches and other network access types. It is

a client/server protocol running on the application layer and uses UDP as the transport

protocol.

Typically a network access server like dial-up server, VPN server, or wireless access point,

operates as a RADIUS client which sends the user credentials, connection parameters and

accounting messages to the RADIUS server. The RADIUS server is responsible for authen-


ticating users before allowing access to the network [19], authorizing those users for certain

network services and accounting their use of these services. Data is exchanged by using

RADIUS messages which consists of a RADIUS header and RADIUS attributes.

texttext

RADIUS Client RADIUS Server

RADIUS: Access-Request

RADIUS: Access-Accept

OR

RADIUS: Access-Reject

RADIUS: Access-ChallengeOR

Figure 3.2: RADIUS Authentication and Authorization Flow

Apart from many inherent drawbacks in RADIUS [21], there are fundamental difference

between features offered by RADIUS and FRAC requirements, which makes RADIUS an

unlikely choice for our framework. RADIUS provides AAA only between two nodes, the

gateway which has a RADIUS client component and communicates with the RADIUS server,

whereas FRAC system has three nodes involved in the system. The notion of accounting in

FRAC is different from accounting in RADIUS. RADIUS measures network usage in terms

of time and bandwidth whereas FRAC provides its CLIENTs free Wi-Fi and accounts on

online advertisements delivered, clicked or viewed.

3.1.5 Diameter

The emergence of new access technologies like mobile IP and the increased complexity and

density of network access servers have led to new demands on AAA protocols, which RADIUS

cannot handle. The Diameter protocol is defined to address the drawbacks of the RADIUS

protocol and provide additional features. Main feature additions of the Diameter protocol


include using TCP as the transport layer protocol, using IPSEC or TLS for transport layer

security, transition support for RADIUS, attribute-value pairs and 32 bit identifiers, better

roaming support, client-server protocol and extensible support and use of EAP.[22]

Diameter not only addresses these new demands but also adds many other features which

makes it much more sophisticated than the RADIUS protocol. Due to this Diameter is

complex to implement and may consume relatively high authentication overhead. Secu-

rity requirements for FRAC are much lighter compared to the security features offered by

Diameter.

3.2 Wi-Fi sharing solutions

The common Wi-Fi sharing solutions include commercial hotspots, free access hotspots, com-

munity and municipal Wi-Fi networks. All these solutions extend the concept of a hotspot.

The enabler-technologies and solutions include Captive portals, hotspot management sys-

tems and network access control.

3.2.1 Captive Portal

These captive portals force an HTTP client on a network to see a special web page for

authentication and billing purposes before internet access is granted. The user is denied

access first by intercepting or dropping all the packets from any unregistered user and instead

the user’s browser is redirected to a web page which requires authentication details, billing

information or agreeing upon an acceptable use policy. Captive portals are used in many

places like business centers, airports, shops and other venues that offer Wi-Fi hotspot service

to users.


3.2.2 Hotspot management systems

Wi-Fi hotspots are controlled using hotspot management systems which run on the router

or an external computer. Their functions include client authentication, bandwidth hogging,

billing systems.

3.2.3 Network access control mechanisms

Network access control solutions typically uses a set of protocols and policies which control

secure access to a network.

There are many software solutions which implement captive portals, hotspot management

and network access control together or separately which are used in open and commer-

cial wireless networks. Some of the common open-source solutions include ChilliSpot[23],

Wilmagate[24], Wifidog[25], PacketFence[26], NoCat, CoovaChilli[27], pfsense[28], m0n0wall

[29], EasyHotSpot[30], etc. We will discuss a few solutions that are relevant to our proposed

model.

3.2.4 Wifidog

The Wifidog captive portal suite is a complete and embeddable open source captive por-

tal solution to operate a hotspot or a network of hotspots. Its design includes features

such as optional centralized access control, full bandwidth accounting, authentication and

authorization, heartbeat messages and local content specific to the hotspot.[25]

The Wifidog suite consists of two parts, authentication server and gateway. Wifidog gateway

was developed using C which can be included easily into embedded systems like routers,

APs and it can run on any Linux platform even though it was specifically designed for

Linksys WRT54G. The gateway is responsible for dynamically allowing or denying access to

users. The authentication server (Auth Server) is coded in hypertext preprocessor (PHP)


and uses a backend user database. It is responsible for all administrative functions and

user authentication. The database stores the current user data and accounting information.

Whenever users send requests to the gateway, it forwards the data to the authentication

server and waits for further instructions.

text texttext text

AUTH SERVER GATEWAY CLIENT

Validation of ID status

Success page

Initial Web Request

Redirect Request

Request to Auth

Auth Form

User name & Pass

Redirect request to GW

Request with ID to GW

Redirect to successStatus Response

GET for success page

Figure 3.3: Wifidog Flow Diagram

Figure 3.3 shows the authentication flow used in Wifidog. Initial requests from the client0 are

redirected to a local port on the gateway, which allows the client to contact the authentication

server where the client provides user credentials. Once the client has been successfully

authenticated, it is redirected to the gateway with an authentication token. The gateway

validates the token by requesting a confirmation from the authentication server for the token.

Once successful, gateway sends a redirect to the client which obtains the success page from

the authentication server.


3.2.5 Chillispot & Coovachilli

Chillispot is also an open source captive portal and a WLAN access point controller [23].

It used a web based login mechanism for authenticating users. It uses the RADIUS server

for authentication, authorization and accounting. It supports two different access methods:

UAM and Wireless Protected Access(WPA). Chillispot is WISPr compliant. Coovachilli is

based on the Chillispot project (now defunct). It is also a software access controller and

uses RADIUS protocol or simply HTTP protocol for access provisioning and accounting.

Coovachilli is installed on OpenWrt firmware specialized for hotspots called CoovaAP and

supports WISPr 2.0. [27]

Though the basic requirements and functions of these Wi-Fi sharing solutions differ from

FRAC, there is a lot in common with respect to authentication and access control policy,

implementation environment and design limitations. The architecture and technology from

these software solutions have influenced some aspects of design and implementation of the

FRAC system. We also utilize APIs from the Wifidog project in the FRAC HOST AP

software implementation.

3.3 Initiatives

3.3.1 FON

Fon (Fon Wireless Ltd.) [31] is a company that provides a global Wi-Fi network by allowing

members to share their Wi-Fi with other members in the FON community. To be a member

of the FON community, the user must have a Fon Wi-Fi router (called La Fonera) or must

have a router with Fon firmware (ie. Create a Fon Spot). This router will have two separate

Wi-Fi signals one for the host, and one shared signal for other members and visitors. This

enables the host to share their Wi-Fi and, in exchange, allow them to connect to other Fon

Spots.


There are three types of FON users:

• Linuses share their Wi-Fi for free using a FON social router and they can access Wi-Fi

from other Fon spots without any charge in return.

• Bills profit from hosting Fon spots which are using by aliens. They get revenue from

those who purchase FON passes through that Fon spot. Fon provides tools to customize

the splash pages for user sign-in.

• Aliens is any user who wishes to access Wi-Fi from Fon spots but are not FON members.

They typically pay for the service by purchasing passes.

Initial deployments of FON were custom firmware based on OpenWrt for certain compatible

routers (Linksys) and used Chillispot (now CoovaChilli) for authentication without Wi-Fi

encryption and bandwidth-throttling features. FON has developed its commercial line of

Fon routers, La Fonera which still use OpenWrt base as firmware, which provide customized

features to support the Fon network. Further, FON has agreements with leading broadband

providers and ISPs like BT, SFR Softbank, and MTS which allows users to share their excess

bandwidth without breaching user’s terms of service.

FON will be competing with popular wireless router manufacturers provides new product

features based on new wireless standards for market share. Further, users have to buy new

FON equipment to be a part of the FON community, which requires high initial investments.

As we discussed earlier, market is transitioning to free-to-the-end user Wi-Fi, this will reduce

the revenues from FON spots. On the other hand, FRAC provides free-to-end-user Wi-Fi to

users leveraging existing infrastructure.

3.3.2 Boingo and Google, enabling free-to-the-end-user Wi-Fi

Public Wi-Fi deployments have expanded into many venues to support the proliferation

of mobile devices. As such the user’s expectations increasingly skew towards free-to-the-


end-user public Wi-Fi. Wi-Fi has been a key enabler of services beyond internet access.

Sponsored Wi-Fi benefits all the parties involved, consumers get free Wi-Fi, advertisers

reach a captive audience and venue owners improve revenue at the cost of providing Wi-Fi.

Google has recently teamed up with Boingo Wireless to provide free-to-the-end-user Wi-

Fi in New York City subway stations and Wi-Fi hotzones [1]. Google sponsored for free

Wi-Fi service during the summer of 2012, providing a suitable brand-awareness campaign

for Google. Boingo’s model is a sponsor-driven initiative, where the Wi-Fi is sponsored by

companies for brand-awareness to target subways riders at popular stations who represent a

high class customer base. This model is not self-sustainable, as costs involved in sponsoring

Wi-Fi are quite high compared to the overall benefits for the sponsor. Moreover, this model

is suitable only for subsets of the population (high income groups) compared to our model

which can be deployed among different users groups as discussed previously.

Chapter 4

Design Requirements

In this chapter, we envision the outline of the FRAC framework to recognize the requirements

of the FRAC system. We then discuss the quality attributes which will allow the system to

meet user expectations and ensure efficiency. Finally, we discuss the functional requirements

of the system, which defines the important prerequisites for the FRAC system to function

correctly and efficiently.

4.1 Outline

We define a broad outline of the FRAC system based on which we formulate the important

functions and quality requirements that has been considered in the FRAC design. FRAC

is an advertisement-based community network sharing framework. The key elements in this

framework are CLIENTs, HOSTs, ADVERTISERSs and the AGENT.

CLIENT/USER

Any Wi-Fi-enabled device which includes laptop, PC, smartphones, tablets that can connect

to HOSTs on the FRAC framework for free internet access is a potential CLIENT. CLIENTs

26

Lakshman Swaroop Babu Chapter 4. Design Requirements 27

may view advertisements and promotions, or provide feedback and reviews about products,

services and features in exchange for internet access.

HOST

HOSTs represent subscribers who have internet access services from ISPs or other sources

with a Wi-Fi enabled router and are willing to share their excess internet bandwidth with

CLIENTs. Suitable compensations are provided to HOSTs in exchange for delivering adver-

tisements or other messages to CLIENTs during their internet access period.

ADVERTISER

ADVERTISERS represent any party interested to advertise, promote, send messages, get

consumer opinions or create an awareness about any product or service or feature using

the FRAC network. They purchase advertising space on the framework to reach a captive

audience and are the sponsors of the system.

INTERMEDIARY/AGENT

The organization which essentially coordinates between HOSTs, CLIENTs and ADVER-

TISERs in this framework is the INTERMEDIARY (or) AGENT. The main source of the

revenue in this framework comes from developing creative high value advertisement models

and promotion schemes, planning and management of the advertisement delivery process.

AGENT provides suitable compensation to the HOSTs based on proportional revenues gen-

erated. AGENT uses a set of servers to perform its functions, we refer to these set of servers

as FRAC SERVER.

To be a part of the FRAC network, CLIENTs install applications in their system which we

refer to as CLIENT APP and the HOSTs install new software on their wireless routers to

extend the functions of their router to support FRAC functions. We refer to this modified


configuration of the HOST’s wireless router as HOST AP.

We discuss the sequence of steps which outlines of the interaction between the elements in

FRAC.

• CLIENT device associates itself to a HOST AP on the FRAC network.

• When the CLIENT uses the web browser to access the internet, the browser is auto-

matically redirected by the HOST AP to a webpage hosted by the INTERMEDIARY.

CLIENT downloads and installs a CLIENT APP, which is basically an application or

browser extension.

• CLIENT APP communicates with the FRAC SERVER through the HOST AP to

register itself on the FRAC network. FRAC SERVER communicates with the HOST

AP to provide free internet access to the respective CLIENT.

• CLIENT APP periodically retrieves advertisements from the FRAC SERVER and

publishes it on the browser. FRAC SERVER quantifies the advertisements and promo-

tions served successfully to CLIENTs using a HOST AP based on which proportional

compensation is provided to that HOST.

• CLIENT is disconnected from the service if the advertisements are not viewed com-

pletely or if the CLIENT APP functions maliciously. The CLIENT is blocked internet

access by the FRAC SERVER through the HOST AP.

• ADVERTISERS promote their advertisements campaigns through the INTERMEDI-

ARY which publishes these advertisements on different CLIENT devices through the

FRAC SERVER.


4.2 Quality Requirements

• Scalability: FRAC should be able to support a growing user base. Efficient and

practical design will enable FRAC to support a large number of USERs, HOSTs and

ADVERTISERs.

• Self-sustainability: The goal of the FRAC model is to provide a self-sustainable

framework which benefits all the elements in the framework. The design choices should

be structured to allow all the elements to benefit from the system to enable sustain-

ability.

• Robustness: Stability of the system under perturbations and errors.

• Portability: Using FRAC software in different environments. CLIENTs should be

able to use FRAC CLIENT APP from different devices, operating systems, architec-

ture and hardware to ensure a wide range of customers use the FRAC system. To

support FRAC CLIENT APP for smartphones and tablets apart from laptops, as the

smartphone user base is huge and growing rapidly.

• Maintainability and Flexibility: Providing efficient ways to detect and correct

errors in the framework, perform modifications to enhance the system functionality

allowing for flexible design modifications.

• Reliability: Preventing application and system failures, reducing errors that affects

CLIENTs and HOSTs directly. For example, ensuring the HOSTs are able to use their

internet and are not affected due failure of HOST AP software.

• Efficiency: Reducing the complexity of design, software implementation and ensuring

high performance with little overhead and better response time. For example, since

HOST APs are embedded devices with limited resources, the design should off-load

avoidable functions from the router to ensure better performance.


• Usability: Ensure the design provides a functional system, which can be easily used

by all elements in the framework. Providing an easy way to install software and to

register with the FRAC system.

4.3 Functional Requirements

We classify the functional requirements that need to be considered in FRAC design as basic

functions and additional functions. The basic functions discussed will help us design a func-

tional prototype of the FRAC system. The additional functions will provide supplementary

features which will help the FRAC system achieve its quality requirements further.

4.3.1 Basic Functions

4.3.1.1 CLIENT Isolation

It is important to isolate a CLIENT connecting to the HOST AP, this will ensure privacy and

security of HOSTs and CLIENTs. This will also provide better reliability and robustness,

allow HOSTs and CLIENTs to conveniently use their internet without any interruptions

from other CLIENTs.

4.3.1.2 CLIENT and HOST Authentication

The notion of CLIENT authentication in this framework is to simply validate the USER’s

CLIENT APP and register a USER to the FRAC network by storing USER credentials in

the FRAC SERVER through the HOST AP. Once the CLIENT is authenticated by the

FRAC SERVER, the HOST APs allow the CLIENTs to access the internet. Since the

HOSTs are agreed incentives based on the client activity on the HOST AP, the HOST

authentication is not as trivial compared to the CLIENT authentication. Periodic HOST


authentication is required to maintain the active HOST APs and their IP addresses in the

FRAC SERVER. Digital signatures, asymmetric encryption and decryption, timestamps can

be used to strengthen HOST authentication. Further, we need to provide a mechanism

to maintain connectivity between all the elements in the framework by using heartbeat

messages.

4.3.1.3 Advertisement Delivery Mechanism (ADM)

Once CLIENTs are authenticated by the FRAC SERVER, the HOST AP allows the CLIENT

to access the internet. CLIENTs watch advertisements which are periodically published on

their browser to sustain their internet access. ADM constitutes the way the advertisements

are delivered to CLIENTs from the FRAC SERVER, and methods to ensure these advertise-

ments are enforced properly. ADM creates an effective advertising medium which ensures

more revenue.

The main requirements to design ADM are the following.

• Advertisements are delivered and published successfully to the CLIENTs.

• Foolproof mechanisms to ensure advertisements are enforced properly at the CLIENT.

• Enforce periodic internet access policies which allow and deny internet access to the

CLIENTs.

4.3.1.4 Quality of Service

Certain QoS features are required to ensure that HOSTs are able to use their internet service

without compromising their internet connection experience by providing priority to HOST

traffic over the CLIENTs. Further, every CLIENT connecting to this framework should get

their fair share of bandwidth and admission control will has to be strictly enforced at HOST

AP, so that the HOST AP is not overloaded with CLIENTs.


4.3.1.5 Billing Mechanism

In this framework, HOSTs share their unutilized internet bandwidth with CLIENTs in ex-

change for benefits from INTERMEDIARY. An appropriate billing mechanism is required

to quantify the HOST AP’s ability be a successful advertising medium, based on which com-

parable benefits are provided to respective HOSTs. A similar billing mechanism is required

to charge the ADVERTISERs for promotions using the FRAC network.

As described above, the notion of accounting in our framework differs from other standards

like RADIUS, Diameter and solutions like WifiDog where the users/clients are charged based

on internet usage time or bandwidth. In our framework, a trusted accounting system is re-

quired to distribute incentives to the HOSTs and provide a portal for ADVERTISERs where

they can view their performance statics and pay their charges. The billing mechanism can

be quite simply be any successful advertisement pricing scheme used for online advertising.

4.3.1.6 Security and Firewalls

Providing security ensures safe and secure operation of CLIENTs and HOSTs, ensures all

the elements in this framework work correctly and detects malicious activity. The important

security requirements are as follows.

• Firewall to ensure isolation, access control and restrictions, proper operation of all

functional blocks.

• Use encryption and decryption to ensure critical packets/control messages traverse the

network securely. Creating a secure channel for communication between CLIENTs,

HOSTs and FRAC SERVER.

• Use authentication mechanisms like digital signatures, timestamps to authenticate

HOSTs and CLIENTs in the framework.


Providing the right amount of security is critical for better system efficiency and performance,

as this will reduce the overhead from using complex security features.

4.3.1.7 Unified Message Exchange Format

All the nodes in FRAC system have to communicate with each other in order for it to

function. To ensure portability, interoperability and to make the system scalable, a common

message format is a prerequisite. There are a variety of standard options and a fitting choice

would depend on the requirements and functionality of the system. The basic requirements

of this message format is that it should be lightweight, have low implementation complexity,

portability, better support and reduced overhead. It should be flexible, extensible and easy

to parse.

4.3.2 Additional Functions

4.3.2.1 Automatic Network Discovery and Selection

CLIENT APP identifies and associates with HOST APs in the background automatically

without any active intervention from the USER. This will ensure that CLIENTs do not

connect to incorrect APs which are not part of FRAC system. This feature is currently being

released in Wi-Fi certified Passpoint devices, which was discussed earlier in the related work

section.

4.3.2.2 Automatic Software Updates

This feature will enable the all the elements in the FRAC system to update software and

additional features automatically providing more flexibility to add additional improvements

and features.


4.3.2.3 Effective Advertising and Promotions

This framework remains self-sustainable only when this framework is an effective marketing

solution for commercial organizations. One of the important goals would be to find creative

solutions which will make this framework an effective advertising and marketing medium.

Chapter 5

Design

First, the most widely used architectures and platforms for HOST AP and CLIENT APP

are considered which determine the flexibilities and limitations in FRAC design. Then, we

examine the design of the essential features in the FRAC system. Finally, the elements and

their overall design based on these features are provided.

5.1 Architecture and Platform

5.1.1 HOST AP

The HOST AP is typically a Wi-Fi router which consists of a router and a wireless access

point. Since the HOST AP has to be configured to perform additional functions like allowing

and denying CLIENTs into the guest network, communicate with the FRAC SERVER or

CLIENT APP, the host firmware has to be modified to perform these additional functions.

To perform these additional functions, we use open source firmware like dd-wrt or OpenWrt

which are quite popular. The router must be compatible with the open source firmware in

order for it to be installed over the proprietary router firmware. As explained earlier, there

is a very wide base of commercial home routers which being used today that are capable of

35

Lakshman Swaroop Babu Chapter 5. Design 36

using open source firmware like dd-wrt and OpenWrt.

Most of the routers in the market use the MIPS or MIPSEL architecture (MIPS architecture

in little endian format). Though the router hardware and support features vary greatly

across different brands and price ranges, their basic hardware and functions remain identical.

More flash memory and RAM on a router improves throughput, performance and supports

larger networks. To ensure better portability across different wireless routers, the HOST

AP software should be designed to support minimal flash and RAM in available in routers

(16MB RAM, 4MB Flash).

5.1.2 CLIENT APP

The CLIENT is typically any device which has a Wi-Fi adapter and is capable of connecting

to the HOST AP. CLIENT devices include PCs, laptops, netbooks, smartphones and tablets.

Based on the device type, the CLIENT APP can be classified as browser-based and app-

based.

Browser-based CLIENT APPs are for PCs, laptops and netbooks. These devices mainly

use the internet through their web-browser like Firefox, Chrome, Internet Explorer, etc.

CLIENT APP in these devices can simply be a browser extension which runs on the back-

ground or system software which interact with the browser. The design of the CLIENT APP

is browser specific rather than platform specific as most of the browsers take care of the com-

patibility through different architectural platforms.

App-based CLIENT APPs are for smartphones and tablets. These devices uses the internet

mainly through Apps on their devices rather than web-browsers. CLIENT APP in these

devices is typically an APP on the device, as such this makes the CLIENT APP platform

dependent. The two commonly used platforms for these devices are Android and iOS, and

the CLIENT APP requires separate design and implementation in both these platforms.

CLIENT APP portability remains a challenge due to varied devices and platforms over which


CLIENTs typically use the internet. Potential solutions involve designing CLIENT APPs

separately for the most widely used platforms and devices or finding a way to support and

design one CLIENT APP for most platforms and devices.

5.2 FRAC Design Features

Message Abbreviations

HTTP CLIENT AUTH REQ HTTP authentication request from CLIENT APP to HOST AP

HTTP CLIENT AUTH RESP HTTP authentication response from the HOST AP to

CLIENT APP

HTTP AP AUTH REQ HTTP authentication request from HOST AP to FRAC SERVER

for CLIENT

HTTP AP AUTH RESP HTTP authentication response from FRAC SERVER to HOST AP

for CLIENT

HTTP VAD REQ HTTP CLIENT Video Advertisement Request

HTTP VAD RESP HTTP CLIENT Video Advertisement Response

HTTP VAD NOTIFY REQ HTTP CLIENT Video Watched Notification Request

HTTP VAD NOTIFY RESP HTTP CLIENT Video Watched Notification Response

HTTP BAD REQ HTTP CLIENT Banner Advertisement Request

HTTP BAD RESP HTTP CLIENT Banner Advertisement Response

5.2.1 JSON Unified Messaging Protocol (JUMP)

JavaScript Object Notation (JSON) is used to create a unified messaging protocol in FRAC.

JSON is made out of two structures, a collection of field-value pairs and an ordered list of

values [32]. JSON Unified Messaging Protocol (JUMP) is a predefined set of fields used with

JSON as the common message exchange format to communicate across all the elements in

the FRAC network. JUMP uses HTTP as its underlying protocol. Since JUMP is essentially


JSON, it can be easily extended to support additional fields and data types.

A detailed description of JUMP is provided in the Appendix section of this document.

5.2.1.1 JSON Schema

JSON Schema is a JSON based format for defining the structure of JSON data. JSON schema

provides an overview of the required data for applications and the methods to interact with

data. It validates JSON objects, and provides documentation and hyperlinking.

{

"client_id" : {

"type" : "string",

"value" : "6ge3T9pf"

},

"message" : {

"type" : "number",

"value" : "10"

},

"protocol_version" : {

"type" : "string",

"value" : "1.1"

},

"software_version" : {

"type" : "string",

"value" : "1.0"

},

"session_id" : {

"type" : "string",

"value" : "sid"

},

}

5.2.1.2 Message and Status Codes

Message and Status codes help the application to process requests and responses. JUMP

uses message codes to provide information to the nodes in the framework to identify the


message in order to process the received data appropriately. JUMP uses status codes to

determine if the status of a request was a success or failure and provides the reason for the

failure.

5.2.1.3 Example: Message Format

The following is an example of the HTTP CLIENT AUTH REQ message using JUMP.

{

client_id: "6ge3T9pf",

message: "10",

protocol_version: "1.1",

software_version: "1.0",

session_id: "1qw3e4v9"

}

5.2.2 CLIENT Authentication Mechanism

The CLIENT authentication requirements are modest and lightweight as discussed previ-

ously. We basically validate the USER’s CLIENT APP and register a USER to the FRAC

network by storing USER credentials in the FRAC SERVER through the HOST AP.

Initially all the packets from the CLIENT are dropped at the HOST AP, as the CLIENT has

not been authenticated. CLIENT APP sends a HTTP CLIENT AUTH REQ to the HOST

AP. This request is received by the HOST AP firewall and it triggers the HOST AP to send

an HTTP AP AUTH REQ for the CLIENT to the FRAC SERVER. The FRAC SERVER

validates the request and adds the CLIENT to the database if the request was success-

ful. It sends back a HTTP AP AUTH RESP to the HOST AP which forwards it to the

CLIENT APP, and if the requests was successful the HOST AP allows the CLIENT to ac-

cess the internet (unblocks CLIENT). Note that HOST AP sends authentication request for

a CLIENT not the CLIENT itself because otherwise, this would allow malicious CLIENTs

to send requests to the FRAC SERVER from behind non-FRAC APs.


text texttext text

CLIENT_APP HOST AP FRAC_SERVER

HTTP_CLIENT_AUTH_REQ

HTTP_AP_AUTH_REQ

HTTP_CLIENT_AUTH_RESP

HTTP_AP_AUTH_RESP

(HTTP_CLIENT_AD_REQ)

Validate Request

Authenitcate CLIENT

Add CLIENT to DB

Initialize CLIENT data

Forward response.

If Authentication

successful, unblock

CLIENTCLIENT is

allowed a grace

period to send

AD request and

view AD.

Figure 5.1: CLIENT Authentication Mechanism

Uniquely identifying HOSTs and CLIENTs is an important authentication requirement.

We see that CLIENTs are connected to HOST APs at Layer 2, CLIENT MAC IDs are

broadcasted by CLIENTs to the HOST AP. CLIENT MAC is a unique identifier for a

CLIENT at the HOST AP. Since, HOSTs are connected to the FRAC SERVER at layer

3 and they have multiple MAC IDs for different interfaces, the FRAC SERVER cannot

determine the MAC ID of the HOSTs. A unique gateway ID is provided to HOST APs and

CLIENT APPs to identify the valid HOSTs and CLIENTs at the FRAC SERVER.

5.2.3 Maintaining Connectivity

Since, the HOST AP in the framework connected to the FRAC SERVER over the internet

and has a dynamic IP address, secure keep-alive messages are sent periodically to ensure the

HOST AP is not malicious and FRAC SERVER updates the IP address for a valid HOST

AP in the database.


5.2.4 Advertisement Delivery Mechanism (ADM)

Display advertising and video marketing are preferred advertising methods for this framework

and are effective marketing strategies. ADM provides successful advertisement delivery to

CLIENTs and ensures foolproof ad publishing which enables periodic internet access for the

CLIENTs. Although, the basic principle remains the same, ADM differs based on the type

of marketing strategy and the CLIENT device. ADM for banner ads and video ads for a

browser based CLIENT APP are discussed in this section.

Our prototype design is a video-centric model that provides internet access when the CLIENT

views video advertisements periodically. Since we use HTTP which is a pull protocol.

FRAC SERVER will be able to deliver advertisements only when requested by the browser

or CLIENT APP .

5.2.4.1 ADM for Video Ads on a Browser-based CLIENT APP

Once the CLIENT is authenticated, the HOST AP unblocks the CLIENT and allows internet

access for a grace period. During this grace period the CLIENT APP will request the

video advertisement data from the FRAC SERVER and publishes the received data on the

USER browser. The browser retrieves the video advertisement from the AD Server. The

USER views the video, a trigger button is displayed for a random interval during which the

USER is required to click on the trigger button. This sends out a trigger request to the

FRAC SERVER, this mechanism ensures the video is being watched by the USER. After

the USER views the video completely, a notification request is sent from the CLIENT APP

to the FRAC SERVER. FRAC SERVER updates the timer for the respective CLIENT in

the database provided both the trigger request and notification request are received and

sends back a response to the CLIENT APP. Every time at the start of the grace period, the

CLIENT APP automatically sends out a video advertisement request to the FRAC SERVER

to renew the internet connectivity.


text texttext text


HTTP_VAD_REQ

Send AD response to

valid CLIENT.

Update trigger request.

Update notification request from

CLIENT_APP.

IF both messages are received,

update CLIENT timer in DB.

Send response to CLIENT.

CLIENT_APP receives Video

AD, CLIENT views AD and

clicks on trigger buttons, which

send out a trigger request.

After viewing AD, the APP

sends notification message to

FRAC_SERVER

If successful response, APP

updates CLIENT timer

HTTP_VAD_RESP

trigger_request

HTTP_VAD_NOTIFY_REQ

HTTP_VAD_NOTIFY_RESP

CLIENT_APP sends an video

ad request when CLIENT has

grace period of internet access

remaining.

Figure 5.2: Video Advertisement Delivery Mechanism

The message exchange takes place between the CLIENT APP and the FRAC SERVER, and

does not involve the HOST AP. This reduces the complexity at the HOST AP and prevents

any malicious activity at the HOST AP.

This section focused on delivering the video to the USER’s browser but we also require

mechanisms to enforce the USER to watch these advertisements completely. It would not

be effective if the USER can simply shift between tabs and open new windows, to avoid the

advertisements. This issue is implementation specific and is addressed in the next chapter.

5.2.4.2 ADM for Banner Ads on a Browser-based CLIENT APP

Banner Ads are automatically enabled once the CLIENT is authenticated in the frame-

work. The CLIENT APP sends banner ad requests to the FRAC SERVER periodically. The

FRAC SERVER maintains a counter for the requested banner ads, to ensure CLIENT APP

is working correctly. It sends a HTTP BAD RESP which contains the banner ad data, which

is published on the USER’s browser. The browser requests the banner ad from the ad server.


text texttext text


HTTP_BAD_REQ

Send banner AD

response to valid

CLIENT. Updates

banner ad counter.HTTP_BAD_RESP

CLIENT_APP sends banner

ad request when banner ad

timer expires.

CLIENT_APP publishes

banner ad in USER’s browser

window/tabs.

Figure 5.3: Banner Advertisement Delivery Mechanism

5.2.4.3 CLIENT Expiry Process

CLIENTs are removed from the FRAC network if they do not view advertisements fully

before the timer expires, or if the CLIENT APP functions maliciously.

text texttext text


HTTP_EXP_NOTIFY_REQ

HTTP_EXP_REQ

HTTP_EXP_RESP

Event: CLIENT timer expired

(or) malicious CLIENT activity.

Server sends an expiry request

for CLIENT to HOST AP.

Identify CLIENT, block

CLIENT access, send expiry

notification to CLIENT_APP

Sends confirmation to

FRAC_SERVER.

Server removes CLIENT

from DB.

Figure 5.4: CLIENT Expiry Process

CLIENTs usually have a grace period over which they should watch the advertisements. If


CLIENT fails to do so, the FRAC SERVER communicates with the HOST AP and sends an

HTTP EXP REQ for that CLIENT. The HOST AP removes that CLIENT from the FRAC

network.

5.2.4.4 CLIENT Initiation Process: Launching CLIENT APP

Providing a simple way to connect, install and use FRAC software on the CLIENT is im-

portant and improves the usability of the FRAC system. We suggest an easy way for the

CLIENT to be initiated into the FRAC network from browser of any CLIENT connected to

a HOST AP.

text texttext text

CLIENT

BROWSERHOST AP FRAC_SERVER

HTTP WEB Request

Download Request + User

credentialsServer sends the

CLIENT_APP with

installed unique key and

Id.

CLIENT installs

CLIENT_APP

to connect to

FRAC network.

Detects new unregistered

CLIENT. Sends a redirected

splash page response, allows

CLIENT to download

CLIENT_APP from

FRAC_SERVER.Redirected splash page response

HOST AP firewall allows

only access to only this

link for a new client.

Response: CLIENT_APP

New CLIENT,

CLIENT_APP

not installed

Figure 5.5: CLIENT Initiation Process

Once the CLIENT connects to the HOST AP, it may request a web page from its browser

via HOST AP. Since the CLIENT is not registered with the FRAC network, HOST AP

drops all packets from the CLIENT. But first few packets trigger the HOST AP to send a

splash page redirect to the CLIENT browser. The CLIENT will be able to download the


CLIENT APP software and instructions from this page on entering required user credentials.

The FRAC SERVER sends a CLIENT APP file with uniquely configured key and ID.

5.2.5 CLIENT Isolation

CLIENT isolation can be achieved with the following steps.

• Separate internal networks and interfaces for CLIENTs and HOSTs, guest network and

main host network which also includes adding a DHCP server and configuring NAT

for the newly configured guest network.

• Multiple SSID broadcast, one for guest network and one for host network.

• Isolating CLIENTs within the guest network, so that they can communicate only with

HOST AP and not any other devices within the network.

• Blocking all incoming packets from unauthenticated CLIENTs, except authentication

requests.

• Provide administrative and access privileges only to HOSTs and not to CLIENTs.

Almost all the recent wireless routers in the market have the capability to broadcast mul-

tiple SSIDs and upgrading to Linux-based dd-wrt router firmware provides the features to

configure separate internal networks, guest isolation and provide access control [33] . These

features can be realized using Linux utilities such as iptables, brctl, ifconfig.

5.2.5.1 Creating Multiple SSIDs and VLANs

We create an additional SSID for the wireless interface and an additional VLAN to for the

guest network. The initial router configuration and modified router configuration is shown.


LAN1 LAN2WAN LAN3 LAN4

CPU

32MB DDR

SDRAM

802.11b/g/n

8MB Flash

0 1 2 3 4

8

Ethernet Switch

vlan 2

vlan 1

eth0

br0 eth1

Figure 5.6: Initial Router Configuration

LAN1 LAN2WAN LAN3 LAN4

CPU

32MB DDR

SDRAM

802.11b/g/n

8MB Flash

0 1 2 3 4

8

Ethernet Switch

vlan 2

vlan 1

eth0

br0 eth1

br1wl0.1vlan 3

Figure 5.7: Modified Router Configuration

We see in the modified router configuration, wired vlan3 and wireless wl0.1 interfaces are

bridged. Since the CLIENTs are not connected to the HOST AP using wired interfaces, it

is sufficient to create a bridge br1 with the wireless virtual interface wl0.1 and no ports in

vlan3. The wireless virtual interface wl0.1 is configured to broadcast a new guest SSID to

connect to the guest network.


5.2.5.2 Creating Virtual guest interface and guest network

The following script will create a new bridge and move the wireless interface to it. [33] [34]

nvram set dnsmasq\_enable=1

if [ "‘nvram get dhcpfwd\_enable‘" = "0" ]; then

nvram set dns\_dnsmasq=1

nvram set dhcp\_dnsmasq=1

nvram set auth\_dnsmasq=1

fi

# Create bridge br1 and move the virtual wireless interface wl0.1 to it,

brctl addbr br1

brctl delif br0 wl0.1

brctl addif br1 wl0.1

#Setup IP subnet for guest interface.

ifconfig br1 192.168.2.1 netmask 255.255.255.0

ifconfig br1 up

5.2.5.3 Access Control Rules

This command enables NAT on all the interfaces including the virtual guest interface [33]

[34].

/* Enable NAT on WAN port for virtual interface (br1)/all interfaces */

iptables -t nat -I POSTROUTING -o ‘get\_wanface‘ -j SNAT --to ‘nvram get wan\_ipaddr‘

These set of commands set access control rules for the new virtual guest interface.

/* Allow br1 access to br0, the WAN, and any other subnets */

iptables -I FORWARD -i br1 -m state --state NEW -j ACCEPT

iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

/* Restrict both wireless networks from talking to each other */

iptables -I FORWARD -i br1 -o br0 -m state --state NEW -j DROP

iptables -I FORWARD -i br0 -o br1 -m state --state NEW -j DROP

/* Restricting br1 from accessing the router */


iptables -I INPUT -i br1 -p tcp --dport telnet -j REJECT --reject-with tcp-reset

iptables -I INPUT -i br1 -p tcp --dport ssh -j REJECT --reject-with tcp-reset

iptables -I INPUT -i br1 -p tcp --dport www -j REJECT --reject-with tcp-reset

iptables -I INPUT -i br1 -p tcp --dport https -j REJECT --reject-with tcp-reset

By default, all packets sent to the WAN interface from the guest network are dropped.

/* Blocking WAN for br1 */

iptables -I FORWARD -i br1 -o ‘get\_wanface‘ -j DROP

5.2.6 Quality of Service (QoS)

QoS is required to ensure that HOST internet traffic is not compromised because of CLIENTs

in the guest network and so that every CLIENT in FRAC is provided a fair share of available

bandwidth. The important factors to be considered in QoS design are the following. [25]

• Downloading large files using P2P applications, UDP connections will consume con-

siderable bandwidth. Due to this HOSTs and other CLIENTs using the network from

that HOST AP are affected, and do not get their fair share of bandwidth.

• Since HOSTs are typically private consumers mostly subscribing to internet plans from

ISPs, it is not possible to know internet bandwidth available in advance.

We provide a design which is simple, effective and addresses most of these concerns while

providing priority to HOST traffic.

• Provide priority to HOST traffic over CLIENT traffic at all times. This can be accom-

plished by setting up two queues one for HOST traffic and one for CLIENT traffic,

and using a strict priority scheduler to forward HOST packets first.

• Adding Firewall rules to disallow or throttle certain types of traffic on guest network

like P2P traffic, UDP traffic, large files. This will make sure that a single CLIENT


does not take up too much bandwidth, and to ensure all CLIENTs get their fair share

of bandwidth.

• Enforce strict Admission control policy, allowing only a fixed number of CLIENTs per

HOST AP.

• To ensure all the CLIENTs get fair share of bandwidth from HOST AP we can use

the following.

– Round-robin scheduling: The HOST AP schedules packets in the CLIENT queue

in a round-robin fashion to all the CLIENTs. One advantage with this approach

is that the entire available HOST-unused bandwidth is divided equally among all

the CLIENTs in HOST AP. Enhanced Stochastic Fair Queuing (ESFQ) can be

used to effectively accomplish the same.

– Static bandwidth allocation: Fixed bandwidth allocation to all CLIENTs using

the HOST AP. Problem with this approach is that it is not possible to know the

available internet bandwidth at a HOST AP.

SP

CLIENT Queue

SFQ

HOST QueueIncoming Packets

br1

br0

To HOST

To CLIENT 1

To CLIENT 2

To CLIENT 3

Figure 5.8: Proposed QoS Configuration

QoS design is simple, lighweight and easily implementable on routers using iptables, tc and

qdisc functions which is available in dd-wrt or other Linux-based firmware.


5.2.7 Security and Firewall

There are new threats that arise in the FRAC model, which are discussed below.

• A malicious CLIENT tries to avoid viewing advertisements or participating in pro-

motions, and tries to hinder the ADM and get free uninterrupted internet access. The

malicious CLIENT can do this by modifying the CLIENT APP to function differ-

ently, such as sending fake requests to the FRAC SERVER. CLIENT may also try to

eavesdrop on other CLIENTs or HOSTs in the network.

• A malicious HOST attempts to maximize its revenues from the FRAC system by

over-reporting advertisements. Since HOSTs have control of their AP, they can attempt

to maximize benefits by severely rate limiting CLIENTs, removing CLIENT security

features to eavesdrop into CLIENT traffic and steal important critical information.

HOST may try to modify the AP software to function maliciously like changing the

initial splash page to steal USER credentials. An invalid HOST can act as though it

is part of the FRAC network and steal information from the CLIENTs connected to

its AP.

• Malicious HOST-CLIENT coordination can provide a way for HOSTs to max-

imize profits fraudulently or allow CLIENTs to get uninterrupted internet access. A

malicious HOST can create a few bogus CLIENTs/CLIENT APPs and use bots to

click on advertisements. This will maximize revenue for the HOST without actually

serving CLIENTs.

• A malicious unregistered user may connect to the guest network at the HOST AP,

and create DoS attacks by constantly sending packets to the router.

• Any eavesdropper in the internet can steal sensitive information from CLIENTs if

critical data is sent using an unsecured channel without any encryption.


The security features that are required to address these security threats include authenti-

cation to register/identify CLIENTs and prevent unauthorized entities to act as a HOST,

encryption to provide a secure channel to send and receive critical data between the HOSTs,

CLIENTs and FRAC SERVER. We strengthen security using firewall rules using iptables,

improve the authentication mechanism and ADM. In order to provide the right amount of

security, we use a combination of HTTP messages for non-critical data and HTTPS messages

for critical data for communication between FRAC elements to reduce significant message

overhead and improve performance and scalability.

5.2.7.1 Secure Authentication

Since most of the communication over the FRAC network is not critical, providing lighter

security features serves the purpose and improves scalability. CLIENTs and HOSTs can

send digitally signed the messages to the FRAC SERVER and vice versa using public key

infrastructure which provides authentication for most of the FRAC messages. Common

public-key cryptography algorithms such as MD5, SHA, RSA can be used. Since, the im-

plementation complexity and overhead is much lesser compared to complex encryption and

decryption, this method can be implemented in HOST AP which have limited resources.

Further, timestamps can be used to avoid replay attacks.

5.2.7.2 Encryption

Since HOSTs are provided benefits based on the ads requested or clicked by CLIENTs using

that HOST AP. Encrypting the advertisement responses and notification requests from the

CLIENT to the FRAC SERVER would ensure the HOST AP cannot tamper with these

messages. Further, the HOST AP which has limited resources is not directly involved in the

complex encryption and decryption process. Transport Layer Security (TLS) has been used

quite commonly by web servers and can be used to provide a secure channel for communi-

cation. Due to significant overhead in encryption/decryption process, the FRAC SERVER


may not scale too well to support a larger client base.

5.2.7.3 Firewall and Access Control

Apart from providing a standard secure firewall, the guest network at the HOST AP uses

access control policies to prevent malicious USERs from using too much resources, or stealing

critical data from other CLIENTs and HOSTs. This can be accomplished by using iptables

to provide firewall and access control. Most of these security vulnerabilities can be resolved

by isolating the CLIENTs as discussed previously. Since any CLIENT can connect to the

guest network in the HOST AP, creating DoS attack on the HOST AP is possible. This

problem can be addressed by rate-limiting CLIENTs connectivity to the HOST AP using

iptables.

5.2.7.4 Strengthening security by design improvements

Although, security in the framework can be improved using these standard approaches, some

of the security vulnerabilities described previously can be addressed only by improving design

to strengthen security. Some of the design considerations to improve security include the

following.

• Randomizing banner advertisement display location would ensure that bots do not

click advertisements to generate revenue for HOSTs.

• FRAC SERVER responds to video advertisement requests from CLIENTs only during

the grace period when the CLIENT is actually required to view the advertisements.

Selective ad response ensures better server scalability.

• Protecting the source code is critical to maintain security. Malicious entities can modify

the source code and change the way CLIENTs and HOSTs function. This can threaten

CLIENTs and HOSTs using this software and create a potential security breach in the


system. Since CLIENT APP is implemented using JavaScript, it remains open source.

We obfuscate the JavaScript using standard tools and software, which will conceal the

real meaning and intent of the JavaScript code. Since HOST AP is a standard binary,

it is secure and cannot be modified easily.

5.2.8 Billing Mechanism

The AD server is responsible for reporting clicks, impressions, actions generated and updat-

ing information in different databases on the FRAC SERVER. ADVERTISERs are provided

with the statistics and accounting for their published advertisements based on which they

provide equivalent compensation. Similarly, the HOST database is updated based on count-

ing the advertisements viewed, delivered or clicked by different CLIENTs using that HOST

AP, based on which they are provided suitable compensation.

For our current prototype model, we support banner ads and video ads which are quite

popular online advertising types. CPM pricing model can be used for video ads, as ADVER-

TISERs pay for brand exposure and awareness. Performance based pricing models such as

CPC and CPA are most preferred revenue models in the market today and can be used for

banner ads.

5.3 FRAC SERVER Design

FRAC SERVER is the key element which coordinates between HOSTs, CLIENTs and AD-

VERTISERs in this framework. The block diagram shows the basic elements and functions

of the FRAC SERVER.


HTTP Server

Common Communication Interface

AD Server Database Server

CLIENT Database AD Database HOST Database

HOST AP CLIENT BrowserCLIENT_APP

Internet

File ServerHTTP Client

Figure 5.9: FRAC SERVER design

HTTP Server and Client

The HTTP Server block is responsible for all the control plane messages to the HOST AP

and CLIENT from the FRAC SERVER. It also consists of a HTTP Client module to sends

requests (expiry) to the HOST AP. HTTP Server and Client modules are responsible for the

following functions which were discussed in the previous sections.

• CLIENT Authentication

• CLIENT Expiry

• Advertisement request and response.

• HOST AP Keepalive

The HTTP server communicates with the database server for CLIENT and HOST infor-

mation to validate messages and authenticate CLIENTs and HOSTs. HTTP server re-


sponds to CLIENT advertisement requests with URLs which deliver advertisements from

the FRAC SERVER. These URLs are generated by the AD server, HTTP server communi-

cates with the AD server to obtain these responses.

AD Server and database

The main function of the AD server is to serve advertisements to CLIENTs in the FRAC

network and to perform accounting operations in the framework. It also has a file server to

download the CLIENT plugin during CLIENT initialization. The AD server also creates and

sends advertisement URLs to the HTTP server which the CLIENT browser retrieves from the

AD server. The AD server does not interact with the CLIENT APP but with the CLIENT

browser. It serves files from the AD database which contains all the advertisements from the

ADVERTISERS in the framework. The AD server updates the number of advertisements

that were clicked, delivered, viewed successfully into the HOST database. Based on these

fields in the database, the HOST compensation is calculated using a suitable cost function.

CLIENT and HOST database

The database server is used to provide response to database lookup and update requests from

the HTTP server and AD server. It also checks for any expired CLIENTs in the CLIENT

database, if there are any expired CLIENTs, then it communicates with the HTTP server

to send an expiry request to the respective HOST AP.

The CLIENT database contains a list of active CLIENTs in the FRAC network and their

credentials which includes their identification, associated HOST IP address and identifica-

tion, the current session identification, service expiry time, security profile and advertise-

ment profile. The CLIENT database also maintains counters to check if advertisements are

published and enforced on the CLIENT device. The security profile information is used

to send and receive critical information using secure channels between the CLIENT and

the FRAC SERVER. The ad profile includes the advertisement selected for delivery to the

CLIENT by the ad server and the advertisement status.


CLIENT_ID HOST_IP HOST_ID SESSION_IDAD

PROFILE

SECURITY

PROFILE

EXPIRY

TIME

VAD

CTR

BAD

CTR

HOST_IP HOST_ID SESSION_IDBAD

CLICKS

KEEPALIVE

COUNT

VAD

CTR

BAD

CTR

SECURITY

PROFILE

Figure 5.10: CLIENT database example

The HOST database contains the list of active HOST APs in the FRAC network and their

credentials which includes the identification, IP address, billing information and security

profile. The security profile information is used to send and receive critical information

using secure channel between HOST AP and FRAC SERVER. The billing information like

the number of advertisements delivered, viewed and clicked, is updated by the AD server.

CLIENT_ID HOST_IP HOST_ID SESSION_IDAD

PROFILE

SECURITY

PROFILE

EXPIRY

TIME

VAD

CTR

BAD

CTR

HOST_IP HOST_ID SESSION_IDBAD

CLICKS

KEEPALIVE

COUNT

VAD

CTR

BAD

CTR

SECURITY

PROFILE

Figure 5.11: HOST database example


5.4 HOST AP Design

HOST SSID GUEST SSID

ROUTER

Internet

Internal WLAN

HTTP Client

CLIENT Database

HTTP Server

CLIENT_APP/Browser

FRAC_SERVER

Access Contol +

Firewall + QoS

Common Communication Interface

Figure 5.12: HOST AP design

This diagram shows the design overview of a HOST AP in the FRAC system. Routers are

embedded systems which have small amounts of Flash and RAM, which makes it challenging

to implement all these design features in the HOST AP. Lightweight implementation, modest

APIs and efficient design are important considerations in the design of HOST AP for FRAC.

We have discussed the important issues such as client isolation, firewall and QoS for the

HOST AP in the previous section on FRAC features. The other important blocks in HOST

AP design are the CLIENT database and HTTP client/server.

A simple CLIENT database implementation is required to maintain the list of active CLIENTs


connected to the HOST AP. Dynamic Access control mainly includes dynamically allowing

and blocking access to CLIENTs in the database based on successful authentication responses

and expiry requests from the FRAC SERVER. HTTP server and client modules in the HOST

AP are used to send and receive control messages from CLIENTs and FRAC SERVER which

are either processed or forwarded based on the message type and status. HTTP server and

HTTP client API should have basic functional features and a modest implementation.

5.5 Browser-based CLIENT APP Design

Wi-Fi Interface

Internet

UI/Popup

Background HTTP Client

HOST AP

FRAC_SERVER

AD SERVER

Common communication interface

Client Browser

Tab 3Tab 2Tab 1

Content Scripts

CLIENT Browser

Figure 5.13: Browser-based CLIENT APP design


This diagram shows the design overview of a browser-based CLIENT APP design. It con-

tains a User Interface (UI) to provide the user with basic information such as the browsing

time remaining, identification, status and authentication. The CLIENT can use the UI to

disconnect from the FRAC network.

The background page is responsible for communicating with all the other blocks - UI, con-

tent scripts and send requests to the HOST AP and FRAC SERVER. Its main functions

include creating and parsing JUMP messages, sending and receiving data using AJAX HTTP

requests to the HOST AP and FRAC SERVER. Once the advertisement data is received

from the FRAC SERVER, it will publish these advertisements using content scripts to the

browser. CLIENT APP maintains two timers - video ad timer and banner ad timer based

on which it sends out requests to the FRAC SERVER. These timers act as guidelines for

the CLIENT APP to send advertisement requests at the appropriate time. Content scripts

communicate with the background to get the advertisement data. The content script exe-

cutes the JavaScript on the web page to publish advertisements onto the webpage which are

then requested from the AD server.

Chapter 6

Implementation

In this chapter, we discuss the implementation of the prototype version of the FRAC system.

The implementation consists of the following software and features.

Base FRAC Software

• Chrome browser extension for Browser-based CLIENT devices.

• Embeddable HOST Gateway application (executable binary) developed using C with

dd-wrt Firmware

FRAC System Features

• JSON Unified Message Protocol (JUMP)

• CLIENT authentication mechanism.

• Advertisement Delivery Mechanism for Browser-based CLIENT APPs

• CLIENT isolation.

For this setup, we use a basic apache HTTP web server on Amazon EC2 with a global IP

60

Lakshman Swaroop Babu Chapter 6. Implementation 61

as the FRAC SERVER for testing implementations. This is a pretend server which provides

static responses to the JUMP message requests from the HOST AP and CLIENT.

The other design features include the FRAC SERVER prototype implementation, QoS for

CLIENTs at HOST AP and most of the security features discussed in the FRAC design.

These features are currently being implemented by our project team but are not part of this

work.

6.1 CLIENT APP Implementation

CLIENT APP developed in the prototype version is a Chrome browser extension. As we

discussed earlier, Chrome extensions are written in HTML, JavaScript, and CSS using AJAX

and Chrome API to enhance the Google Chrome browsers functionality to run on FRAC

networks. Chrome extensions are not system specific but Chrome browser-specific. So this

CLIENT APP works on all systems which has a Chrome browser installed.


Figure 6.1: Working screen showing CLIENT APP with an video advertisement published

on the Chrome browser

As discussed previously, the Chrome extension has a background page which holds the main

logic of the extension. The extension has a UI to display information to the user and content

scripts to communicate with webpages that the user loads onto the Chrome browser. The

other pages include web storage data using localStorage API and JSON message API [5].

6.1.1 Background Page

The following are the main functions of the background process.

• Sending asynchronous HTTP AJAX POST requests to FRAC SERVER and HOST AP

in the background. JQuery provides additional customization on the AJAX requests.

The code fragment shown below is an example of an AJAX request which retrieves

banner advertisement data from the server.


$.ajax({

url : server\_url,

type : ’POST’,

contentType: ’application/json’,

data : json\_data,

success :

function(data)

{ console.log("Device Control Succeeded");

localStorage.setItem("banner\_data",data);

localStorage.setItem("banner\_exists",1);

},

error :

function()

{ console.log("Device Control Failed"); return 0;}

});

• Creating and parsing JUMP messages – Since Chrome extension uses JavaScript, a

straightforward JUMP implementation is possible. JSON data can be easily created

and parsed from JavaScript code and is well suited for AJAX-based web applications.

Most web browsers including Chrome provide native JSON support which includes

lightweight functions json.parse() and json.stringify() to convert JSON string data

into JSON objects and vice versa respectively [32].

var json\_response = JSON.parse(data);

var json\_data = JSON.stringify(json\_obj);

JSON schema is used to define the message fields in JUMP. We define a small API to get,

set and compare JSON objects in JavaScript. This allows us to construct and manipulate

JSON objects for message exchange.

JUMP.Settings = {

{

"client\_id" : {

"type" : "string",


},

"message" : {


"type" : "number",

"value" : "10"

}

};

JUMP.Settings.set({"message":"73"});

var json\_obj = JUMP.Settings.get();

• Communicates with the extension UI and content scripts using Chrome API functions.

The code fragment shown below sends a message to other scripts in the extension, and

processes the response.

chrome.extension.sendMessage(null, {action: value}, function(response) {

console.log("Response From Background: "+response.status);

if(response.status == 20) {

chrome.extension.getBackgroundPage().location.reload();

}

});

• Detects browser events based on which it interacts with the webpages on the browser

to display advertisements. The code fragment shown below fires an event whenever a

tab in the browser is updated.

chrome.tabs.onUpdated.addListener(function(tabId, changeInfo, tab) {

if(localStorage.getItem("banner\_exists") == 1) {

display\_banner\_ad(localStorage.getItem("banner\_data"));

}

});

• Persistent local storage support is available on the Chrome browser with HTML5.

Background uses localStorage to store and retrieve application specific data and current

status.


6.1.2 Extension UI/ Popup

The extension UI developed is a popup, which is displayed when the USER clicks on the

extension icon. When the extension UI pops up, it gets CLIENT APP status data from the

background page. The information displayed on the page includes the CLIENT identification,

status, authentication and internet access time remaining. USER can connect and disconnect

from the service as and when required using the UI.

Figure 6.2: CLIENT APP: Popup-based User Interface

6.1.3 Content Script

The received advertisement data from the FRAC SERVER is not the advertisement itself but

its location (URL) on the AD Server. Content scripts communicate with the background

page using Chrome API as shown above, to get the advertisement data. Then, they can

inject this data as new HTML div or iframe elements which contain video objects and image

objects on the webpages which are then viewed by CLIENTs.


6.1.4 Enforcing Video Advertisements on CLIENT browser

Enforcing USERs to view advertisements is an important requirement in the FRAC system

making it an effective advertising medium and boosts the revenues from ADVERTISERS.

Mentioned below are the common ways to publish video advertisements on CLIENT browser.

• New Window: Displaying video ads on a new window, common user response would

be to close the window.

• New Tab: Displaying video ads on a new tab, this will require more than just injecting

content scripts as there is no webpage on a new tab. Moreover, the user will close this

tab or switch to another tab when the ad is displayed.

• Current Tab: Displaying video ads on the current tab that the user is using. This can

be achieved by injecting the advertisement from the background page into the content

script on the page. Further, USER will not necessarily close this tab as he will lose

the current page but may switch to another tab.

These are the common USER responses when displaying video ads in different ways. Our

implementation uses a current tab video display mechanism to enforce video ads on the

Chrome browser.

6.1.4.1 Current Tab Video Display

We publish video ads on the USER’s current tab by injecting video ad data from the extension

background onto the content script of that page. If the USER shifts to a new tab, that page

is refreshed and the video ad is reloaded onto that page and resumes from where it left off

at the previous tab. This ensures that video ads are enforced on the Chrome browser, and

video ads do not restart again and rather resume from previous tab when the USER switches

between tabs. Figure 6.3 describes the current tab video display mechanism.


Vid

eo

ele

men

t re

mo

ved

.

Rem

ove

d f

ram

e t

rack

ing

up

dat

e t

o b

ackgr

ou

nd

.

text

text

text

Tab

2:

con

ten

tscr

ipt.

js

Bac

kgr

ou

nd

Pag

e:

bac

kgr

ou

nd

.js

Tab

1:

con

ten

tscr

ipt.

js

v_ti

mer

en

ters

gra

ce p

eri

od

Sen

d v

ideo

dat

a to

cu

rren

t

tab

.

Sen

d v

ideo

dat

a to

Tab

1

Co

nte

nt

Scr

ipt

Get

vid

eo

dat

a fr

om

FR

AC

_S

ER

VE

R

Co

nte

nt

Scr

ipt

em

bed

s

vid

eo

in

to W

eb

Pag

e.

Tra

cks

vid

eo

fra

mes:

Vid

eo

is d

ivid

ed

in

to f

ram

es

&

up

dat

ed

to

th

e b

ack

gro

un

d

pag

e

Vid

eo

Sta

tus:

Fra

me 1

Vid

eo

Sta

tus:

Fra

me 2

Vid

eo

Sta

tus:

Fra

me 3

Cu

rren

t F

ram

e is

up

dat

ed

in

bac

kgr

ou

nd

web

sto

rage

.

CL

IEN

T s

wit

ches

fro

m

curr

en

t ta

b/o

pen

s n

ew

tab

or

clo

ses

curr

en

t ta

b.

Dete

cted

Eve

nt:

curr

en

t ta

b c

han

ged

.C

heck

s if

vid

eo

is

stre

amin

g.

If v

ideo

is

stre

amin

g, s

en

ds

vid

eo

dat

a an

d c

urr

en

t

fram

e t

o c

urr

en

t ta

b (

tab

2)

afte

r eve

nt.

Sen

d v

ideo

dat

a an

d c

urr

en

t

fram

e v

alu

e t

o t

ab 2

.

If v

ideo

is

stre

amin

g,

refr

esh

pag

e.

Vid

eo

str

eam

s fr

om

curr

en

t fr

ame. T

rack

s

vid

eo

an

d u

pd

ated

to

bac

kgr

ou

nd

pag

e.

Vid

eo

Sta

tus:

Fra

me 4

Vid

eo

Sta

tus:

Fra

me 5

Vid

eo

Sta

tus:

Fra

me 6

Vid

eo

Sta

tus:

Co

mp

lete

d

Cu

rren

t F

ram

e is

up

dat

ed

in

bac

kgr

ou

nd

web

sto

rage

.

Up

dat

e v

ideo

_w

atch

ed

to

1,

vid

eo

no

lo

nge

r st

ream

ing

Rem

ove

vid

eo

tag

s

fro

m w

eb

pag

e.

Rem

ove

vid

eo

tag

s

fro

m w

eb

pag

e.

Tim

er

exp

ires,

HT

TP

_V

AD

_N

OT

IFY

_R

EQ

sen

t to

FR

AC

_S

ER

VE

R

Vid

eo

ele

men

t re

mo

ved

,

vid

eo

sto

ps

pla

yin

g in

th

is

tab

. R

em

ove

d f

ram

e t

rack

ing

up

dat

e t

o b

ackgr

ou

nd

.

Fig

ure

6.3:

Curr

ent

Tab

Vid

eoD

ispla

y


6.1.4.2 Trigger button mechanism

To ensure CLIENTs use the Chrome browser and do not shift to a new browser or use an

incognito window, we implement a trigger button mechanism. Trigger buttons popup at

random intervals on the video ads and banner ads which requires the USER to click on these

ads. If the user does not use the Chrome browser on which these buttons popup, the user will

not be able to click on these trigger buttons and this will be detected by the FRAC SERVER

and user loses internet access.

6.1.5 JavaScript Obfuscator

Since the CLIENT APP is a browser extension which is implemented using JavaScript, it is

open source to the CLIENT, which poses a security concern. In order to hide the code, we

perform code obfuscation which conceals the logic of the code to prevent tampering using

JavaScript Obfuscator software [35].

6.2 HOST AP Implementation

The access points used in HOST AP implementation are CISCO Linksys WRT54GL and

Linksys E1200. We use dd-wrt firmware on these routers, as these are Linux-based, open

source, stable and flexible embedded firmware which provide easy handling and several func-

tionalities within framework of the router’s basic hardware platform.

The HOST AP software is developed in C and can be installed on embedded systems such

as wireless routers with small amounts of flash memory and RAM. Most commercial home

routers commonly have MIPS or MIPSEL architecture as discussed earlier. The routers

used in our implementation have MIPSEL architecture, as such the HOST AP software is

compiled to run on this platform.


6.2.1 Implementation Features

The HOST AP has to perform multiple operations and serve multiple CLIENTs at a time.

Our implementation is multithreaded using pthreads to handle multiple USER requests and

simultaneously send HTTP requests to the FRAC SERVER and CLIENTs. We use ipta-

bles API to dynamically allow and deny access to CLIENTs, provide firewall and CLIENT

isolation.

6.2.2 Router compatibility with dd-wrt

FRAC is based on the idea using existing infrastructure by creating HOST APs from most

wireless home routers being used today. Most Linux-based home routers like Linksys, Asus,

Netgear, Buffalo support dd-wrt today, though the extent of support varies. A detailed list

of routers is provided online [41] .

Since, there is a wide range of popular home routers that support dd-wrt, this will allow most

of the HOSTs to configure their wireless routers to act as HOST APs in the FRAC system,

at a small cost (cost of getting a suitable dd-wrt based home router which is around 40-60$

on the average) or no cost (if they already have a wireless router that supports dd-wrt).

6.2.3 Cross Compiling & MIPSEL architecture

We need to cross-compile the source code developed for the HOST AP into executable code

for MISPEL-based router firmware or compile the code in a native MIPSEL environment to

run it on the router. This is because the router is an embedded system which has limited

resources and does not have the capability to run a compiler or any development environment.

In our implementation, we cross-compile for MIPSEL target using an x86 host machine. We

use uClibc MIPSEL toolchain on Debian Linux x86 platform for cross-compiling to MIPSEL

executables [36] .


6.2.4 LibHTTPD Web-Server API

The CLIENT APP and FRAC SERVER send JSON based HTTP requests to the HOST AP.

Since the HOST AP is a layer 3 device, it does not have any in-built web-based access. So,

we need a web-server and web-client implementation on the HOST AP to send and receive

messages from other FRAC elements.

LibHTTPD provides basic web-server capabilities to embedded systems such as routers [37].

It is an open-source lightweight C library which handles static and dynamic server content

and simplifies creation of web based application interfaces at low overhead. In our imple-

mentation, we incorporate LibHTTPD 1.4 API functions to provide web-server capabilities

for the HOST AP while making minor modifications to support the FRAC system.

6.2.5 Implementing JUMP using JSON-C

Unlike the CLIENT APP which works on the application layer, we do not have native JSON

support to parse and generate JSON. In order to provide JSON support in C, we use JSON-C

package which implements a lightweight reference counting object model [38]. Using JSON-

C, we can construct JSON objects in C, parse and generate JSON. JSON-C API is used to

implement JUMP functions, construct JUMP messages and parse received JUMP messages.

6.2.6 Wifidog Iptables API and Utility functions

Wifidog is a captive portal solution, which we discussed in the related work section. Wifi-

dog gateway was developed using C and is easily embeddable into routers. In our FRAC

HOST AP implementation, we use the list API functions from Wifidog for CLIENT database

operations and Wifidog utilities [25] such as functions to get the MAC and IP address of

interfaces and detect the external interface automatically. Further, we also modify the ipta-

bles functions and firewall APIs from Wifidog source code for compatibility with the FRAC


system.

6.2.7 HTTPClient Web-Client API

To provide web-client capabilities to the HOST AP, we implemented a web-client API in C,

which is lightweight and can be easily integrated into the FRAC system. This web client

allows us to send HTTP requests to CLIENT APPs and FRAC SERVER.

Chapter 7

Evaluation

In this chapter, we evaluate the FRAC system model, design and implementation. We

broadly assess our design choices and discuss how these translate into better system perfor-

mance and quality characteristics.

7.1 Model Evaluation

The proposed model for providing free Wi-Fi to the public is self-sustainable. The evaluation

of this model is based on the assumption that design requirements are clearly satisfied by

the implementation. A self-sustainable system is established based on the following.

• Providing high value creative targeted advertising. Using foolproof mechanisms to

enforce users to participate in these advertising campaigns. Making FRAC system an

effective medium of advertising, which will provide increased revenue.

• Low or No Cost of Deployment. Potential HOSTs can easily convert their wireless

routers to act as HOST APs in the FRAC system. They are provided with suitable

benefits for opening up their access points for public use. DD-WRT firmware can be

72

Lakshman Swaroop Babu Chapter 7. Evaluation 73

loaded in most Linux-based routers and installing HOST AP software on these routers

is just a few steps away.

• Free CLIENT and HOST software with benefits. This motivates CLIENTs and HOSTs

to be part of the framework, increasing the number of USERs and HOSTs, and thereby

boosting revenue.

Potential Challenges in this model include the following.

• FRAC becomes self-sustainable based on the assumption that it creates an effective

advertising medium. This becomes a challenge as advertising trends and preferences

tend to differ across communities and locations. Revenues through online advertising

may not be substantial for self-sustenance.

• User Terms of Service may be a critical barrier for HOSTs to open up their internet for

public use. Like FON, we would need to establish agreements with ISPs/broadband

providers, so that HOSTs do not breach the terms of service by sharing their excess

bandwidth. This implies that significant portion of the revenue may be shared with

ISPs and broadband providers, thus reducing self-sustenance.

Nevertheless, despite these potential challenges our model will substantially offset costs of

deployment of a free public Wi-Fi system unlike any other.

7.2 Design Evaluation

In this section, we evaluate the design choices and discuss the potential weaknesses in the

design and suggest future enhancements to address these problems in the next chapter. We

evaluate design choices mainly with the following factors in mind - scalability, security, and

reliability.


• Designing a message exchange format which is lightweight, secure and provides reduced

amount of message and data exchange is critical. Two most popular commonly used

data exchange formats are JSON and XML, and the choice is application dependent.

We use JSON over XML to create a unified message exchange format mainly because

JSON is lightweight, uses simple formatting, has terse syntax and matches the data

models supported by most programming languages such as scalar data types, arrays and

objects. Even though, JSON is relatively new compared to XML, the support required

for our framework does not differ much between JSON and XML [40]. Since JSON

is natively supported in JavaScript [40], it makes the CLIENT APP implementation

simpler. Moreover, because of its lightweight implementation, JSON is better suited

for routers which have limited resources [38]. JSON parsing using eval() function

poses some potential security threats [40], which is resolved by using JSON.parse()

and JSON.stringify() functions which parse only JSON and not any other JavaScript

code.

JUMP is simply JSON with a unified set of fields for communication between the FRAC

elements. We do not use SOAP as it relies on XML for its message format which makes

it heavy and not suited for our application [8]. Making JUMP more RESTful may

provide some advantages at the cost of increased implementation complexity. REST

provides certain advantages which may not be required for our framework and JUMP

provides a much simpler implementation.

• The functional complexity at the HOST AP is reduced by design as the routers

have limited resources and as this improves the security of the system. This ensures

FRAC SERVER has control over the framework, so that HOST APs and CLIENTs

cannot dishonestly gain benefits from the framework. Except CLIENT authentica-

tion and expiry, all the other mechanisms are directly handled between CLIENT and

FRAC SERVER such as ADM, billing. This reduces the load and accountability of

the HOST AP providing more robustness.


• ADM design is implementation specific with different limitations depending on ar-

chitecture and platform. This reduces CLIENT APP portability and usability across

different devices.

• Designing Foolproof Mechanisms makes FRAC more reliable, secure and scalable.

FRAC SERVER responds to advertisement requests sent by CLIENTs only during

their grace period preventing unnecessary advertisement delivery. Changing banner

advertisement locations and enforcing video advertisements using trigger mechanisms

and current tab persistent video ad display are mechanisms which make FRAC more

reliable and secure for advertising and prevents bots.

• Suggested security features include selectively performing encryption and decryption

(TLS/HTTPS) between CLIENT APP and FRAC SERVER for critical messages. Au-

thentication mechanisms such as digital signatures and timestamps can be used for the

remaining messages. By selectively encrypting only critical messages, we can reduce

the system overhead and significantly improve scalability.

We also use firewalls to provide isolation and access restrictions. We authenticate

CLIENTs only after they connect to the HOST AP, which allows malicious CLIENTs

access to router. Providing layer 2 security, authenticating CLIENT on trying to

connect to HOST AP is a much challenging task [43].

7.3 Implementation Evaluation

We evaluate our prototype implementation in this section and discuss the areas for improve-

ment.

• Choosing the right firmware is an important implementation choice, as firmware sup-

ports different features which aids the design and extensibility of the system. Main

factors to be taken into consideration when choosing the firmware is router support


and support for functional features used in HOST AP software. Over the wide range of

open-source wireless router firmware available, dd-wrt and OpenWrt remain popular

choices due to the overwhelming router support for these firmware projects which pro-

vide the capability to install HOST AP software on most of the Linux-based wireless

home routers [42].

For our prototype implementation, we use dd-wrt because the base firmware on dd-wrt

is more functional compared to OpenWrt and dd-wrt has excellent router support [41].

It may be a good choice to use OpenWrt for creating production software, as it has

excellent feature support and extensibility.

• The CLIENT APP implemented is Chrome browser-specific and has to be modified

or recreated to support other popular browsers. CLIENT APP has more implementa-

tion specific design features, for example CLIENT APP design has to be modified for

smartphones as CLIENTs mostly use apps to access internet rather that the browser

in smartphones.

• CLIENT APP implementation poses certain serious security issues [44][45][46]. Since

CLIENT APP is written in JavaScript, the source code can be viewed by anyone us-

ing the extension. This will allow malicious clients to reconstruct the application to

function differently and remove all foolproof mechanisms and get around the adver-

tisements. We obfuscate the JavaScript using standard tools and software, which will

conceal the real meaning and intent of the JavaScript code. Moreover, using content-

scripts on CLIENT APP leads to cross-site scripting vulnerabilities such as retrieving

HTTP content on an HTTPS page because HTTP content might have been corrupted

by a man-in-the-middle over the network [44] [45] .

• The HOST AP software has to be cross-compiled for router specific architecture. Since

every router model is different, it has different dd-wrt firmware versions which reduces

the portability. Further, the HOST has complete control over the HOST AP, it can

act maliciously and make changes to the CLIENT network configuration. In order to


prevent that certain settings have to be made immutable and have to be hard-coded

into the firmware.

• The main goals for HOST AP software implementation includes stability, scalability,

and robustness. The HOST AP is developed in C which is lightweight, efficient and can

be cross-compiled to support different platforms. Our implementation provides concur-

rent execution via multithreading using pthreads with conservative memory handling

and error checking, message validation which improves performance and scalability.

The current firewall implementation does not have support for IPv6. Areas for im-

provement include standardizing API functions, improving firewall implementation.

Chapter 8

Future Work

8.1 Future Work on FRAC Prototype Software

To extend the current implementation of our prototype model, we are currently working

on the following improvements which include the FRAC SERVER implementation, firewall

enhancements, QoS, security, billing mechanism implementation.

8.2 App-based CLIENT APP Design

We have designed and implemented a browser-based CLIENT APP in this prototype. Sub-

stantial traffic in the internet nowadays comes from smart devices and Wi-Fi has been an

integral feature on these device for several years. Designing app-based CLIENT APP allows

us to target a much larger and affordable USER base. The CLIENT APP design for smart-

phones and tablets has to be designed to support app-based web access, rather than using

web browsers.

An ground plan of the overall design of the Android app-based CLIENT APP is shown in the

figure, where the CLIENT APP interrupts the currently active app when the timer expires

78

Lakshman Swaroop Babu Chapter 8. Future Work & Vision 79

using startActivity() which allows the CLIENT APP to be placed at the top of the activity

stack [47].

USER activity

interrupted by

CLIENT_APP

CLIENT_APP OTHER_APPsFRAC NETWORK

CLIENT Authentication

HTTP_VAD_REQ to

FRAC_SERVER

text

HOST AP

timer expires

Ad DisplayedHTTP Notification Requests sent

to FRAC_SERVER

timer starts

startActivity()

*Currently active APP on the device is shaded.

Figure 8.1: Oveview of an App-based CLIENT APP design

8.3 Plugins: NPAPI vs. NativeClient (NaCl)

CLIENT APP implementation uses Chrome extensions is open-source, which poses an im-

portant security concern. A common way to include proprietary code in the extension is to

use Netscape Plugin Application Programming Interface (NPAPI) plugins with the extension

which allows us to call native binary code from JavaScript [50].

NPAPI poses an important security threat as the code running in a NPAPI plugin has full

permissions and is not shielded from malicious input from the browser platform. Cross-side


scripting attacks become more common when working with content scripts and AJAX HTTP

requests which process input from questionable sources. Allowing the plugin unrestricted

access poses a big security vulnerability, may allow attackers to install malicious software on

USER’s machine.

Native Client is a sandboxing technology used to run native code securely on the browser. It

expands the scope of web programming beyond JavaScript, allowing web-based applications

to achieve close to native system performance [48] [49]. A sandbox provides a virtual isolated

environment with controlled resources for guest programs to run in. NaCl uses a double

sandbox to protect system resources. A web application which uses NativeClient will have

JavaScript, HTML and CSS along with a sandboxed NativeClient module bridged by Pepper

API. Pepper API provides a communication interface between NaCl modules and JS code

to create and use browser resources. Further, NativeClient allows same level of portability

for C and C++ as JavaScript.

Bridge

Pepper

Native Client Module

Browser

HTML, CSS, JavaScript

Figure 8.2: Native Client Overview

Using NaCl can provide a solid way to embed proprietary code in the CLIENT APP with

improved security features. This will allow the CLIENT APP to more control in shielding


loopholes in the ADM and authentication mechanisms.

8.4 Automatic Network Discovery and Selection

CLIENT has to manually choose a HOST AP in the FRAC network which poses security

concerns, as a malicious entity can act as a HOST AP in the FRAC network and get crit-

ical data or harm the user. Automatic network discovery and selection feature allows the

CLIENT APP to identify and associate with the HOST AP automatically without any inter-

vention from the USER, ensuring the CLIENT connects to a valid HOST AP. This feature

is currently being released in Wi-Fi certified Passpoint devices [16].

8.5 From Prototype Software to Production Software

There are other challenges apart from the standard steps involved in converting a prototype

to a production software, such as error-handling, input validation, unit testing, solid API

design, logging and documentation. Creating an effective method to automatically update

software across CLIENTs and HOSTs in the framework provides the flexibility to make

changes to FRAC system. Autoconf is an extensible suite which uses shell scripts to au-

tomatically configure software packages to adapt them to many Unix-based systems with

different OS and features [51]. Using autotools to install HOST AP software on different

router architectures can improve portability to an extent.

8.6 Effective Advertising

Our efforts till now have focused on building a functional prototype for this model. Creating

an effective advertising medium is an important requirement for self-sustainability of this

framework. This can be achieved by designing high value creative advertising schemes using


location-based advertising and supporting new advertisements and marketing methods like

surveys, rich media advertisements and interactive advertising schemes. Providing more

flexibilities to USERs can improve the confidence on the framework in the market. For

example, allowing users a time window over which they can choose to watch advertisements,

so that they are not interrupted frequently.

Chapter 9

Conclusion

FRAC is a self-sustainable advertisement-based community network sharing framework which

provides users free internet access. We provided a detailed overview of the framework and

formulated the quality and functional requirements to satisfy user expectations, efficiency

and ensure the system functions correctly. This thesis describes the main features of the

FRAC system such as CLIENT and HOST authentication, advertisement delivery mech-

anism, quality of service, security, unified message format etc. based on which an overall

design of the key elements of our framework is formulated.

A prototype implementation of FRAC is detailed in this thesis. We implemented a Chrome

browser extension to support FRAC on browser-based CLIENT devices like laptops and de-

veloped an embeddable HOST gateway software using C on dd-wrt firmware for Linux-based

routers. We evaluated our system model, design and implementation which indicates FRAC

is self-sustainable, lightweight and scalable overall. Further, our evaluation also indicates

potential challenges such as portability due to platform specific design, security issues of

an open source CLIENT APP, for which we suggest additional solutions and enhancements

in the future work section. Overall this thesis provides a proof-of-concept version of the

proposed model, and provides insight into potential barriers, suggests solutions and future

enhancements to develop the framework.

83

Bibliography

[1] WBA Industry Report, Global developments in public WiFi, http://www.wballiance.

com/resource-centre/global-developments-wifi-report.html, Nov, 2012.

[2] Bar, F., & Park, N. (2006). Municipal Wi-Fi networks: The goals, practices, and policy

implications of the US case. Communications & Strategies, 61(1), 107-125.

[3] Understanding the Role of Managed Public Wi-Fi in Today’s Smartphone User Experi-

ence, Informa Telecoms & Media, Feb, 2013

[4] Understanding today’s smartphone user, white paper, Informa Telecoms & Media, Au-

gust, 2012

[5] Chrome extensions. http://developer.chrome.com/extensions

[6] S. C. C. Rita J. Cressy, “Iptables,” LeRoy D. Cressy, 2004

[7] Iptables. http://linux.die.net/man/8/iptables

[8] Kumar, Pavan, et al. “Comparing Performance of Web Service Interaction Styles: SOAP

vs. REST.” Journal of Information Systems Applied Research 6.1 (2013): 4.

[9] 2012 Internet Advertising Revenue Full-Year Report, http://www.iab.net/

AdRevenueReport, 2012

[10] Digital Video Ad Format Guidelines & Best Practices, http://www.iab.net/

guidelines/508676/digitalvideo/DV_Guidelines, May 2008.

84

Lakshman Swaroop Babu Bibliography 85

[11] Broder, Andrei, Vanja Josifovski, and Jayavel Shanmugasundaram. “Introduction to

display advertising: a half-day tutorial.” Proceedings of the fourth ACM international

conference on Web search and data mining. ACM, 2011.

[12] Toolchains. http://www.linux-mips.org/wiki/Toolchains

[13] Introduction to cross-compiling for Linux http://landley.net/writing/docs/

cross-compiling.html

[14] DD-WRT. http://www.dd-wrt.com

[15] WISPr 2.0, Wireless Broadband Alliance, March 2010.

[16] Wi-Fi CERTIFIED Passpoint, white paper, Wi-Fi Alliance, updated June 2012

[17] Aboba, Bernard, et al. “RFC 3748-Extensible authentication protocol (EAP).” Network

Working Group (2004).

[18] 802.1X: Port-Based authentication standard for network access control (NAC), white

paper, Juniper Networks, Inc., 2010

[19] Rigney, C., Willens, S., Rubens, A. and W. Simpson, ”Remote Authentication Dial In

User Service (RADIUS)”, RFC 2865, June 2000

[20] Rigney, C. “RFC 2866: RADIUS Accounting.” Network Working Group June (2000).

[21] RADIUS Protocol Security and Best Practices, http://technet.microsoft.com/

en-us/library/bb742489.aspx, Jan 2002.

[22] Calhoun, P., et al. “RFC 3588-Diameter Base Protocol.” Network Working Group

(2003).

[23] Chillispot.http://www.chillispot.info


[24] Brunato, Mauro, and Danilo Severina. ”WilmaGate: a new open access gateway for

hotspot management.” Proceedings of the 3rd ACM international workshop on Wireless

mobile applications and services on WLAN hotspots. ACM, 2005.

[25] Wifidog captive portal suite. http://dev.wifidog.org

[26] PacketFence: Open Source NAC .http://www.packetfence.org

[27] CoovaChilli.http://coova.org/CoovaChilli

[28] Pfsense Open Source Firewall Distribution. http://www.pfsense.org

[29] M0n0wall: Free embedded firewall software.http://m0n0.ch/wall

[30] EasyHotspot, open source Hotspot Management System. http://easyhotspot.inov.

asia

[31] Fon. www.fon.com

[32] JSON. http://www.json.org

[33] Multiple WLANs. http://www.dd-wrt.com/wiki/index.php/Multiple_WLANs

[34] How to setup multiple BSSIDs using DD-WRT. http://www.pennock.nl/dd-wrt/

Multiple_BSSIDs.html

[35] JavaScript Obfuscator. http://javascript-source.com

[36] MIPSEL Cross-compiler. http://www.uclibc.org/toolchains.html

[37] LibHTTPD : Embedded web server library http://www.hughes.com.au/products/

libhttpd/libhttpd.pdf

[38] JSON-C - A JSON implementation in C. https://github.com/json-c/json-c/wiki

[39] Linux Firewalls Using iptables http://www.linuxhomenetworking.com/wiki/index.

php/Quick_HOWTO_:_Ch14_:_Linux_Firewalls_Using_iptables


[40] An Introduction to JavaScript Object Notation (JSON). http://msdn.microsoft.

com/en-us/library/bb299886.aspx

[41] List of DD-WRT supported devices. http://www.dd-wrt.com/wiki/index.php/

Supported_Devices

[42] Heldenbrand, David, and Christopher Carey. “The Linux router: an inexpensive alter-

native to commercial routers in the lab.” Journal of Computing Sciences in Colleges 23.1

(2007): 127-133.

[43] Choi, J.; Sang-Yoon Chang; Diko Ko; Yih-Chun Hu, “Secure MAC-Layer Protocol for

Captive Portals in Wireless Hotspots,” Communications (ICC), 2011 IEEE International

Conference on , vol., no., pp.1,5, 5-9 June 2011

[44] Barth, Adam, et al. “Protecting browsers from extension vulnerabilities.” 17th Network

and Distributed System Security Symposium. 2010.

[45] Liu, Lei, et al. “Chrome extensions: Threat analysis and countermeasures.” Proceeding

of the Network and Distributed System Security Symposium, NDSS. 2012.

[46] Carlini, Nicholas, Adrienne Porter Felt, and David Wagner. “An evaluation of the google

chrome extension security architecture.” Proceedings of the 21st USENIX Conference on

Security. 2012.

[47] Activity class in Android.

[48] Native Client. https://developers.google.com/native-client

[49] Yee, B.; Sehr, D.; Dardyk, G.; Chen, J.B.; Muth, R.; Ormandy, T.; Okasaka, S.; Narula,

N.; Fullagar, N., “Native Client: A Sandbox for Portable, Untrusted x86 Native Code,”

Security and Privacy, 2009 30th IEEE Symposium on , vol., no., pp.79,93, 17-20 May

2009


[50] Netscape Plugin Application Programming Interface (NPAPI). https://wiki.

mozilla.org/NPAPI http://developer.android.com/reference/android/app/

Activity.html

[51] Calcote, John. Autotools: A Practitioner’s Guide to GNU Autoconf, Automake, and

Libtool. No Starch Press, 2010.

Appendix A

JSON Unified Messaging Protocol

The fields in the JSON schema are the following.

client_id : CLIENT_APP Unique Identifier

status : Response Status/Result of REQUEST message.

message : Message Type

protocol_version : Protocol Version Number

software_version : Software Version Number

session_id : Unique Identifier for every REQ-RESP

server_id : FRAC_SERVER Unique Identifier

vad_id : Video AD Unique Identifier

vad_time : Duration of Video ad received

v_timer : Set Video AD Timer value

b_timer : Set Banner AD Timer value

ap_id : HOST AP Unique Identifier

JSON Schema

defaults : {

"client_id" : {

"type" : "string",


},

"message" : {

"type" : "number",

89

Lakshman Swaroop Babu Appendix 90

"value" : "10"

},

"protocol_version" : {

"type" : "string",

"value" : "1.1"

},

"software_version" : {

"type" : "string",

"value" : "1.0"

},

"session_id" : {

"type" : "string",

"value" : "sid"

}

}

server: {

"server_id" : {

"type" : "string",

"value" : "sid"

},

"v_timer" : {

"type" : "number",

"value" : "0"

},

"b_timer" : {

"type" : "number",

"value" : "0"

},

"vad_time" : {

"type" : "number",

"value" : "0"

},

"vad_id" : {

"type" : "string",

"value" : "vid"

},

}

ap: {

"ap_id" : {

"type" : "string",

"value" : "apid"


}

}

Message Codes

Nodes Src Dst Message Type Abbreviation Code

Client-APC A Client Authentication Request HTTP CLIENT AUTH REQ 10

A C Client Authentication Response HTTP CLIENT AUTH RESP 13

AP-Server

A S AP Authentication Request HTTP AP AUTH REQ 20

S A AP Authentication Response HTTP AP AUTH RESP 21

S A Server Expiry Request HTTP EXP REQ 22

A S Server Expiry Response HTTP EXP RESP 23

A S AP Keepalive Request HTTP AP KA REQ 24

A S AP Keepalive Response HTTP AP KA RESP 25

Client-Server

C S Video Advertisement Request HTTP VAD REQ 30

S C Video Advertisement Response HTTP VAD RESP 31

C S Video watched Notification Request HTTP VAD NOTIFY REQ 32

S C Video watched Notification Response HTTP VAD NOTIFY RESP 33

C S Banner Advertisement Request HTTP BAD REQ 34

S C Banner Advertisement Response HTTP BAD RESP 35

*Note: C indicates CLIENT APP, S indicates FRAC SERVER and A indicates HOST AP

Status codes

Status Code Description

1xxx Success. Valid request.

2xxx Unauthorized request.

3xxx CLIENT APP error.

4xxx HOST AP error. (FRAC SERVER)

5xxx FRAC SERVER error. (HOST AP)

6xxx Bad request. Request could not be understood

due to invalid syntax.


Message Formats

HTTP_CLIENT_AUTH_REQ

{

"protocol_version": "1.1",

"software_version": "1.0",

"session_id": "cl2h03t1",

"message": 10,

"client_id": "6ge3T9pf"

}

HTTP_CLIENT_AUTH_RESP

{



"session_id": "cl2h03t1",

"message": 13,

"status": 1000,

"ap_id": "aw54fg31",

"server_id": "s35v351d",

"client_id": "6ge3T9pf",

"v_timer": 10,

"b_timer": 2

}

HTTP_AP_AUTH_REQ

{



"session_id": "h03t2fs5",

"message": 20,




}

HTTP_AP_AUTH_RESP

{



"session_id": "h03t2fs5",

"message": 21,

"status": 1000,




"v_timer": 10,

"b_timer": 2

}

HTTP_EXP_REQ

{



"session_id": "cl3xp15y",

"message": 22,




}

HTTP_EXP_RESP

{



"session_id": "cl3xp15y",

"message": 23,

"status": 1000,




}


HTTP_AP_KA_REQ

{



"session_id": "k39a11v3",

"message": 24,


"ap_id": "aw54fg31"

}

HTTP_AP_KA_RESP

{



"session_id": "k39a11v3",

"message": 25,

"status": 1000,


"ap_id": "aw54fg31"

}

HTTP_VAD_REQ

{



"session_id": "vad53q5t",

"message": 30,



}

HTTP_VAD_RESP

{




"message": 31,

"status": 1000,



"vad_time": 36,

"vad_id": "qw12er34"

}<video advertisement data>

HTTP_VAD_NOTIFY_REQ

{




"message": 32,



"vad_id": "qw12er34"

}

HTTP_VAD_NOTIFY_RESP

{




"message": 33,

"status": 1000,



"v_timer": 7

}


HTTP_BAD_REQ

{



"session_id": "bads3q5t",

"message": 34,



}

HTTP_BAD_RESP

{



"session_id": "bads3q5t",

"message": 35,

"status": 1000,



"b_timer": 1

}<banner advertisement data>

Date post:	02-Dec-2018
Category:	Documents
Upload:	doankhanh
View:	241 times
Download:	1 times

FRAC: Design and Implementation of an Advertisement-based ... · FRAC: Design and Implementation of...

Documents