Adaptive Counteraction Against Denial of Service Attack1162616/... · · 2017-12-04DEGREE PROJECT...

IN DEGREE PROJECT ELECTRICAL ENGINEERING,SECOND CYCLE, 30 CREDITS

, STOCKHOLM SWEDEN 2017

Adaptive Counteraction Against Denial of Service Attack

SYAFIQ AL ATIIQ

KTH ROYAL INSTITUTE OF TECHNOLOGYSCHOOL OF ELECTRICAL ENGINEERING

Preface

Õ�æk�

��QË�@ á

�

�Ô

�g��QË

�@ é�

��<Ë

�@ Õ

�æ��.�

I would like to express my gratitude to Marco Tiloca and Rikard Höglundas my supervisors from RISE SICS, for your patience guiding me and an-swering all my questions for the past 7 months. It was an enjoyable learningexperience doing research in cutting-edge technology with you. Furthermore,to Prof. Viktoria Fodor from KTH, who has been an excellent supervisor andexaminer. I thank you for your guidance and feedback throughout my thesiswork.

To my super strong Mom and Dad, for all the life lessons through inter-national call every weekend. I know, I will always be your little boy. To mybig brothers Mahuddin, Alan, and Yusron who introduced me the path to theengineering world. To LPDP, who has been very generous sponsoring mystudy. And last, to my wife, Amirinnisa, who has to deal with my crankinesswhen my code did not work as expected. I would never have been able to finishthis thesis without her support.

1

Abstract (English)

The Internet of Things (IoT) is the next generation of networked societywhere billions of, everyday-life, devices are directly connected to the Inter-net and able to communicate with each other. In particular, the ConstrainedApplication Protocol (CoAP) has become the de-facto IoT standard for com-munication at the application layer, as a lightweight web transfer protocolaffordable also for resource-constrained platforms. However, as IoT devicesare directly connected to the Internet, they are especially vulnerable to anumber of security attacks including Denial of Service (DoS), which can se-riously worsen their performance and responsiveness, and even make themtotally unavailable to serve legitimate requests.

In this Master’s Thesis project, we have developed a cross-layer andcontext-aware approach that adaptively counteracts DoS attacks againstCoAP server devices, by dynamically adjusting their operative state accord-ing to the attack intensity. This considerably limits the impact of DoS at-tacks and preserves service availability of victim devices to the best possibleextent. The proposed approach leverages a trusted Proxy that adaptivelyshields victim devices, while effectively forwarding and caching messages ifneeded. We have made a proof-of-concept implementation of our solutionfor the Californium framework and the CoAP protocol, and experimentallyevaluated its effectiveness in counteracting DoS and preserving availabilityof devices under attack.

This Master’s Thesis project has been conducted in collaboration withRISE SICS, a research institute for applied information and communicationtechnology in Sweden.

Keywords:Security, Denial of Service, Adaptive Counteraction, Cross-Layer, CoAP, In-ternet of Things.

2

Abstract (Swedish)

Sakernas Internet (IoT) är nästa generations nätverkssamhälle där mil-jarder av, vardagliga, enheter är direkt anslutna till Internet och har möj-lighet att kommunicera med varandra. Särskilt har CoAP, ett lättviktspro-tokoll för webbtrafik som även fungerar för plattformar med begränsaderesurser, blivit Sakernas Internets standard för kommunikation på applika-tionslagret. Men eftersom IoT-enheter är direkt anslutna till Internet så ärde också speciellt utsatta för ett antal säkerhetsattacker, inklusive DoS, somkan försämra deras prestanda och mottaglighet avsevärt och i värsta fall göradem helt otillgängliga för legitima förfrågningar.

I detta examensarbete har vi utvecklat en lageröverskridande och kon-textmedveten metod som adaptivt motverkar DoS attacker mot CoAP serveren-heter genom att dynamiskt anpassa enhetens operativa tillstånd i enlighetmed attackintensiteten. Detta begränsar DoS-attackers påverkan på en-heterna avsevärt samtidigt som det bibehåller tillgänglighet för tjänster påutsatta enheter till största möjliga utsträckning. Den föreslagna metodenutnyttjar en betrodd proxy som adaptivt skyddar utsatta enheter, samtidigtsom den effektivt vidarebefordrar och sparar meddelanden om så behövs. Idetta arbete har vi skapat en proof of concept-implementation av vår lösningför Californium-ramverket och CoAP protokollet. Arbetet har utvärderatsexperimentellt för att undersöka lösningens effektivitet när det gäller att mo-tarbeta DoS-attacker samt hur den bibehåller enheters tillgänglighet underattacker.

Detta uppsatsprojekt har utförts i samarbete med RISE SICS som ärett forskningsinstitut för tillämpad informations- och kommunikationstekniki Sverige.

Nyckelord:Säkerhet, Överbelastningsattacker, Adaptiv Motverkan, Lageröverskridande,CoAP, Sakernas Internet

3

List of Acronyms

6LoWPAN IPv6 over Low-Power Wireless Personal Area Networks

CARL Clustered Adaptive Rate Limiting

CoAP Constrained Application Protocol

CPU Central Processing Unit

DDoS Distributed Denial of Service

DoS Denial of Service

DTLS Datagram Transport Layer Security

GPU Graphics Processing Unit

HTTP HyperText Transfer Protocol

IETF Internet Engineering Task Force

IoT Internet of Things

IP Internet Protocol

IPv6 Internet Protocol version 6

KDC Key Distribution Center

M2M Machine-to-Machine

MAC Message Authentication Code

PRF Pseudo Random Function

4

5

QoS Quality of Service

RAM Random-Access Memory

REST Representational State Transfer

RFC Request for Comments

SHA Secure Hash Algorithm

SMACK Short Message Authentication ChecK

SMS Short Message Service

TCP Transmission Control Protocol

TLS Transport Layer Security

TLV Type-Length-Value

UDP User Datagram Protocol

URI Uniform Resource Identifier

WSN Wireless Sensor Network

List of Figures

2.1 CoAP Message Format . . . . . . . . . . . . . . . . . . . . . . 202.2 Californium Architecture Based on [1] . . . . . . . . . . . . . . 232.3 Message Flights for Full Handshake . . . . . . . . . . . . . . . 252.4 CoAP Message with Short MAC . . . . . . . . . . . . . . . . . 28

3.1 Application Scenario . . . . . . . . . . . . . . . . . . . . . . . 32

4.1 Network Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 354.2 Server Communication Stack . . . . . . . . . . . . . . . . . . . 364.3 Server state machine . . . . . . . . . . . . . . . . . . . . . . . 374.4 CoAP Message with Additional Information for Adaptive Ap-

proach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6.1 Measurement scenario . . . . . . . . . . . . . . . . . . . . . . 58

7.1 Round Trip Time AC0 . . . . . . . . . . . . . . . . . . . . . . 637.2 Round Trip Time AC6 . . . . . . . . . . . . . . . . . . . . . . 647.3 Round Trip Time AC60 . . . . . . . . . . . . . . . . . . . . . 657.4 Round Trip Time AC120 . . . . . . . . . . . . . . . . . . . . . 667.5 Round Trip Time AC180 . . . . . . . . . . . . . . . . . . . . . 677.6 First Measurement of Round Trip Time AC180 . . . . . . . . 697.7 Second Measurement of Round Trip Time AC180 . . . . . . . 707.8 Time spent on each phase . . . . . . . . . . . . . . . . . . . . 717.9 Reception Pattern AC6 . . . . . . . . . . . . . . . . . . . . . . 737.10 Reception Pattern AC180 . . . . . . . . . . . . . . . . . . . . 747.11 Memory Utilization . . . . . . . . . . . . . . . . . . . . . . . . 757.12 CPU Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . 76

6

List of Tables

4.1 CoAP Message Format with Additional Field . . . . . . . . . 39

7

Contents

List of Acronyms 4

1 Introduction 111.1 Problem Statements . . . . . . . . . . . . . . . . . . . . . . . 121.2 Related Works . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.3 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.3.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . 161.3.2 Benefits, Ethics and Sustainability . . . . . . . . . . . 16

1.4 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.5 Report Structure . . . . . . . . . . . . . . . . . . . . . . . . . 17

2 Background 182.1 CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.1.1 Message Format . . . . . . . . . . . . . . . . . . . . . . 192.1.2 Interaction Model . . . . . . . . . . . . . . . . . . . . . 212.1.3 CoAP Proxy . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2 Californium . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.3 DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.3.1 Handshake . . . . . . . . . . . . . . . . . . . . . . . . . 252.3.2 Packet Loss Handling . . . . . . . . . . . . . . . . . . . 262.3.3 Reordering . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.4 SMACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.4.1 Message Format . . . . . . . . . . . . . . . . . . . . . . 272.4.2 Short MAC Computation . . . . . . . . . . . . . . . . 282.4.3 Key Derivation Procedure . . . . . . . . . . . . . . . . 29

3 Adversary Model and Application Scenario 313.1 Adversary Model . . . . . . . . . . . . . . . . . . . . . . . . . 31

8

Contents 9

3.2 Application Scenario . . . . . . . . . . . . . . . . . . . . . . . 31

4 Adaptive Counteraction Protocol 344.1 Network Architecture . . . . . . . . . . . . . . . . . . . . . . . 344.2 Invalid Messages Detection . . . . . . . . . . . . . . . . . . . . 354.3 Server State Machine . . . . . . . . . . . . . . . . . . . . . . . 374.4 Synchronization Message . . . . . . . . . . . . . . . . . . . . . 384.5 Server Behaviors . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.5.1 Client Perspective . . . . . . . . . . . . . . . . . . . . . 404.5.2 Server Perspective . . . . . . . . . . . . . . . . . . . . 42

4.6 Server State Update and Transition . . . . . . . . . . . . . . . 434.6.1 Normal State . . . . . . . . . . . . . . . . . . . . . . . 434.6.2 Protected State . . . . . . . . . . . . . . . . . . . . . . 454.6.3 Off State . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5 Implementation of Adaptive Counteraction Protocol 495.1 Invalid Messages Counter . . . . . . . . . . . . . . . . . . . . . 495.2 DoS Reaction Module . . . . . . . . . . . . . . . . . . . . . . 50

5.2.1 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.2.2 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.3 KDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.4 Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.5 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6 Evaluation Setup 576.1 Testing Environment . . . . . . . . . . . . . . . . . . . . . . . 58

6.1.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . 586.1.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . 596.1.3 Adversary . . . . . . . . . . . . . . . . . . . . . . . . . 596.1.4 Proxy/KDC . . . . . . . . . . . . . . . . . . . . . . . . 596.1.5 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.2 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . 606.2.1 Scope and Scenario . . . . . . . . . . . . . . . . . . . . 606.2.2 Tested Protocols . . . . . . . . . . . . . . . . . . . . . 606.2.3 Configuration . . . . . . . . . . . . . . . . . . . . . . . 606.2.4 Attack Configuration . . . . . . . . . . . . . . . . . . . 61

Contents 10

7 Results and Discussion 627.1 Round Trip Time . . . . . . . . . . . . . . . . . . . . . . . . . 62

7.1.1 Tests Performed . . . . . . . . . . . . . . . . . . . . . . 627.1.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

7.2 Time on Each Phase . . . . . . . . . . . . . . . . . . . . . . . 707.2.1 Tests Performed . . . . . . . . . . . . . . . . . . . . . . 707.2.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

7.3 Response Reception Pattern . . . . . . . . . . . . . . . . . . . 727.3.1 Tests Performed . . . . . . . . . . . . . . . . . . . . . . 727.3.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

7.4 CPU and Memory Utilization . . . . . . . . . . . . . . . . . . 747.4.1 Tests Performed . . . . . . . . . . . . . . . . . . . . . . 747.4.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

7.5 Experiments Conclusion . . . . . . . . . . . . . . . . . . . . . 77

8 Conclusion and Future Work 788.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 788.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Bibliography 84

Appendix A Underclocking Raspberry Pi 3 85

Chapter 1

Introduction

According to Ericsson Mobility Report, by 2022 the world will have 29billion connected devices [2]. This scenario is commonly referred by the termInternet of Things, where every device can harness the connection to theInternet or with other devices [3][4]. The Internet of Things will changethe human paradigm of computer networks, as it is shifting from computerand mobile-centered paradigm to a scenario where anything that can benefitfrom connectivity is available on the Internet. Furthermore, sensors (whichbecomes also Internet connected) combined with machine learning and an-alytic techniques make it easier and more convenient to automate most ofour daily tasks. Smart farming, manufacturing automation, and e-healthare some examples of how IoT can benefit our lives, not only from a tech-nological perspective, but also from a social and economical point of view.Considering Moore’s law "the number of transistors in a dense integrated cir-cuit doubles approximately every two years", the development of the Internetof Things will accelerate over time, due to the reduction of prices and theincreasing capabilities of IoT hardware platforms. In particular, we couldexpect lower price tag solution in the IoT in the coming years. Finally, asInternet technology is getting mature, it provides the basic foundation tobuild connected world in a more solid way. This make the IoT grow strongersince the foundation technologies that support them is already mature.

On the other hand, many IoT devices are built on constrained hardwareplatforms, which have limited resources compared to e.g. personal comput-ers. These devices are limited in terms of memory, computational power,transmission capabilities, as well as battery. The problem arise when thesedevices are used for prominent and important tasks such as health moni-

11

Chapter 1. Introduction 12

toring, industrial automation, or energy management. Thus, keeping theirbattery alive as long as possible becomes very important while at the sametime they have to be reliable and secure.

1.1 Problem StatementsInternet of Things devices with a direct connection to the Internet are es-

pecially exposed to several types of attack. One of them is Denial of Service(DoS), where the attacker tries to prevent legitimate users from accessing in-formation or services provided by server devices. The most common strategyadopted by the attacker consists in flooding server devices with invalid (re-quest) messages so inducing the server to become exhausted and hence lessresponsive or even unable to serve legitimate requests. While the impact ofDoS attack on traditional networks can be already considerable, the impacton a constrained environment can be even more severe. Not only does DoSprevent devices to effectively serve the legitimate requests, but also it canadditionally drain battery-powered devices out of energy, resulting furthercosts or effort to do system recovery. This is often referred as Denial of Sleepattack [5][6][7] where the main purpose is to make the victim unable to switchto sleep mode, and hence to make it eventually run out of battery.

On the other hand, there are currently no implementation of an efficientapproaches to counteract such attacks in a way that dynamically protectsthe victim server according to the ongoing attack and its intensity. In tra-ditional networks with plenty of resources, a typical approach consists inanalyzing traffic patterns and then identifying malevolent message flooding[8][9]. However, this is infeasible in a network of constrained devices, whichcannot actively participate in such a demanding monitoring process. Cur-rently, there are no approaches aimed at reducing the impact of DoS against,while at the same time preserving best-effort service availability. This thesiswork takes a first step in filling this gap by providing a cross-layer and adap-tive solution to the common IoT protocol stacks. Nevertheless, the proposedapproach is general and can be easily adapted to alternative protocol stacks.


1.2 Related WorksDenial of Service (DoS) is a serious security threat, as described by [10],

which the purpose is to make a server or a network unavailable to their users,so leading to a temporary or even permanent disruption of its services. Thevictim is especially forced to highly consume its resources, e.g. in termsof CPU utilization, memory utilization, or network bandwidth, so becomingless responsive or even unavailable to serve legitimate requests. Furthermore,if the adversary relies on multiple source of IP addresses, the attack can beclassified as Distributed Denial of Service (DDoS) [11] attacks. Often, DDoSattacks are well coordinated through master and slave nodes, where masternodes act as attack leaders. The result of these attacks are even more severecompared to single source Denial of Service.

A number of approaches have been proposed to counteract Denial of Ser-vice attacks. As explained by Wang H. et.al. [12], approaches can be classi-fied into two types, namely router-based and host-based. First, router-basedapproaches address the problem by detecting source addresses used by theattacker [13][14][15][16] by using built-in defense mechanisms running on in-termediate nodes between client and server. Router-based solution can alsodetect attack traffic and block DoS traffic patterns [17][18][19][20][21][22].However, typically router-based solutions need all the router involved inthe defense mechanism to implement Probabilistic Packet Marking (PPM)[14][23][24], as well as coordinating mechanisms between routers. This is es-pecially inconvenient for system designer since they have to deal with a lotof nodes to maintain.

Second, host-based approaches implement DoS counteraction at the endnodes. This solution does not need coordination function between potentialvictims and can be deployed immediately. The solution proposed in thisthesis falls into this category. There are already several counted as host-based approaches, that can rely on resource management schemes [25][26].Also, other options consist in reducing resource utilization on the victim invarious ways, such as: SYN Cookies [27], DDoS-resilient scheduler [28], andClient Puzzles [29][30].

In [31], the authors classify types of DoS attack according to differentcriteria, i.e. the amount of source devices, source of node belonging, ge-ographical position, attack occurrence over time, vulnerability type, layertargeted by the attack, etc. The authors also proposed a simple solution toallow the server to detect DoS attack based on the number of TCP-packets


quantity and their increasing dynamic, processor loading, and difference be-tween SYN and SYN+ACK packets. Unfortunately, this approach can onlybe applied to specific attacks against TCP. If we consider bogus messages asUDP packets, they are hardly detected by the server using this approach.

Client puzzles is a popular solution to defend against Denial of Serviceattack and several approaches fall into this category. In [29], A. Juels andJ.Brainard introduced a client puzzle solution to counteract connection de-pletion attacks. The idea is to give the client a unique puzzle (with solvableproblem) when the victim believes to be under attack. In order to gain accessto the server, the client receives a challenge from the server and has to sendback the right answer. Instead, if the server does not believe to be underattack, then it serves requests normally at the earliest convenience. X. Wangand M. Reiter proposed a puzzle auction protocol to defend against Denialof Service attack [30]. Based on the protocol, in order to gain access to theserver, the client has to bid by solving puzzles, which can have several levelsof difficulty. Other solutions using client puzzles method were also proposed[32][33]. However, with increasing power of modern GPU, the puzzles fromvictim server can be easily solved [34] since most of the servers are usingCPU, while GPU has lower memory latency and onboard memory comparedto CPU.

In [35], the authors investigate energy attacks, a malicious exploits on theserver systems aimed at harming server power utilization. The authors claimthat state-of-the-art server systems with improved power saving technologiesare more vulnerable to energy attacks. In [36], the authors proposed to makeuse of QoS regulation techniques to reduce the impact of Denial of Serviceattack on the victim server. The approach considers the state of the resourceof the server which maintained over time. Then, according to resource usageof packets (or flows), the server performed a regulation enforcement to re-duce the impact of DoS. Since the Linux kernel provides QoS architecture inthe network stack, the authors rely heavily on them to perform provisioningon the network bandwidth by running a variety of traffic control functions.To become more adaptive, they added State Maintenance, QoS regulation,and Window Control as additional functionality on top of the kernel. Un-fortunately, since they monitor the utilization of whole incoming packets (orflows), this approach would results in the server becoming exhausted beforesufficiently enforcing QoS to mitigate the attack.

Raymond and Midkiff introduce CARL (Clustered Adaptive Rate Lim-iting) [37], a rate limiting approach based on current host-based intrusion


detection techniques. CARL classifies the type of message, i.e. whether it islegitimate or not at the link layer. Packets which are not properly authen-ticated as well as replayed packets are considered as potentially malicious.Last, the actions are taken based on the rate limiting to avoid the attack,and network throughput is sacrificed in exchange for network lifetime.

There are several efforts already been proposed to tackle Denial of Sleep.One of them is proposed by R. Raymond et.al. [7], as a solution to classifydenial of sleep attack considering attacker’s knowledge of the Medium AccessControl (MAC) layer protocol, and her capacity to bypass authentication andencryption protocols. They show that, combining the knowledge of protocolswith the capability of breaking link-layer encryption, an adversary can easilyperform Denial of Sleep attack on wireless sensor network MAC protocols,which could easily result in battery drain. The authors also propose a frame-work for preventing the Denial of Sleep attack built upon the knowledge ofjamming identification, link layer authentication, and replay protection. Thisthesis work proposes a solution against Denial of Service attack which is ableto effectively address also Denial of Sleep in constrained, battery-powered,devices. Future work will, in fact, include implementation and validation onconstrained platforms and evaluation in terms of protection against batterydrain.

1.3 ObjectivesThe main objectives of this thesis are the following:

1. To design a network architecture and a protocol that can counteractDenial of Service attacks in IoT environment, namely Adaptive Coun-teraction Protocol. The protocol should detect invalid messages whichperiodically assessed in order to adaptively change the operative statusof the victim server, and adequately counteract ongoing DoS attacks.

2. To implement the protocol in an environment that makes implemen-tation relatively easy and still gives good intuition about the protocolbehavior in a really constrained environment. We choose Californiumto perform our implementation.

3. To experimentally evaluate and analyze Adaptive Counteraction Proto-col in terms of quality of service of the IoT server provides, the resourcesit consumes, and the behavior of the protocol.


1.3.1 Limitations

We do not perform our implementation in a real constrained device. Butwe believe our work can give an initial figure on how our implementationwill look in a tiny device. Therefore, a continuation of this work into realcontrained device is actually needed. Furthermore, the proposed solutionwill only performs invalid messages detection mechanisms inside CoAP layerusing SMACK[38]. Further details about detecting invalid messages throughother means and/or at different layers are out of scope of this thesis. Theenergy related performance are also out of scope of this thesis. The resourceutilization is only measured in term of Memory and CPU utilization. Also,we do not implement the key distribution mechanism that is needed for theAdaptive Counteraction Protocol. The scenario to distribute the pre-sharedkey is out of scope of this thesis. And last, since we introduce additional con-figurable parameter to achieve our goal, the value of those parameters in ourmeasurement are determined heuristically. The equation and/or derivationof such values are out of scope of this thesis.

1.3.2 Benefits, Ethics and Sustainability

Internet of Things will become the next generation of internet where itcould help many sectors in the industry to operate more efficiently. The im-plementation provided in this thesis can help to preserve the resource on theInternet of Things device while under attack. Therefore, risks on running outof resource when operating on a critical and prominent task can be avoided.Furthermore, the result of this thesis might not have a direct impact on theethical discussion due to the aim of this thesis is not securing the integrityof the data, but rather on how to save the resource and availability of theserver even under heavy DoS attack. And last, since we aim to preserve theresource of the Internet of Things device while under attack, we have possiblesignificant impact on saving energy on the device, in particular, comparedto the vanilla implementation of Californium. Therefore, the device is moresustainable.

1.4 MethodologyThis thesis presents an adaptive approach to counteract Denial of Service

attacks against CoAP servers. The writer chose the experimental research


methodology as it is a typical research methodology in computer networks.We have built our prototype to prove that our proposed solution is doable sothat we can demonstrate it and evaluate its performance. This thesis workis divided into four stages :

1. Preliminary study, where we try to understand the problem and studythe background material on IoT protocols and their built-in securityfeatures. This stage includes literature review as well as code review ofexisting implementations.

2. Development, where we develop the algorithms and mechanisms al-ready pre-defined at RISE SICS, but still open for improvement.

3. Implementation, where we implement our idea in software. This stageincludes verification of algorithm and mechanisms mentioned in theprevious stage.

4. Evaluation, where we experimentally evaluate our work to assess theperformance of a device under attack in the presence of our solution.The evaluation includes cpu and memory consumption, round trip time,and message delivery rate.

1.5 Report StructureThe rest of this report is organized as follows. In chapter 2, we discuss

about the background knowledge of this work, including: the CoAP protocol,the library Californium (Cf), DTLS, and SMACK. Chapter 3 is devotedsolely to explain the Adversary Model and Application Scenario. Chapter4 describes the Adaptive Counteraction approach against Denial of Service,as the main contribution of this thesis work. Then, chapter 5 discusses thedevelopment and implementation of the proposed Adaptive Counteractionprotocol for the library Californium (Cf). We present our evaluation strategyin Chapter 6, and discuss the results in Chapter 7. Finally, in Chapter 8 wedraw our conclusions and anticipate future works.

Chapter 2

Background

In this chapter, we review the theoretic background and existing technol-ogy used in this thesis. First, we discuss CoAP, a protocol designed for con-strained environment that provides the underlying mechanism of our work.We consider the general definition and features of CoAP protocol in the firstplace. Then, we discuss CoAP in more detail as we explain its message for-mat and its interaction model. Since our work is utilizing CoAP proxy asa forwarder in one of our operative state, we also discuss this by the endof CoAP protocol discussion. Our implementation is developed on top ofCalifornium, a Java framework where we implement our proposed methodas an additional library. We discuss the glimpse of Californium right afterCoAP. Based on the specification, CoAP relies heavily on DTLS protocol tosecure its communication where we discuss subsequently afterward. In theend, since we use SMACK (Short Message Authentication Check) to distin-guish between legitimate or not legitimate packet, we explain briefly aboutshort MAC computation as well as the key derivation procedure.

2.1 CoAPThe Constrained Application Protocol (CoAP) [39] is a communications

protocol specialized to be used for constrained nodes and networks. It isdesigned to be affordable for constrained nodes in the sense of low resourcefor computation, such as CPU and memory as well as available energy. Itis often used on top of IPv6 over Low-Power Wireless Personal Area Net-works (6LoWPAN) which has limited throughput as well as high error rates

18

Chapter 2. Background 19

in packet transmission. CoAP design is highly affected by the Representa-tional State Transfer (REST) design, which is widely used in world wide web.Therefore, one of the purposes of CoAP is to give constrained device accessto the feature of a REST architecture so that it can interact with outsideworld seamlessly.

The main application of CoAP is for Machine-to-Machine (M2M) com-munications [39], such as smart city, smart farming, connected car, homeautomation, etc . Furthermore, as described by the standard [39], the mainfeatures of CoAP are as follows:

• A light version of web protocol specializing in M2M communications.

• It uses UDP as transport protocol.

• The message exchanges are asynchronous.

• It has low parsing complexity as well as header overhead.

• It supports URI and Content-type.

• Messages can be cached and proxied.

• It recommends Datagram Transport Layer Security (DTLS) to ensuresecure communications.

2.1.1 Message Format

By design, CoAP architecture tries to make message overhead as smallas possible and avoid message fragmentation while still providing REST-features. Based on the RFC 7252 [39], a CoAP message begins with a 4-byteheader (fixed length), subsequently followed by Token, whose size rangesbetween 0 to 8 bytes. Then, it is followed by Options in Type-Length-Value(TLV) format, which then optionally followed by payload which can fill untilthe end of the datagram. The representation of CoAP message can be seenin figure 2.1.


Figure 2.1 CoAP Message Format

The following definition of each field is based on the RFC [39]:

• Version (Ver): A 2-bit unsigned integer shows the CoAP version num-ber. This thesis is using version 1.

• Type (T): A 2-bit unsigned integer denotes the type of message. Pos-sible value can be 0 as confirmable, 1 as non-confirmable, 2 as an ac-knowledgment, and 3 as reset message.

• Token Length (TKL): A 4-bit unsigned integer denotes the length ofToken field in the range of 0 to 8 bytes.

• Code: An 8-bit unsigned integer, futher divided into two parts. Thefirst 3-bit is class "c" where it ranges from 0 to 7 specify: (0) as arequest, (2) as a success response, (4) as a client error response, and(5) as a server error response. The remaining "c" values are reservedfor the future purpose. The next 5-bit indicates the specific messagecode, as a value ranging from 0 to 31. More details can be found inRFC 7252, in CoAP method and response codes sub-registry [39].

• Message ID: a 16-bit unsigned integer denotes a unique message IDfor each message. Its purpose is to support duplication check as wellas message matching between confirmable/non-confirmable or acknowl-edgment/reset.

The subsequent field after header is Token value, whose size ranges be-tween 0 and 8 bytes as stated by the Token Length field. This value intentsto match the requests and responses, so that client/server knows how to pro-cess them. Each request message carries a Token value so that the server


replies with the same Token value in the response message. The generationof Token value should be unique enough for a period for a given source/desti-nation endpoint pair. This approach is to prevent mixed processing betweenmessage exchange on the relatively same period.

The next field is Options, where can be followed by another option, orby the Payload Marker and the payload. CoAP describes several Optionswhich could be carried in the message. For each Option, it contains OptionNumber, its length, and the corresponding value. A CoAP message caninclude multiple options depending on the designer of the system. However,a message can also contain zero options as it is optional.

Last, after header, token, and options, a payload can be optionally present.In this case, the payload starts with a byte Payload Marker (0xFF), which de-notes the end of options field and the beginning of the payload. The payloadcan occupy CoAP message until the end of the datagram.

2.1.2 Interaction Model

The CoAP interaction model is identical with the client/server model inHTTP [39] where a CoAP client performs request message towards a server,and if the server is available, it replies with response messages to the clientalong with the response code and the payload at its earliest convenience. Yet,M2M applications often lead to CoAP implementation where a device can actboth as a client and server. In this case, CoAP needs to distinguish the typeof message using its message code so the node can understand who is doingwhat. On the contrary with HTTP, CoAP message exchange is handled asyn-chronously. To accommodate transfer reliability between client and server,a message can be flagged as Confirmable (CON). As a response, if available,the CoAP server has to respond the confirmable request with an Acknowl-edgement (ACK) message. If that is not the case, the confirmable messagewill be retransmitted, based on the configuration value of timeout and expo-nential back-off between retransmissions. In the end, if the server does nothave the capability to send acknowledgment until the timeout expires, it hasto send Reset message (RST). On the contrary, if the application does notrequire reliable delivery, CoAP message can be flagged to NON-Confirmable.This message type does not require acknowledgment, but still relies on uniquemessage ID for each request to avoid message replay attack.


2.1.3 CoAP Proxy

Similar to the web proxy, a CoAP proxy can also perform requests tothe designated server on behalf of original node that sent the request. Thiscapability is useful when, at some point, the client does not have direct accessto the server due to policy from an administration authority or other reasons.Based on its behavior, a proxy can be classified into two categories, that is:

• Forward-proxy, where it is explicitly selected by the clients. CoAPdifferentiates requests designated to the proxy and the final recipientserver by means of a specific field in the CoAP message, named Proxy-Uri. The request addressed to the origin server is written in the Proxy-Uri Option as a string inside the CoAP message sent to the proxy. Thenthe proxy will strip the string and build new CoAP request towards theserver based on the content of the Proxy-Uri field. Hence, the request isstill similar to the normal CoAP request, where it could be Confirmableor Non-Confirmable, but the acknowledgement of the CoAP request ismade in a full-proxy fashion.

• Reverse-proxy, where clients have no knowledge that the proxy exist.This is the case when a client does not need to explicitly select theproxy to retrieve data from the server.

2.2 CaliforniumCalifornium (Cf) [1] is a sofware library implementing the Constrained

Application Protocol (CoAP) in Java. It is primarily intended for back-endservices for IoT applications, which in most cases need persistent scalabilitydue to numerous messages from a huge amount of nodes. Californium imple-mentation is based on a 3-stages architecture [1] where queues separate eachstage and carry its concurrency model. The details of Californium architec-ture can be seen on figure 2.2. The brief definition and procedure of messageprocessing on each stage is as follows:


Figure 2.2 Californium Architecture Based on [1]

• Network Stage - is the first stage of Californium where it is liable tosend and receive byte array through the underlying network. This stagerepresents underlying communication protocol where in most cases areUDP or DTLS. Yet, it does not rule out the possibility to use othercommunication protocol as well, e.g. SMS, GSM Network, etc.

• Protocol Stage - this second stage of Californium is responsible forexecuting the CoAP protocol. If the server has more than one CPUcore, then it will create the thread pool based on the quantity of thosecores. This state also implements the conversion from Java object tothe serialized datagram representation. After that, it checks if there is


any duplication to the messages, and perform the message cancellationif any. And then, the messages are managed by several layers :

– Reliability layer: Manages retransmission timeouts.

– Token layer: Ensures the unique matching of responses to openrequests.

– Observe layer: Handles observe relationships and orders notifica-tions.

– Blockwise layer: Fragments requests and responses for blockwisetransfers.

• Business Logic State - Where the developer can choose the role: (1)Server, hosting resources to be accessed by another node, (2) Client,where the node does not host any resource and uses the CoapClientAPI to send request messages are either synchronous or asynchronous.

Californium encapsulates CoAP protocol and network stage into an objectcalled Endpoint. This way, developers can choose any underlying transportmethod they want, i.e. UDP, DTLS, SMS, etc. in a modular fashion. A sin-gle server can also belong to multiple endpoints, for the purpose of multiplechannel accessibility on a resource, as well as for the sake of simplicity to dis-tinguish between many network interfaces. Our work in this thesis concernsstage 2 of the architecture above, specifically above the Blockwise layer.

2.3 DTLSDatagram Transport Layer Security [40] [41] is a protocol that equip

datagram protocols with privacy. DTLS is built upon the foundation of TLS(Transport Layer Security) protocol [42], which is already widely deployed forsecuring network traffic. Similar to TLS, "DTLS also guarantees client andserver to communicate securely, by preventing eavesdropping, replay, tamper-ing, or message forgery" [41].

The basic design principle of DTLS is to build "TLS over datagram trans-port" [41]. TLS cannot be implemented in datagram packet because there isa possibility of packet loss or out-of-order, which TLS has no capability tohandle. DTLS was designed with the mindset of solving this problem withas minimal changes as possible to the TLS protocol.


2.3.1 Handshake

To establish a secure session in DTLS, client and server have to performa handshake where the client is typically acting as a starter for this process.To do that, the client sends a ClientHello message to the server, and theserver has to respond with a ServerHello message as depicted in figure 2.3.

Figure 2.3 Message Flights for Full Handshake

These two Hello messages (either from the client side or server side) areused to form security enhancement capacity between client and server. Thefollowing attributes are established when Hello messages exchange are done:

• Protocol Version.

• Session ID.

• Cipher Suite.


• Compression Method.

The server will send its Certificate in a Certificate message subsequentlyafter the hello messages. Also, the server can optionally send a ServerKeyEx-change message if it has no certificate or its certificate is for signing only.Then, the server will send ServerHelloDone message, specify that hello-message phase of the current handshake is done. In this step, the serverhas to wait for the response from the Client. If from the previous stage, theserver sent the CertificateRequest message, then the client has also to sendthe certificate message. Still, at the same step, the client sends the Clien-tKeyExchange message, which the content is based on the agreed public keyalgorithm on ClientHello and ServerHello message. At this stage, the clientsends ChangeCipherSpec message and also copies the pending Cipher Specinto the current Cipher Spec. Then, the client sends the Finished message.As a response, the server sends its ChangeCipherSpec message, and finally,sends the Finished message. Then, the handshake process is finished, andthe client and server can securely exchange CoAP messages.

We can distinguish the handshake of DTLS over TLS with the followingpoints:

• The server can optionally exchange a stateless cookie with the client,as a protection against Denial-of-Service.

• There are several modifications in the header message, which has thepurpose of message reordering and message loss handling. This serviceis important due to the underlying protocol of DTLS is datagram whichdoes not provide reliability.

• It has retransmission timers for message loss handling.

• DTLS handshake messages include explicit indications for fragments.

2.3.2 Packet Loss Handling

As explained in the previous paragraph, DTLS relies on simple retrans-mission timer as an additional feature to handle packet loss. If let’s say,ClientHello message from the client is not responded by the server (eitherthe ClientHello message or the HelloVerifyRequest message is lost), it will


retransmit the ClientHello when the timer expires. The timeout and re-transmission only apply on ClientHello message, while HelloVerifyRequestdoes not have the same capability.

2.3.3 Reordering

DTLS has small modifications on the header (compared to TLS). One ofthem is to assign a specific sequence number inside the handshake process.When the node receives the handshake message, it can figure out whetherthe message it receives is in the correct order or not. If that is not the case,it will queue the corresponding message to be handled later when previousadjacent messages have been received.

2.4 SMACKSMACK [38], stands for Short Message Authentication ChecK, a security

service that identifies invalid messages in an efficient way early after theirreception, by checking a short and lightweight Message Authentication Code(MAC). In a case where the device receives a lot of invalid messages, itcan prevent further parsing and verification procedures. Furthermore, if thereceived invalid messages are quite a lot in a relatively short time window,the server can consider being under attack, therefore it can act accordinglyto reduce the impact, e.g. as described in more detail in Chapter 4.

2.4.1 Message Format

SMACK essentially included in the Token field of CoAP message wherea short MAC computed over the CoAP message header. Before sendingthe CoAP request message, the client generates a-16 bit random Request IDR. This value is used to match the requests messages with their respectiveresponse, and is in fact written in the first 16 bits of a 32 bit Token field.Subsequently, it is followed by a 16-bit short MAC SM computed by theclient following the procedure described in this chapter. The input to theshort MAC computation is the concatenation of the following fields in theCoAP message:

• 4-byte CoAP header, including Version, Type, Token Length, Code,and Message ID.


• 2-byte Request ID R.

Request ID R and Short MAC SM are placed in Request ID and Validitycheck subfield of the Token field, respectively. The new message format afterthe addition of Short MAC value can be seen on figure 2.4.

Figure 2.4 CoAP Message with Short MAC

2.4.2 Short MAC Computation

MAC is defined to be 16 bits in size. Thus further short MAC compu-tation would employ 16 bits in size as well. SMACK introduces the conceptof session, i.e. "a sequence of messages exchanged between the same client Cand device D over a short amount of time".

Let GF (216) as a 16 bits Galois Field [43], so we can express:

• a, b ∈ GF (216) - constant 16 bits key values used for the entire SMACKsession.

• ci ∈ GF (216) - dynamic 16 bits key value, renewed for each messageexchange between C and D.

If Mi is the i-th CoAP request sent towards the device D from client Cin one session, then we defined mi as the first 48 bits of Mi where it contains:

• 32 bits CoAP header.

• 16 bits Request ID.


That is mi is defined as the concatenation of 3 items (which are 16 bitslong each), so we can represent mi as

{mi0||mi1||mi2

}, where mi0,mi1,mi2 ∈

GF (216). Hence, the short Message Authentication Code is computed:

vi = (mi0 + a ·mi1 + a2 ·mi2) · b+ ci (2.1)

Ahead of throwing a request message Mi to device D, client C calculatevi using Equation 2.1. The output is placed in the validity check subfieldinside the token field. As Mi arrives at D, it examines the first 6 bytes ofthe message header, and considers them to recompute the MAC v∗i accordingto Equation 2.1. Then, device D perform a conditional operation to checkwhether the calculated short MAC is equal to the attached MAC vi carriedin the token field. If vi == v∗i then device D considers message Mi to be avalid request, otherwise it would counted as invalid.

2.4.3 Key Derivation Procedure

To compute a, b, and c considered in equation 2.1, a master key KM isshared between the device D acting as CoAP server and a trusted third partyacting as Key Distribution Center KDC. It is assumed that D establishesKM with KDC at deployment time. This material KM is not used directlyto secure the communication, but rather as a source to derive other securitymaterial. Device D and KDC also pre-shared a positive integer seed. Thisvalue will be employed along with KM to produce further key material.

Both KDC and device D rely on a same pseudo random function PRF (•),whose output is 256 bits in size. The first additional key material derivedby D and KDC is KMS, a master session key. This key is in turn used toderive further keys to compute the short MACs. The key KMS is computedas follows:

KMS = PRF (KM , seed) (2.2)

Before sending the request to device D, client C needs to contact KDCto get the following security material:

• Initial Message ID ID∗ - As the first CoAP message IDs to be usedduring this SMACK session with device D.


• Session Key KS - As the key considered to compute short MACs duringthis SMACK session with device D. KDC computed KS as follows,before providing it to the client C:

KS = PRF (KMS, ID∗) (2.3)

Finally, we can define KSjas:

KSj=

{KS, if j = 0

PRF (KS, KSj−1), if j ≥ 1

(2.4)

Then, the device can use equation 2.1 to compute the MAC of i-th mes-sage during a given SMACK session, where the values of its constants are:

• a - bits position 0-15 of KS

• b - bits position 16-31 of KS

• ci - 16 bits in KSjwhere j = b(i + 2)/16c starting from the bit in

position ((i+ 2)mod16) ∗ 16 until ((i+ 2)mod16) ∗ 16 + 15.

Chapter 3

Adversary Model and ApplicationScenario

3.1 Adversary ModelWe consider an adversary that performs a Denial of Service attack against

a victim server by repeatedly sending service request messages. The adver-sary can send such bogus messages repeatedly over unicast or multicast com-munication such that the victim will process all of them upon their reception.We consider such bogus messages as invalid requests, which are identified byusing the mechanism Short Message Authentication ChecK (SMACK), ex-plained in Chapter 2.4.

In this thesis, we consider service request attack messages sent as CoAPrequest message, sent to the victim server in order to exhaust its resources.

3.2 Application ScenarioWe look at an application scenario consists of three parties: a CoAP client

C, a CoAP server device D, and a trusted third party acting as Key Distri-bution Center (KDC). The main role of the KDC is to provide the client Cwith the key material necessary to compute the short MACs required by theSMACK mechanism (see Section 2.4). Before doing that, KDC should alsoverify that C is authorized to contact device D, by either performing the au-thorization process itself or by leveraging a previously occurred authorizationprocess. Further details about such an authorization process are out of the

31

Chapter 3. Adversary Model and Application Scenario 32

scope of this work. Please note that, in this thesis, all communication goingto/from KDC is secured using DTLS protocol explained in Section 2.3. In areal world scenario, KDC not only can be implemented as a single centralizedentity but also in a distributed fashion where multiple KDC work togetherwith a coordination function.

Aside from key distribution task, KDC also acts as forward-proxy. Aslater described in Chapter 4, KDC is also able and available to cache CoAPrequests, for later delivery to the server device in case the latter is underattack.

Figure 3.1 Application Scenario

We consider the application scenario depicted in figure 3.1 where thereare three entities, namely a IoT device D, a client C, and the KDC.

Device D and KDC are in mutual trust relationship where they sharea symmetric cryptographic master key KM , such that KM does not useddirectly to secure the communication, but rather as a foundation to generatefurther security material. The detailed mechanism of generating such securitymaterial has been described in Chapter 2.4. Upon the start of operationof device D, it asks for KM to the KDC using a specific message that wedescribed later in Chapter 4.4. After device D receives KM , it will start theoperation, and classify all incoming requests based on their legitimacy usingSMACK.

Chapter 3. Adversary Model and Application Scenario 33

The protocol communication between device D, client C, and the KDCis Constrained Application Protocol (CoAP), as explained in Chapter 2.1.Furthermore, to secure the message exchange between device D and KDCas well as between client C and KDC, we use DTLS. Finally, to retrieveinformation from the device D, client C has to contact KDC to get :

• Session Key - a cryptographic key to be used by SMACK to computethe short MAC included in request messages sent to device D.

• a valid Message ID - to be used in the first message sent towards deviceD, which the value needs to be incremented gradually following thenumber of messages sent.

Chapter 4

Adaptive Counteraction Protocol

In this chapter, we will discuss in more detail about our proposed Adap-tive Counteraction Protocol. The main idea of our proposal is to adaptivelychange the operative state of the victim server according to attack intensity.This approach is needed to shield the victim server in the event of Denial ofService attacks. We believe the fixed method is not enough to shield the de-vice if the attack happens continuously as the device will process all incomingmessages fairly. Hence, it performs unnecessary computation and consumesadditional energy for nothing. Therefore, we introduce the protected and offstate where the device basically shield itself from the adversaries. To movebetween states, we introduce a counter of invalid messages in which SMACKmechanism [38] is used to distinguish between valid and invalid messages.

4.1 Network ArchitectureIn this thesis, we follow the network scenario as depicted in Figure 4.1.Primarily, the Server S and Client C have been deployed and affiliated to

a third unit P. P has two functions, that is :

• Key Distribution Center (KDC).

• Proxy.

All communications between P and C, as well as P and S rely on a secureDTLS protocol. However, communication between C and S is performed overan insecure channel, employing CoAP protocol on the application layer. The

34

Chapter 4. Adaptive Counteraction Protocol 35

Figure 4.1 Network Scenario

communication model is similar to normal internet protocol where Client Cexpected to initiate the message exchanges, by sending message to the ServerS. Subsequently, server S should reply with response message.

All in all, we consider the attacker as an external adversary who repeat-edly sends invalid request messages to the Server S, feigning as a legitimateclient. On a vanilla implementation where there is no counteracting strat-egy, such messages are delivered to the application layer. As a result, thewhole reception process in the communication stack would employ furtherprocessing as well as resource consumption at the application layer.

In this thesis, the server S only utilize one detection mechanism de-ployed at the CoAP layer, and based on a short Message AuthenticationCode (MAC) encapsulated in the CoAP request messages sent by legitimateclients. The short MAC value is calculated by the client, and verified bythe Server upon the receiving process. It is generated based on the securitymaterial that is distributed over the Proxy P, acting also as Key DistributionCenter. Further details on how invalid message detection mechanism worksare already explained in chapter 2.4.

4.2 Invalid Messages DetectionTechnically, invalid messages detection can be performed at any layer in

the TCP/IP stack according to different possible criteria and mechanism.For example, short MACs technique can be used in the CoAP layer to detectinvalid message, as we already discussed in chapter 2.4. The DTLS layer can


rely on the services provided by the respective record layer. IPSec can beused in the IP layer to do the same task. And other layer can rely on anyspecific mechanism which suitable to them.

After all, we built an additional component on the top communicationlayer, namely "DoS Reaction." This module is responsible for collecting re-ports of detected invalid messages, no matter the communication layer wherethey have been detected. That being said, in particular, we can detect invalidmessages at any communication layer to be reported to the "DoS Reaction"module, before silently discarding it. For instance, deployed server with itscommunication stack integrated with "DoS Reaction" module can be seenon Figure 4.2.

Figure 4.2 Server Communication Stack

Considering all the reported invalid messages from different communica-tion layers, the "DoS Reaction" module aims at achieving the following goalsin a victim server that under DoS attack :

• Shielding the Server under DoS attack.

while at the same time

• Allowing the Server to still serve legitimate request messages in aneffective burst fashion.


4.3 Server State MachineTo achieves the goals mentioned above, the "DoS Reaction" module pos-

sess three operative states that can change over time, according to the currentattack conditions. We named those three operative states as phase, in whichthe victim server can recognize itself :

• NORMAL (Phase 0) - denotes a typical behavior where request mes-sages from clients are served by the server, which replies at its earliestconvenience.

• PROTECTED (Phase 1) - denotes that the server processes and repliesto request messages from clients only if received from the Proxy P asrelay sender. In this case, response messages from the Server are alsodelivered to the client through the Proxy P acting as relay.

• OFF (Phase 2) - denotes that the server entirely shuts down its networkinterface for a given time interval, during which the Proxy P cachesrequest messages coming from clients to be served later on.

Figure 4.3 Server state machine

Possible transitions between states is depicted in Figure 4.3. State syn-chronization between server and other entities is important in the scenarioon the state machine above because by only doing so, client and proxy couldunderstand what is going on with the server so that it can act accordingly.Furthermore, by understanding the server state, client can still be possibleto be served by the server, in a best-effort way, through the Proxy P.


4.4 Synchronization MessageTo achieve our goal, we embed additional information at the beginning of

CoAP payload so that each entity knows how to perform further processingof incoming message. To this end, the message format would looks like figure4.4.

Figure 4.4 CoAP Message with Additional Information for Adaptive Ap-proach

The reason to put such additional information at the beginning of thepayload is solely for simplicity. In a general case, this information can be puteven inside the options or anywhere in the CoAP message as long as eachentity knows how to process the messages. However, since we do not haveany intention to change the CoAP message format, we believe it is convenientenough to put this additional information inside CoAP payload. Based ontheir purpose, we consider three types of message in our proposed technique,namely :

• Type 0 - for SMACK material exchange.

• Type 1 - Signaling (synchronization function).

• Type 2 - Caching procedure.

For each type, we define specific sub type based on their purpose, as wellas source and destination. Table 4.1 shows each of the described messageand their details respectively.


Table 4.1 CoAP Message Format with Additional Field

Type SubType From To Purpose

0

0 S P Initial SMACK Material(Server Side)1 P S

2 C P Initial SMACK Material(Client Side)3 P C

4 S P Update SMACK Material(Server Side)5 P S

6 C P Update SMACK Material(Client Side)7 P C

1

0 S C Change state fromNORMAL toPROTECTED

1 S P2 P S3 S P Change state from

PROTECTED to OFF4 P S5 P C6 S P Change state from OFF

to PROTECTED7 P S8 P C9 S P Change state from

PROTECTED toNORMAL

10 P S11 P C

20 C P Uncacheable request

1 C P

Cacheable request withinformation aboutmaximum acceptabletime in OFF state clientcan handle

2 P C

Inform client for howlong from that point intime the Server is goingto be in OFF state


4.5 Server BehaviorsThis section discuss in detail the difference of server behaviors both from

Client and Server perspective. The behaviors will be based on the opera-tive state and attack configuration from the adversary. We also discuss theconditions and events required to switch between different states.

4.5.1 Client Perspective

As operative states in the server changes due to attack injection rates, thefollowing section explains what the client will expect on the server behavior.

Server in NORMAL State

The server normally accepts and processes CoAP requests received fromthe Client, and replies with a CoAP response at its earliest convenience.

In case the proxy P receives request messages addressed to the serverwhile this is in NORMAL state, it replies to the client originated the requestmessage (message Type 1, SubType 11), forcing it to directly send the requestmessage to the server.

Server in PROTECTED State

The server does not serve requests directly coming from the client. Thereare two approach to let the client know, suggesting it should transmit requestmessages through the proxy, that is :

1. For the client(s) which already have an established session with theserver and authenticated with the proxy through DTLS, the serversends an error reply Type 1, SubType 0.

2. For the client(s) which have no existing session running, the serverwill not serve any request from them, so that the client eventuallyreaches the limit of request retransmissions and automatically starttransmitting them through the Proxy P.

In this state, the client sends the request message using Type 2, SubType0 meaning that it sends a message through the Proxy that is uncacheable.The proxy only needs to forward the request to the server as well as relayingback the response it get to the client. The server does not serve any requests


that coming directly from the client, instead it only serves request comingfrom the proxy. If that is the case, the server prepare the response messageaddressed to the client, and sends it through the proxy P to be delivered tothe client.

In case the proxy P receives request messages addressed to the serverwhile this is in PROTECTED state, it immediately relays the message tothe server.

Server in OFF State

The server shuts down its network interface so that no any incomingmessages would reach the server. Based on the existence of session betweenclient and server, there are two approaches of message handling:

1. For the client(s) which already have an established session with theserver in the PROTECTED state, the proxy P will inform the clientwith error message Type 1, SubType 5 in a form of response messagepiggybacked in the CoAP response of the respective request. That way,client will understand that the server is going to OFF state, so thatthe client change its request message to Type 2, SubType 1 carryinginformation about the maximum acceptable time the client expects toreceive a response.

2. For the client(s) which have no existing session running, it will not beserved by the server (since its network interface is shutted down) sothat the client eventually reach the maximum number of retransmis-sions. The client will start sending request messages Type 2, SubType0 to the proxy P assuming that the server is in PROTECTED state.Instead, the client will receive an error message Type 1, SubType 5(but not in a piggybacked form as in the previous case), suggestingthat it should send a cacheable request. Then, as suggested by theproxy, the client sends a cacheable request message Type 2, SubType1 carrying information about the maximum acceptable time the clientexpect to receive a response. The information of maximum acceptabletime expected by the client is important because it prevents the possi-ble long-term caching of request messages from clients that expect toreceive a response within a relatively short time.

Upon receiving a CoAP request from the client, in case the server is inOFF state :


• The proxy P considers the time specified by the client in the CoAPoption mentioned above. In case such a time is greater than the residualtime that the Server is going to spend in OFF state, the proxy Pdiscards the received request message without caching it.

• The proxy P replies to the client with message Type 2, SubType 2,informing the client for how long from that point in time the server isgoing to be in OFF state. This is the minimum amount of time beforethe client could receive any response from the server (through the proxyP). Given this information and the knowledge that the server is in OFFstate, the client can decide to avoid any further requests addressed tothe server S for the whole time specified in the proxy response.

While the server is in OFF state, the proxy P caches request messagesfrom clients, to be later on delivered to the server in a First-Come-First-Served fashion. The amount of cachable request messages on the Proxy P islimited and, e.g. recent ones force old ones to be discarded as stale.

4.5.2 Server Perspective

Server in NORMAL State

While in NORMAL state, the server normally serves request messagesfrom clients, and replies to them at its earliest convenience. When backto NORMAL state, the server notifies the Proxy P with message Type 1,SubType 9 that its own operating state is in NORMAL again.

Server in PROTECTED State

When switching to PROTECTED state, the server notifies the proxy P toact as relay of request messages originated by the clients, for a given amountof time T1. While in PROTECTED state, the server processes and repliesto the request messages from clients only if received from the proxy P as arelay sender. Besides, response messages from the server are also deliveredto the client through the proxy P acting as a relay.

Server in OFF State

When switching to OFF state, the server notifies the proxy P to cacherequest messages originated by clients, for a given amount of time T2 (A


random value between T2_MIN and T2_MAX). Then, the server shutsdown its network interface for the same specified time interval.

When the amount of time spent in OFF state expires, the server switchesback on its network interface. Then, it contacts the proxy P, and retrieves anycached request messages stored in P. Finally, it switched to PROTECTEDstate and starts serving the collected cached request messages.

While in NORMAL or PROTECTED state :

• The server checks that each incoming request message is valid, at anycommunication layer enforcing a validation mechanism. Note that thechecking mechanism only performed on the unsecured channel betweenserver and client on CoAP layer. Further validation mechanism thathappened on the other layers are out of scope of this work.

• If a message is detected as non valid, the server silently discards it, andreport to the “DoS reaction“ module, in order to increment the counterof detected invalid messages in the current time window.

• The server considers its current operating state. If the state is PRO-TECTED and the (valid) message has been received from an addressdifferent than the proxy P, the server discards the message. This occursif a valid message is sent by a client and the server receives it whilein PROTECTED state. The server can reply to the client with a spe-cific error message Type 1 SubType 0, suggesting the client to transmitrequest messages through the Proxy P.

• The server checks for possible updates in the configuration of its currentstate, or for a possible change of state. The operations are describedin section 4.6.

4.6 Server State Update and Transition

4.6.1 Normal State

In Normal state, we consider the following variables to be used to deter-mine server state update and transition:

• Th0 = Threshold for leaving Phase0 (Normal) and moving to Phase1(Protected).


• W0 = Time window length (in seconds).

• C0 = Number of invalid messages received during the last time window.

Variables above are influenced by the following configuration determinedby system designer :

• Th0_MAX = The maximum threshold value for leaving Phase0 (Nor-mal) and moving to Phase1 (Protected)

• Th0_MIN = The minimum threshold value for leaving Phase0 (Nor-mal) and moving to Phase1 (Protected)

• t0 = Time window length (in seconds)

To get the value of C0, the server S perform SMACK mechanism of eachincoming message. If it is detected as invalid, C0 is incremented by 1 beforethe server silently discards the request message. Otherwise, the server willjust perform message processing normally. At initialization, the server entersNormal State with Threshold (Th0) is set to maximum value, as shown inthe following algorithm :

Algorithm 1 Initialization1: Th0 ← Th0_MAX2: W0 = t03: C0 = 04: <Set state to NORMAL>

Upon switching to Normal state from Protected state, Server S setsThreshold Th0 to minimum value, Time window length (W0), and Counter(C0) as the following:

Algorithm 2 Upon Switching to Normal State1: Th0 = Th0_MIN2: W0 = t03: C0 = 04: <Inform the Proxy P to be in NORMAL state>

While in Normal state, the server tracks Th0 and C0 for each time windowlength W0, performing the following algorithm :


Algorithm 3 After each W0 seconds, while in NORMAL state1: if C0 < Th0_MIN then2: Th0 ← min(2 ∗ Th0, Th0_MAX)3: C0 ← 04: else if Th0_MIN ≤ C0 < Th0 then5: Th0 ← max(Th0/2, Th0_MIN)6: C0 ← 07: else if C0 ≥ Th0 then8: <Switch to Protected state>9: end if

We set the initial Th0 in Algorithm 1 to MAX because we do not want toswitch to protected state immediately as the attack received. The idea is tomake the server wait and see if the attack keeps continue. If that is the case,the server must lowering the value of Th0 by half of the previous value so thatit exponentially decreasing. And if the attack still occurs, Th0 will eventuallyreach the value lower than C0 and makes the victim moves to protected state.On the other hand, if the attack stopped or decreasing so that it is lower thanTh0, the value will be doubled and increase exponentially. It is important toclear the C0 value after time W0 expires, since we are measuring only in onetime window, not as accumulative value between time window.

If the server decides to switch to Protected state, then it will followsprocedures described in the next section.

4.6.2 Protected State

In Protected state, we consider the following variables to be used to de-termine server state update and transition:

• Th1 = Threshold for leaving Phase1 (Protected) and moving to Phase2(Off).

• W1 = Time window length (in seconds).

• C1 = Invalid messages received during the last time window.

• k = An integer value aims to decrease the threshold in Protected state.

Variables above are influenced by the following configuration determinedby system designer:


• Th1_MAX = The maximum threshold value for leaving Phase1 (Pro-tected) and moving to Phase2 (Off).

• Th1_MIN = The minimum threshold value for leaving Phase1 (Pro-tected) and moving to Phase2 (Off).

• t1 = Time window length (in seconds).

• T1 = Timer which define the maximum time of protected state.

• k_MAX = The maximum value of k.

Upon switching to Protected state (Either from Normal or Off state),Server S sets Threshold (Th1) to maximum value, Time window length (W1),and Counter (C1) as the following:

Algorithm 4 Upon Switching to Protected State1: Th1 = Th1_MAX2: W1 = t13: C1 = 04: k = 05: <Inform the Proxy P to be in PROTECTED state>6: <Start a Timer T1 >7: if Timer T1 expires then8: <Switch to NORMAL state>9: end if

While in Protected state, the server keep track of Th1 and C1 value foreach time window length W1, performing the following algorithm :


Algorithm 5 After each W1 seconds, while in Protected state1: if C1 < Th1_MIN then2: Th1 ← min(2 ∗ Th1, Th1_MAX)3: C1 ← 04: else if Th1_MIN ≤ C1 < Th1 then5: k ← min(k + 1, k_MAX)6: Th1 ← Th1 − 2k

7: C1 ← 08: else if C1 ≥ Th1 then9: <Stop Timer T1>

10: <Switch to OFF state>11: end if

Similar to the normal state, we do not want to switch immediately tooff state after the server moves to protected state. Therefore, we set theinitial value of Th1 as maximum value. In a case when the attack intensityis below the threshold minimum Th1_MIN (light attack), Th1 value shouldbe doubled from its previous value and increase exponentially from timeto time. This logic is make sense when the attack injection rates are notintense, which makes the victim server eventually goes back to normal stateagain after T1 expires. In a case when the the attack is medium (betweenTh1_MIN and Th1), the value of Th1 should decrease exponentially, by 2k

where k = 1, 2, 3, ... so that it does not move immediately to off state afterreaching protected state. Last, when the attack is so intense and above theserver can handle (more than Th1), it will finally moves to off state for someperiod of time.

4.6.3 Off State

Upon Switching to OFF State, the server S will perform the followingalgorithm :


Algorithm 6 Upon Switching to OFF State1: <Inform the Proxy P to be in OFF state>2: <Shut down the network interface>3: T2 = generateRandomInteger[T2_MIN, T2_MAX]4: <Start a Timer T2 >5: if Timer T2 expires then6: <Turn on the network interface>7: <Switch to PROTECTED state>8: <Retrieves and serves cached request messages from the Proxy P>9: end if

The mechanism in off state is straightforward, as our intention is to shieldthe victim completely in a period of time during this state. We do not performany invalid messages detection as the interface is shut down, and the serveris out of reach from any nodes surrounding.

Chapter 5

Implementation of AdaptiveCounteraction Protocol

The starting point of our implementation in this thesis is SMACK [38]in Californium. It is already proven to be successful in detecting invalidmessages on a victim server with relatively low overhead. However, it hasno mechanism where the device counteract accordingly to the DoS attackintensity so that further processing on invalid messages can be avoided. Ourproposed solution try to fills those gaps by enhancing the capability of thedevice so that it is become more sensitive and suspicious about DoS attack.We aim to cover such capability with minimum changes possible from theimplementation of SMACK. Even though our current implementation focuseson unconstrained environment, as Californium targeted to be implementedon the cloud, we do have a plan to implement our proposed mechanism in theconstrained environment in the future. Furthermore, by getting real worldexperience about our design as well as the implementation, we hope to getvaluable feedback for the potential optimization. Anyone who have interestin our source code, it is publicly available on our Bitbucket page1.

5.1 Invalid Messages CounterAs we mentioned in Chapter 4.2, invalid messages detection can be per-

formed at any layer in the TCP/IP stack according to different possiblecriteria and mechanism. However, in this thesis we only consider detecting

1https://bitbucket.org/syfq/californium-dos

49

Chapter 5. Implementation of Adaptive Counteraction Protocol50

invalid messages on the CoAP layer by utilizing SMACK. Further detailsabout detecting invalid messages through other means and/or at differentlayers are out of scope of this thesis. To make it easy for future develop-ment, we provide an easy and comfortable API for the developer so thatthey can easily call our API to increase the counter of invalid messages uponthe receiving process.

In our case, SMACKLayer employs the same API to count incominginvalid messages for each epoch time. The counter is restarted when epochtime expires so that the next epoch start to count from 0. The following codesnippet is an example how we call invalid message counter in a case where itreceives a not authentic one.

// This message is not authentic and is silently discardedif(!Arrays.equals(receivedShortMAC, computedShortMAC)) {

SecurityBox.InvalidCounterIncrement();return;

}

Any other layer that wants to use the service only needs to call the samefunction above with invalid message detection can be defined depending onwhich layer it operates.

5.2 DoS Reaction ModuleWhen we implemented our solution for the first time, we developed it in

the application layer of each entity (Server, Client, and Proxy). That way,developer has to deal with complexity in the application side which is not agood practice to implement a software. Furthermore, it does not comply withmodularity approach brought by Californium which has to follow layered-architecture style.

To follow the modularity of californium, on the second attempt, our ap-proach of building the solution is to keep the client and server as transparentas possible to the underlying mechanisms. Therefore, we feel that it is impor-tant to build a dedicated java class similar to the SMACKLayer and move allthe functionality we have built previously to the class, namely DoS ReactionModule. In short, the module is responsible for all the tasks needed by theclient and server as mentioned in the Chapter 4. The following subchapterwill explain in detail of each task from different entities on the module.


5.2.1 Server

runServer()

This method initiated is when the server is running for the first time. Itsets server state to normal and establish a secure DTLS connection towardsthe Key Distribution Center. When the connection is established, the serverasks KDC for SMACK material to be used later to determine validity ofincoming requests from the client.

Counter

Counter is the most important variable in our proposed design, such thatit has to be accessible from any class as well as any layer on the TCP/IPstack of the server. The value affects the server future operative state as wellas its action accordingly. As described earlier, any layer or class that needsto increase the counter value can easily access our provided API in a way assimple as one liner.

Timer

As described in Chapter 4, when the Protected or Off state starts, theserver needs to run a timer such that it will stay in that phase for a pre-defined period or move to other phase if certain conditions are met. Weimplement such feature by utilizing java timer2 class which is convenientenough to schedule task for future execution in a background thread. Thetimer class is also used to schedule operation for each epoch time, i.e. countervalue checking and the correspondence action based on the counter value.

Set Server State

As there are three operative states of the system, we describe three meth-ods on the server side, namely:

• setServerStateNormal().

• setServerStateProtected().

• setServerStateOff().2https://docs.oracle.com/javase/7/docs/api/javax/swing/Timer.html


Each method follows the defined algorithm in which we already explained inChapter 4.6.

Synchronization Function

This method invoked when the operative state of the server changed. Weonly consider an active synchronization to be used inside the DoS Reactionmodule, meaning that the server is actively informing the KDC/proxy aboutits operative state. In the case of client, the information about operativestate changing is embedded in the CoAP response for the respective requestin which we consider that as a passive synchronization message.

We consider 4 active synchronization messages, formed as java methodas follows :

• NPNotifKDC() - Inform the KDC that server changes its operativestate from Normal to Protected.

• PNNotifKDC() - Inform the KDC that server is come back to Normalfrom Protected.

• PONotifKDC() - Inform the KDC that server changes its operativestate from Protected to Off.

• OPNotifKDC() - Inform the KDC that server is come back to Protectedfrom Off.

As we build the packet which is not yet described in the CoAP standard,we need a method from Californium that is flexible enough to perform packetmanipulation for a coap client. Because of that, we always use advanced()method from CoapClient class since it is convenient enough to build a custompacket and send the packet through specific endpoint. For any receivedsynchronization message, the information about the server operative state iscarried inside the packet payload following the type of packet that alreadydescribed earlier on the Table 4.1.

5.2.2 Client

runClient()

This method initiated when the client running for the first time. Theclient assumes that the server is in normal condition and establish a secure


DTLS connection towards Key Distribution Center. When the connectionis established, the client asks KDC for SMACK material to be used later togenerate short MAC value.

5.3 KDCThe Key Distribution Center is implemented in the application layer of

Californium, where the SMACK Materials KMS, KS, and seed are calculatedand provided to the client with CoAP message exchange mechanism providedby CoAP resource. To access specific resource, client must provide identifieron the request message so that the server understands what to provide foreach request. The identifier is a message type and subtype as described inChapter 4.1. For example, if a client wants to authenticate itself to theserver, it needs to contact KDC by sending message Type 0, SubType 2.Subsequently, KDC will reply with message Type 0, SubType 3 along withInitial Message ID and KS.

5.4 ProxyThe proxy capability is implemented inside the ForwardingResource

class, as an extension of CoapResource class. In order to cooperate withthe server, the proxy must know what state is the server currently operates.To achieve this, we describe a synchronization message in Table 4.1 givingproxy the knowledge on the server operative state. Based on the current in-formation of the server state, the proxy will perform the following operations:

• By the time the proxy starts the operation, it assumes that the serveris in normal operative state. In this case, if any CoAP request messagesfrom the client wants to be forwarded to the server, the proxy will sendmessage Type 1 SubType 11 so that the client sends the CoAP requestdirectly to the server.

• If the proxy receives message Type 1 SubType 1 from the server, thiswould changes its operative state to protected. In this case, any in-coming CoAP request received by the proxy will be forwarded to theserver only if the following conditions are met:

– The CoAP request message is Type 2 SubType 0.


– The proxy has not receive any further synchronization messagesfrom the server.

– The timer of protected state is yet to be expired.

• If the proxy receives message Type 1 SubType 3 from the server, itchanges its operative state to OFF. Any incoming CoAP request re-ceived will be cached for period T2 only if the following conditions aremet :

– The CoAP request message is type Type 2 SubType 1.

– The proxy has not receive any further synchronization messagesfrom the server.

– The timer of off state is yet to be expired.

5.5 ConfigurationIn order to achieve our goals of adaptive server state, we need the following

variable to be configured, depending on the environment of the server:

• IS_SERVER(boolean)A boolean indicating this corresponding node is a server or not.

• IS_CLIENT(boolean)A boolean indicating this corresponding node is a client or not.

• IS_PROXY(boolean)A boolean indicating this corresponding node is a proxy or not. If oneboolean is stated as true, the other two must be declared as false. Thepurpose of this classification is to distinguish the function in SecurityBox class.

• Th0_MAX(integer)Maximum threshold of incoming invalid messages in the normal state.

• Th0_MIN(integer)Minimum threshold of incoming invalid messages in the normal state.


• Th1_MAX(integer)Maximum threshold of incoming invalid messages in the protectedstate.

• Th1_MIN(integer)Minimum threshold of incoming invalid messages in the protected state.

• t0(integer)Time window length (in seconds), also known as epoch sampling timeof normal state. For each t0 second, server S count the number ofincoming invalid message and reset the counter when t0 expires.

• t1(integer)Time window length (in seconds), also known as epoch sampling timeof protected state. For each t1 second, server S count the number ofincoming invalid message and reset the counter when t1 expires.

• T1(integer)The amount of time the server spent in the protected state.

• T2_min(integer)The minimum amount of time the server spent in the off state.

• T2_max(integer)The maximum amount of time the server spent in the off state.

• CLIENT_ADDRESS(string-IPv4 format)IPv4 address of the client.

• PROXY_ADDRESS(string-IPv4 format)IPv4 address of the proxy.

• SERVER_ADDRESS(string-IPv4 format)IPv4 address of the server.

• PROXY_SECURE_PORT(integer)Secure port number where the proxy runs it service. Please be notedthat connection to the proxy is assumed to be secure since it uses DTLSchannel.

• SERVER_SECURE_PORT(integer)Secure port number where the server runs it service.


• SERVER_PORT(integer)Port number where the server runs its service on an unsecured channel.

• T_OFF_C(integer)The maximum amount of time the client can wait if the server moves tooff state (in seconds). If this configuration exist, IS_CLIENT mustbe configured to true.

Chapter 6

Evaluation Setup

In this chapter, we discuss the setup and scenario of the evaluation on ouradaptive DoS counteraction protocol. The main purpose of the performedevaluation is to compare vanilla CoAP defined in RFC 7252 with our pro-posed CoAP embedding the DoS counteraction mechanism. We tested thejava code on the CoAP framework, Californium, specifically on version 1.0.3.The performances are measured in terms of Round Trip Time (RTT), CPU,and Memory Utilization. Aside from the comparison, since we introduce op-erative states on the server, we are interested in how long the server spendits time on each phase until it serves all of the legitimate requests. And last,to get better understanding on how our proposed solution works when it isunder heavy attack, we also measure the response reception pattern on twodifferent attack settings.

For all of our tests, we send valid requests from three clients while anadversary is performing Denial of Service attack towards the server. Thetraffic flow is depicted in Figure 6.1. The valid request is a confirmable CoAPmessage which has a purpose to access /helloWorld resource in the server.Then, a response message with "Hello World!" value is sent by the server.The valid request is always sent by a valid client who has been authenticatedby Key Distribution Center (KDC) before accessing the server. The validrequest is sent over UDP protocol so that no handshake is needed prior tothe connection.

On the other hand, the definition of attack message is a CoAP requestmessage (either Confirmable or NON-Confirmable type) being sent by oneor more client(s) which is not authenticated by the Key Distribution Cen-ter (KDC) prior to the connection to the server. Hence, through SMACK,

57

Chapter 6. Evaluation Setup 58

such messages will be considered as invalid and increase the invalid messagecounter on DoS Reaction module.

Figure 6.1 Measurement scenario

6.1 Testing Environment

6.1.1 Hardware

To perform our evaluation, we need a system that running on a lowcomputing resource hardware. This approach is chosen because we wantto show, at some point, by a certain injection rates, vanilla CoAP will reacha point where the attacks are occupying all the resource in the server. Onthe other hand, our proposed protocol still can serve the legitimate requestseven though the client needs to wait for some period of time. At first, wetried to evaluate our protocol with a virtualized server to act as a victimusing open source tool Virtual Box. By virtualizing the server, we can easilyset the server resource so that it can meet our requirements. However, wehad trouble with maintaining consistency of the result because the virtualmachine of the server is in the same hardware with other entities (KDC /proxy, client, and attacker), despite it is on different virtual machine.

To tackle that, we changed the server into a dedicated hardware usingRaspberry Pi 3 model B. But, we observed that Raspberry 3 is too strong tobe exhausted when it receives huge amount of attacks. That being said, we


need to reduce the resource of our raspberry by disabling and underclockingsome of the CPU. In short, Raspberry 3 model B is equipped with QuadCore 1.2GHz Broadcom BCM2837 64bit CPU. To get the device exhaustedwhen receiving huge attacks, we disabled 3 out of 4 CPUs, so that the serveris running only with 1 CPU. To get even lower resource, we underclock theonly single processor running so that it runs only with 850 MHz (instead of1.2 GHz) frequency. We perform this action solely because our computingresource on the attacker side is limited, therefore our victim server resourceneeds to be lowered. In a case where the attacker has unlimited resource,future tester of our software do not need to perform actions like what we did.The details on how we decrease the resource on Raspberry Pi 3 is explained inappendix A. The Raspberry Pi server connected to the machine Dell Inspiron5000 Series using ethernet cable. The laptop hosts all the rest entities: proxy,client, and attacker. All in all, since the server is now a dedicated hardware,we can perform the evaluation on the impact of attacks to the victim serverwith more confidence.

6.1.2 Software

The software dependencies for our evaluation tests is :

• Californium

6.1.3 Adversary

The adversary consist of a single computer (Dell Inspiron) which capableto send high rates of invalid requests. The resource of adversary is sharedwith other entity (clients and proxy), except the server.

6.1.4 Proxy/KDC

The proxy is hosted in the Dell Inspiron computer, sharing the resourcewith other entities, except the server.

6.1.5 Client

The client is also hosted in the Dell Inspiron computer, sharing the re-source with other entities, except the server.


6.2 Methodology

6.2.1 Scope and Scenario

We are interested in observing the effect of the injection rates variationsto the performance of the server. However, we also want to ensure that whilethe server is being attacked, we know the server is processing the incomingmessages. Therefore, we configure to send the requests over and over again.For a single measurement, the client sent 50 valid requests while at the sametime flooding the victim with different attack configurations until all of 50valid requests are replied or timed out. Our measurements are repeated for10 times each, and presented in a graph with 95% confidence level.

6.2.2 Tested Protocols

The protocols compared in these evaluation are :

• Vanilla Californium

• Adaptive Californium with Denial of Service counteraction apability

The following measurement is carried out :

• Round Trip Time (from the client point of view).

• CPU and Memory utilization (of the victim server).

Aside from measured variables above, we are interested in knowing howour design react to certain level of attacks, in terms of:

• Time spent on each phase (of the victim server).

• Response reception pattern (from the client point of view).

6.2.3 Configuration

The configuration on the server for our evaluation tests are:

• Th0_MAX = 90 invalid messages / epoch

• Th0_MIN = 10 invalid messages / epoch


• Th1_MAX = 160 invalid messages / epoch

• Th1_MIN = 80 invalid messages / epoch

• t0 = 3 seconds

• t1 = 3 seconds

• T1 = 15 seconds

• T2_MAX = 30 seconds

• T2_MIN = 20 seconds

• T_OFF_C = 40 seconds

The configurations above are determined heuristically based on the re-source of the server. Regarding the threshold, the higher the resource, thehigher also the threshold can be set. On the other hand, the lower the re-source, the lower also we can set the threshold. Furthermore, regarding thetime setting (t0, t1, T2_MAX, T2_MIN, T_OFF_C), it is not related tothe resource of the server, but purely on the design decision of the systemdesigner.

6.2.4 Attack Configuration

We define the attack towards the server is per epoch time when one epochis t0. The attack configuration of our evaluation tests are :

• AC0 = 0 attack / epoch (no attack)

• AC6 = 6 attack / epoch (negligible)

• AC60 = 60 attack / epoch (lower medium)

• AC120 = 120 attack / epoch (higher medium)

• AC180 = 180 attack / epoch (high attack)

Those values above are determined based on the configuration previouslyexplained in section 6.2.3, as we intend to cover all of the threshold valuewith the attack intensity.

Chapter 7

Results and Discussion

This chapter presents our tests results of the proposed solution. For eachtest below, we describe on how the test is performed, and then followed bythe results and its discussion respectively.

7.1 Round Trip Time

7.1.1 Tests Performed

The round trip time test is quite straightforward. Since we are interestedin how the attacks affecting the round trip time of legitimate requests, wemeasure the time interval between the client sends a valid request to theserver, until it receive the response for the corresponding request while atthe same time an adversary is performing Denial of Service attack with vari-ation of injection rates. The round trip time is indicated by (t1..t50) in thefigure 6.1. As the measurements are repeated 10 times, we show the valueof (t1..t50) with 95% confidence interval. In our tests, we have three clientsrunning at the same time, but for simplicity we are only showing the resultfrom one client perspective.

7.1.2 Results

Attack Configuration 0(AC0)

Figure 7.1 shows the RTT of 50 requests of vanilla and adaptive cali-fornium. During the whole period, vanilla californium shows persistent re-

62

Chapter 7. Results and Discussion 63

sults around 5 ms with a very small variation. However, there is a spike inthe first time of the measurement as the network is setting up the connection.

For adaptive californium, as explained in Chapter 4, the first time a clientwants to get access to the server resource, it has to contact the Key Distribu-tion Center (KDC) to obtain the necessary SMACK material. Furthermore,before being able to access the SMACK material on the KDC, the client hasto establish a DTLS session with KDC, therefore the first round trip timewill always be higher than the other. With AC0, the round trip time onthe vanilla Californium is lower than our solution in the order of ≈ 25 ms.This is because of short MAC computation on the client and server whichmakes the process takes longer than vanilla Californium. Furthermore, onour implementation, there are outlier observation points regularly occurs forevery 16 requests. This result is because of the formula to calculate KSj

fromequation 2.4, which stated that the ci part of the short MAC of i-th messageon a single session is 16 bits in KSj

where j = b(i + 2)/16c. This makes forevery 16 requests, starting from messages number 15, the client will alwaysrecalculate j to get ci of the short MAC.

Figure 7.1 Round Trip Time AC0

We can see from the figure 7.1 that our implementation have higher roundtrip time. It is an expected situation because we introduce additional process


that takes place in the client and server side. This information is importantfor the system designer as a foundation for their decision making process.If the additional overhead is worth to save the device resource when underattack (which we will show the result in the later section), then running thesystem with our solution can be considered.


Based on the server configuration in section 6.2.3, AC6 is considered asnegligible because the attack injection rate is below the threshold Th0_MIN .Based on the rules, in this situation, the server of our implementation willnot change its operative state other than normal.


As we can see from the graph, the vanilla californium is still performingthe same results. Meanwhile our proposed system is still quite stable inprocessing the legitimate requests while receiving such attacks, and shows asimilar behavior as AC0 on figure 7.1.



Considering our configuration on the server, AC60 is considered as lowmedium attack. Since the attack rates is higher than Th0_MIN and lowerthan Th0_MAX, the attack is expected to lowering the Th0 by half of theprevious value for every epoch. When Th0 reaches lower value than theattack rates, the server moves to protected state. Furthermore, after oneepoch, the server is expected to go back to normal state. However, sincethe attack is still exist and Th0 is set to Th0_MIN (every time the servergoes back again to normal state), therefore the server will always go back toprotected state again after one epoch. Hence, the server is expected to moveto the protected operative state for several times.


As we can see from the figure 7.3, vanilla californium performance is stillsimilar with the round trip time is around 5 ms. However, the round triptime of adaptive californium is considerably lower than the previous attackconfiguration. Since the server often in the protected state, it does not haveto compute short MAC both in the client or server side. Therefore, it takesshorter time to process the requests and reply messages compared to theprevious measurement. Yet, we still see from the graph that the round triptime of our implementation is still higher than the vanilla Californium in the


order of ≈ 20 ms because the request has to travel on a different path withadditional node (forward proxy) between client and server. The proxy has atask to forward valid requests from the client to the server, as well as relayingthe response back to the client.


Similar to the previous attack configuration, AC120 is considered asmedium, but much higher than before. When the server starts the oper-ation for the first time, the attack rate is already higher than Th0_MAX,which is the initial value of Th0 at initialization. Therefore, the server ismoving to protected state immediately after one epoch. Further operationof the server is the same as previous attack configuration AC60.


In this setting, vanilla californium still shows similar performance withthe round trip time is around 5 ms. However, we can begin to see some valuealteration in the graph due to instability of the system because of the attack.While in adaptive californium, most of the times the server is in the protectedoperative state, where all the valid requests are going to be forwarded by theproxy to the server through secure DTLS channel. We can see from figure 7.4


that the round trip times are also similar to the previous attack configuration.This is because the difference of time spent on the protected operative stateis not that much different compared to the previous one.


This is the highest attack configuration in our evaluation. The serveris expected to move to OFF state immediately after it starts the operationbecause the attack injection rate is already higher than Th1_MAX. Thetime spent in OFF state is a random number between T2_MIN (20 seconds)and T2_MAX (30 seconds). On the other hand, the vanilla Californium hasto handle and process all the incoming requests as all of them are consideredas valid requests by the victim server.


As can be seen from figure 7.5, the round trip time of vanilla Californiumis getting higher from time to time, until it reach the maximum point whichthe client can handle. This point is considered as timed out (40 seconds)where the client is basically give up on the request and move to processsubsequent request if any. The vanilla Californium gives up to process anymessages after 39 incoming requests onward. It is because the server is


overwhelmed by invalid messages from the adversary which occupy most ofthe resource of the server.

On the other hand, our implementation still can assures the client thatit always serves the requests to the best possible extent. As explained inthe previous chapter, we achieve this by leveraging a trusted proxy to shieldthe victim server, while the proxy is caching requests from legitimate clients.When the server goes back to protected state, it collects the cached requestsfrom the proxy and serves all of them in a burst fashion and goes back tooff state again if the attack still occurs. Due to high attack intensity in thismeasurement, most of the times the server is in OFF state and shuts downits interface to the outside world and saves its resources from being wastedprocessing unnecessary messages from the adversary.

On our implementation, we can see from figure 7.5 that the clients is ex-pected to receive responses from the server after waiting for approximately≈ 3000-25000 ms. Due to always increasing round trip time on the vanillaCoAP, our implementation already shows better performance on the requestnumber 29 until the rest of the measurement. That being said, the vanillaCalifornium can only handle request and perform better than our implemen-tation only for the first 29 request messages while under heavy attack. It iseven getting worse after 39 messages where the valid requests are not beingserved anymore due to high utilization on the victim server.


Figure 7.6 First Measurement of Round Trip Time AC180

Also, we can see a wide variations for round trip value on the graph ofour implementation. This is because transition times between states canbe slightly different in two different measurement. For example, the firstmeasurement might showed that the server went to off state after 4 requestsas can be seen on Figure 7.6, but our second measurement resulting that theserver went to off state after 5 requests as can be seen in Figure 7.7, and soon with other measurement.


Figure 7.7 Second Measurement of Round Trip Time AC180

This will make the RTT of request number 5 on the first measurementis incredibly high (because the server is in the off state), but our secondmeasurement does not say so. It shows low round trip time because theserver stills in the protected state. This condition will make the variationsof round trip time for each value on Figure 7.5 is high.

7.2 Time on Each Phase


This test is not a comparison of our implementation with the vanillaCalifornium but rather on how our implementation reacts to a certain levelof attack configuration in terms of time spent on each phase on the serverside. We want to understand the server behavior in terms of how long acertain state is being used by the server when it receives certain level ofattacks. In particular, the results shown in this test is the time interval fromthe server point of view, not from the client perspectives.


7.2.2 Results

Figure 7.8 shows the time spent on each phase for every Attack Configu-ration AC. As we can see from figure 7.8, when the attack does not exist oris negligible (AC0 and AC6), to process all the 50 valid requests, the serverspent all the time in normal phase. As we sent the requests every second, soit took 50 seconds to process all the valid requests. Moving to higher ratesof attack, we can see that the server starts to move to protected state forsome time when it receives medium rates of attack (AC60, AC120, AC140).However, the server still perform the operation in normal phase for smallperiod of time. This is because when T1 expires, the server will always moveback to normal phase for at least on epoch time during the transition.

Figure 7.8 Time spent on each phase

Moving to even higher attack rates (AC160, AC180) when the attackconfiguration is more than or equal to Th1_MAX, the server starts to moveto off state. The server has some period where the interface to outside worldis shut down. Off time (shown in blue) is when the clients have to wait untilthe server gets up again to process the message and serves them in a burstfashion. We can see that the higher the attack, more time is needed by theserver to serve all the valid requests from the clients.


7.3 Response Reception Pattern


Similar to the previous test, this test is not a comparison of our im-plementation with the vanilla Californium either. We want to understandbetter how the requests from the clients will be served when the server isunder different attack intensity (AC6 and AC180). To perform this test, wehave three clients, namely client1, client2, and client3 who send requests tothe server on a regular basis. When client1 receives a response for the cor-responding request, we note the timestamp as well as other requests fromother clients. Based on the noted timestamp on the client, we compare theresponse reception pattern on the client side. Similar to the previous test,for the valid message request, we use confirmable message trying to accessresource on the server namely "/helloworld" resource with "Hello World!"value. If the incoming messages is valid (checked by SMACK mechanism),the server should process the request and send back the reply right away. Ifthe server is in off state, the client has to wait for a certain amount of time asspecified in the configuration of this evaluation (section 6.2.3). The resultsshown in this test is the timestamp from the client point of view, notfrom the server perspectives.

7.3.2 Results

Low Attack

Figure 7.9 shows the response reception pattern from three different clientperspective on AC6. We can see from figure 7.9 that all the clients are alwaysreceive the response right away after it sends them (every second). This isbecause the server is always in normal state.


Figure 7.9 Reception Pattern AC6

In this attack setting, our implementation serves the clients at the earliestconvenience. The client expect to receives the response immediately afterthey send the requests.

High Attack

On the other hand, as we see on figure 7.10, when the server is on AC180,it serves the clients in a burst fashion, where the blank point between re-ceiving response is when the server is in off state. While the server is inoff state, the proxy caches all the incoming requests only if the client canhandle the amount of time the server goes into off state (T_OFF_C > T2).Then, when the server goes back to protected state, it retrieves all the cachedrequest on the proxy and process them sequentially. The server has only 3seconds chances to process all of the messages as configured in T1. The serverthen moves back again to OFF state for some period of time (between 20and 30 seconds), and repeat the previous process until all the request fromthe clients are served.


Figure 7.10 Reception Pattern AC180

We can compare from figure 7.9 and 7.10 that there is a difference onhow the server serves the requests when it is under different attack injections.When it receives relatively low attacks (AC6) so that it does not have to moveto other state, it serves the clients at the earliest convenience. On the otherhand, when it receives high attacks (AC180) the server becomes adaptive tothe attack and moves to protected state, and eventually to off state. In thiscase, the clients have to wait until the server goes back to protected stateagain to get served. The cycle of moving back and forth between protectedand off is repeated until all the valid requests are served. Therefore, theclients see they are being served by the server in a burst fashion during theprotected state.

7.4 CPU and Memory Utilization


We perform this test in order to get better understanding about the re-source utilization of the server under different attack injection rates. Thefinal expected output is the comparison between our proposed solution withthe vanilla Californium by applying the same attack configuration. Since we


are not implementing our solution to the real constrained device, we believeit is important to measure CPU and Memory utilization, because the energyconsumption is highly correlated to the CPU and Memory.

Similar to the previous one, in this test, the clients send 50 valid requestswhile the victim server receives variations of attack injection rates. At thesame time, we measure the CPU and Memory utilization of the serveruntil all the valid requests are being served by the server or timed out. Theinformation of CPU and memory utilization is extracted from /proc/cpuand /proc/meminfo respectively inside the raspbian operating system. Werecord those two files every second for the whole service period of the server,and finally, we calculate the average value and draw the comparison graph.

7.4.2 Results

Figure 7.11 shows the memory utilization of the victim server under dif-ferent attack configuration. From figure 7.11, we can see that, when theserver receives no attack, vanilla Californium performs better compared toour implementation. However, when it starts to receive attacks with varia-tions of injection rates, our solutions performs better compared to the vanillaCalifornium.

Figure 7.11 Memory Utilization


The reason is that the server silently discards all the invalid incomingrequests from the adversary because it considers them as invalid messages.On the other hand, since vanilla Californium does not have the capabilityto distinguish between valid and invalid messages, it has to process all ofthem, hence the attack messages are consuming the memory on the server.As seen from the graph, in terms of memory utilization, our solution can savethe memory on the victim server compared to the vanilla Californium. Also,as the attacks are getting more intense, our solution can still save the sameamount of memory utilization for variations of attack configurations (AC6,AC60, AC120, AC180).

Furthermore, we measure the CPU utilization while the server being at-tacked by variations of attack injection rates. Figure 7.12 shows the CPUutilization of the victim server under different attack configuration.

Figure 7.12 CPU Utilization

As can be seen from figure 7.12, when there is no attack to the server,vanilla californium performs better than adaptive californium. Adaptive im-plementation uses 3% more of CPU utilization to perform the additionalcomputation of the messages exchange. Moving to higher attack injectionrate AC6, vanilla californium still performs better than adaptive californiumin the order of 3%. However, as we move to higher injection rates (AC60 and


AC120), we can see that our implementation is saving a lot of CPU resource.Similar to the memory case, the reason of this performance is that the serveris silently discarding all the attack messages after it consider the messagesas invalid using SMACK mechanism. Therefore, the server does not have toperform further computation and waste additional CPU resources just forprocessing invalid messages.

On the other hand, the vanilla CoAP Californium utilization is alwaysincreasing rapidly as the attacks go higher. This is because it has to processall the incoming messages (either valid or invalid), so that those processesoccupy a lot of resource in the CPU. As the highest attack configurationAC180, the vanilla Californium is reaching almost 100% CPU utilization inaverage. This high rates of attack is simply killing the server, as alreadymentioned in the previous results that the server is not responsive anymorefor any valid request. However, our implementation still serves the valid re-quests and maintain the CPU utilization at 10%. We achieve this by shuttingdown the interface of the server for some period of time while the proxy iscaching all the valid requests. And last, by maintaining the level of CPUutilization, the server can provides the service assurance to the best possibleextent and in a burst fashion.

7.5 Experiments ConclusionFor the RTT tests on AC0-AC120, our solution introduce additional over-

head varies between 15-25 ms compared to the vanilla implementation. Thisis expected as our solution performs additional computation in the client andserver side. However, for the AC180 when the attacker is simply killing thevanilla implementation device, our solution can still help serving the clientin a best-effort and burst fashion. Regarding the time spent on each phase,we can infer that the higher the attack injection rates, the server will mostlikely spent the operation time in the higher operative states (Phase1 andPhase2).

About the resource utilization (CPU and Memory), our solution is mostlikely introduce small additional overhead when there is no or low attackconfiguration. However, when the victim experiencing high load of attacks,our solution can help reducing the CPU utilization by almost 90%.

Chapter 8

Conclusion and Future Work

8.1 ConclusionWe have designed and implemented a context-aware, cross-layer, and

adaptive approach to react upon Denial of Service attack based on floodingserver units with invalid messages. Our solution provides service availabil-ity of the server to the best extent even under attack. To achieve this, weleverage a trusted proxy (acting also as Key Distribution Center) to shieldthe victim from DoS attacks, while forwarding/caching requests from legit-imate clients. The proxy also assists the server in changing its operativestate, based on the attack intensity. The server dynamically shifts betweena normal operative state, a limited service state (protected), and an off stateduring which the proxy caches messages addressed to the server.

We have implemented this approach, considering CoAP as applicationlayer communication protocol. To detect invalid messages, we rely on ashort MAC embedded in the CoAP messages. Nevertheless, our approach isgeneral and can be used in the presence of different communication stacks.

We have experimentally evaluated the server performance and the qual-ity of service experienced by legitimate clients, considering different attacksettings. Results show that even under heavy attack, our proposed solutionreduces the impact on the server in terms of CPU and memory utilization.Furthermore, our proposed solution preserve a best-effort capability to serveclients, even when the server is under heavy attack.

78

Chapter 8. Conclusion and Future Work 79

8.2 Future WorkFirst, as we mentioned in the limitation section, we introduced additional

configurable parameters in which the values are determined heuristically. Itwill be interesting to develop a formal equation to derive such values usingany possible approach, e.g. performing more experiment.

Second, it will be interesting to investigate how this approach can benefitresource-constrained servers under attack. In particular, this would open theway for evaluating how our solution can reduce the attack impact on theenergy consumption of constrained servers. To this end, an implementationfor Contiki OS or other similar platforms for constrained devices is required.

Besides, further extensive assessment would be possible by making ourapproach leverage detection of invalid messages based on multiple mecha-nisms at different layers of the stack at the same time. These include, forinstance, the record layer of the Datagram Transport Layer Security (DTLS)protocol.

Bibliography

[1] M. Kovatsch, M. Lanter, and Z. Shelby, “Californium: Scalable cloudservices for the internet of things with coap,” in 2014 International Con-ference on the Internet of Things (IOT), Oct 2014, pp. 1–6.

[2] N. Heuveldop. (2017) Ericsson mobility report. [Online].Available: https://www.ericsson.com/assets/local/mobility-report/documents/2017/ericsson-mobility-report-june-2017.pdf

[3] G. Kortuem, F. Kawsar, V. Sundramoorthy, and D. Fitton, “Smart ob-jects as building blocks for the internet of things,” IEEE Internet Com-puting, vol. 14, no. 1, pp. 44–51, Jan 2010.

[4] L. Atzori, A. Iera, and G. Morabito, “The internet of things: A survey,”Comput. Netw., vol. 54, no. 15, pp. 2787–2805, Oct. 2010. [Online].Available: http://dx.doi.org/10.1016/j.comnet.2010.05.010

[5] T. Martin, M. Hsiao, D. Ha, and J. Krishnaswami, “Denial-of-serviceattacks on battery-powered mobile computers,” in Second IEEE AnnualConference on Pervasive Computing and Communications, 2004. Pro-ceedings of the, March 2004, pp. 309–318.

[6] F. Stajano and R. Anderson, “The resurrecting duckling: security issuesfor ubiquitous computing,” Computer, vol. 35, no. 4, pp. 22–26, Apr2002.

[7] D. R. Raymond, R. C. Marchany, M. I. Brownfield, and S. F. Midkiff,“Effects of denial-of-sleep attacks on wireless sensor network mac pro-tocols,” IEEE Transactions on Vehicular Technology, vol. 58, no. 1, pp.367–380, Jan 2009.

80

https://www.ericsson.com/assets/local/mobility-report/documents/2017/ericsson-mobility-report-june-2017.pdf

https://www.ericsson.com/assets/local/mobility-report/documents/2017/ericsson-mobility-report-june-2017.pdf

http://dx.doi.org/10.1016/j.comnet.2010.05.010

Bibliography 81

[8] A. Back, U. Möller, and A. Stiglic, “Traffic analysis attacks and trade-offsin anonymity providing systems,” in International Workshop on Infor-mation Hiding. Springer, 2001, pp. 245–257.

[9] C.-M. Cheng, H. T. Kung, and K.-S. Tan, “Use of spectral analysis indefense against dos attacks,” in Global Telecommunications Conference,2002. GLOBECOM ’02. IEEE, vol. 3, Nov 2002, pp. 2143–2148 vol.3.

[10] M. Tiloca, C. Gehrmann, and L. Seitz, “On improving resistance todenial of service and key provisioning scalability of the dtls handshake,”Int. J. Inf. Secur., vol. 16, no. 2, pp. 173–193, Apr. 2017. [Online].Available: https://doi.org/10.1007/s10207-016-0326-0

[11] J. Mirkovic, S. Dietrich, D. Dittrich, and P. Reiher, Internet Denialof Service: Attack and Defense Mechanisms (Radia Perlman ComputerNetworking and Security). Upper Saddle River, NJ, USA: Prentice HallPTR, 2004.

[12] H. Wang, C. Jin, and K. G. Shin, “Defense against spoofed ip traffic usinghop-count filtering,” IEEE/ACM Transactions on Networking, vol. 15,no. 1, pp. 40–53, Feb 2007.

[13] J. Li, M. Sung, J. Xu, and L. Li, “Large-scale ip traceback in high-speedinternet: practical techniques and theoretical foundation,” in IEEE Sym-posium on Security and Privacy, 2004. Proceedings. 2004, May 2004, pp.115–129.

[14] S. Savage, D. Wetherall, A. Karlin, and T. Anderson, “Practicalnetwork support for ip traceback,” in Proceedings of the Conference onApplications, Technologies, Architectures, and Protocols for ComputerCommunication, ser. SIGCOMM ’00. New York, NY, USA: ACM,2000, pp. 295–306. [Online]. Available: http://doi.acm.org/10.1145/347059.347560

[15] A. C. Snoeren, C. Partridge, L. A. Sanchez, C. E. Jones, F. Tchakountio,S. T. Kent, and W. T. Strayer, “Hash-based ip traceback,” SIGCOMMComput. Commun. Rev., vol. 31, no. 4, pp. 3–14, Aug. 2001. [Online].Available: http://doi.acm.org/10.1145/964723.383060

[16] D. X. Song and A. Perrig, “Advanced and authenticated markingschemes for ip traceback,” in INFOCOM 2001. Twentieth Annual Joint

https://doi.org/10.1007/s10207-016-0326-0

http://doi.acm.org/10.1145/347059.347560

http://doi.acm.org/10.1145/347059.347560

http://doi.acm.org/10.1145/964723.383060

Bibliography 82

Conference of the IEEE Computer and Communications Societies. Pro-ceedings. IEEE, vol. 2. IEEE, 2001, pp. 878–886.

[17] P. Ferguson and D. Senie, “Network ingress filtering: Defeating denial ofservice attacks which employ ip source address spoofing,” United States,2000.

[18] J. Li, J. Mirkovic, M. Wang, P. Reiher, and L. Zhang, “Save: sourceaddress validity enforcement protocol,” in Proceedings.Twenty-First An-nual Joint Conference of the IEEE Computer and Communications So-cieties, vol. 3, June 2002, pp. 1557–1566.

[19] R. Mahajan, S. M. Bellovin, S. Floyd, J. Ioannidis, V. Paxson, andS. Shenker, “Controlling high bandwidth aggregates in the network,”SIGCOMM Comput. Commun. Rev., vol. 32, no. 3, pp. 62–73, Jul.2002. [Online]. Available: http://doi.acm.org/10.1145/571697.571724

[20] D. K. Y. Yau, J. C. S. Lui, and F. Liang, “Defending against distributeddenial-of-service attacks with max-min fair server-centric router throt-tles,” in IEEE 2002 Tenth IEEE International Workshop on Quality ofService (Cat. No.02EX564), 2002, pp. 35–44.

[21] R. Y. Patil and L. Ragha, “A rate limiting mechanism for defendingagainst flooding based distributed denial of service attack,” in 2011World Congress on Information and Communication Technologies, Dec2011, pp. 182–186.

[22] H. Beitollahi and G. Deconinck, “A cooperative mechanism to defenseagainst distributed denial of service attacks,” in Trust, Security andPrivacy in Computing and Communications (TrustCom), 2011 IEEE10th International Conference on. IEEE, 2011, pp. 11–20.

[23] D. Dean, M. Franklin, and A. Stubblefield, “An algebraic approach to iptraceback,” ACM Trans. Inf. Syst. Secur., vol. 5, no. 2, pp. 119–137, May2002. [Online]. Available: http://doi.acm.org/10.1145/505586.505588

[24] M. T. Goodrich, “Efficient packet marking for large-scale ip traceback,”in Proceedings of the 9th ACM Conference on Computer andCommunications Security, ser. CCS ’02. New York, NY, USA: ACM,2002, pp. 117–126. [Online]. Available: http://doi.acm.org/10.1145/586110.586128

http://doi.acm.org/10.1145/571697.571724

http://doi.acm.org/10.1145/505586.505588

http://doi.acm.org/10.1145/586110.586128

http://doi.acm.org/10.1145/586110.586128

Bibliography 83

[25] N. Bhatti and R. Friedrich, “Web server support for tiered services,”IEEE Network, vol. 13, no. 5, pp. 64–71, Sep 1999.

[26] X. Qie, R. Pang, and L. Peterson, “Defensive programming:Using an annotation toolkit to build dos-resistant software,” inProceedings of the 5th Symposium on Operating Systems Design andimplementationCopyright Restrictions Prevent ACM from Being Ableto Make the PDFs for This Conference Available for Downloading,ser. OSDI ’02. Berkeley, CA, USA: USENIX Association, 2002, pp.45–60. [Online]. Available: http://dl.acm.org/citation.cfm?id=1060289.1060295

[27] D. J. Bernstein, “Syn cookies,” 1996.

[28] S. Ranjan, R. Swaminathan, M. Uysal, and E. Knightly, “Ddos-resilientscheduling to counter application layer attacks under imperfect detec-tion,” in Proceedings IEEE INFOCOM 2006. 25TH IEEE InternationalConference on Computer Communications, April 2006, pp. 1–13.

[29] A. Juels and J. G. Brainard, “Client puzzles: A cryptographic counter-measure against connection depletion attacks.” in NDSS, vol. 99, 1999,pp. 151–165.

[30] X. Wang and M. K. Reiter, “Defending against denial-of-service attackswith puzzle auctions,” in 2003 Symposium on Security and Privacy,2003., May 2003, pp. 78–92.

[31] O. Voitovych, Y. Baryshev, E. Kolibabchuk, and L. Kupershtein, “Inves-tigation of simple denial-of-service attacks,” in 2016 Third InternationalScientific-Practical Conference Problems of Infocommunications Scienceand Technology (PIC S T), Oct 2016, pp. 145–148.

[32] M. Abadi, M. Burrows, M. Manasse, and T. Wobber, “Moderatelyhard, memory-bound functions,” ACM Trans. Internet Technol.,vol. 5, no. 2, pp. 299–327, May 2005. [Online]. Available:http://doi.acm.org/10.1145/1064340.1064341

[33] B. Parno, D. Wendlandt, E. Shi, A. Perrig, B. Maggs, and Y.-C.Hu, “Portcullis: Protecting connection setup from denial-of-capabilityattacks,” SIGCOMM Comput. Commun. Rev., vol. 37, no. 4, pp.

http://dl.acm.org/citation.cfm?id=1060289.1060295


http://doi.acm.org/10.1145/1064340.1064341

Bibliography 84

289–300, Aug. 2007. [Online]. Available: http://doi.acm.org/10.1145/1282427.1282413

[34] N. C. O and S. Mathivanan, “A survey on resource inflated denial ofservice attack defense mechanisms,” in 2016 Online International Con-ference on Green Engineering and Technologies (IC-GET), Nov 2016,pp. 1–4.

[35] Z. Wu, M. Xie, and H. Wang, “Energy attack on server systems,” inProceedings of the 5th USENIX Conference on Offensive Technologies,ser. WOOT’11. Berkeley, CA, USA: USENIX Association, 2011, pp.8–8. [Online]. Available: http://dl.acm.org/citation.cfm?id=2028052.2028060

[36] A. Garg and A. L. N. Reddy, “Mitigation of dos attacks through qos reg-ulation,” in IEEE 2002 Tenth IEEE International Workshop on Qualityof Service (Cat. No.02EX564), 2002, pp. 45–53.

[37] D. R. Raymond and S. F. Midkiff, “Clustered adaptive rate limiting:Defeating denial-of-sleep attacks in wireless sensor networks,” in MIL-COM 2007 - IEEE Military Communications Conference, Oct 2007, pp.1–7.

[38] C. Gehrmann, M. Tiloca, and R. Höglund, “Smack: Short message au-thentication check against battery exhaustion in the internet of things,”in 2015 12th Annual IEEE International Conference on Sensing, Com-munication, and Networking (SECON), June 2015, pp. 274–282.

[39] Z. Shelby, K. Hartke, and C. Bormann, “Rfc 7252—the constrainedapplication protocol (coap),” Internet Engineering Task Force (IETF),2014.

[40] N. Modadugu and E. Rescorla, “The design and implementation of data-gram tls,” in In Proc. NDSS, 2004.

[41] E. Rescorla and N. Modadugu, “Rfc 6347—datagram transport layersecurity version 1.2,” Internet Engineering Task Force (IETF), 2012.

[42] T. Dierks, “The transport layer security (tls) protocol version 1.2,” 2008.

[43] R. J. McEliece, Finite fields for computer scientists and engineers.Springer Science & Business Media, 2012, vol. 23.

http://doi.acm.org/10.1145/1282427.1282413

http://doi.acm.org/10.1145/1282427.1282413



Appendix A

Underclocking Raspberry Pi 3

To perform CPU underclocking in Raspberry Pi 3, the following procedureis needed:

1. Open /boot/config.txt.

2. Add arm_freq parameter and change the value as desired, for example:arm_freq=850.

3. Reboot.

85

TRITA EE 2017:119

www.kth.se

Adaptive Counteraction Against Denial of Service Attack1162616/... · · 2017-12-04DEGREE PROJECT...

Documents

Transcript of Adaptive Counteraction Against Denial of Service Attack1162616/... · · 2017-12-04DEGREE PROJECT...