TELKOM
NIKA Indonesia
n
Journal of
Electrical En
gineering
Vol. 12, No. 12, Decembe
r
2014, pp. 83
3
5
~ 834
3
DOI: 10.115
9
1
/telkomni
ka.
v
12i12.68
15
8335
Re
cei
v
ed Se
ptem
ber 14, 2014; Revi
se
d Octob
e
r 27,
2014; Accept
ed No
vem
b
e
r
16, 2014
Performance Comparison of Host Identity Protocol and
TCP/IP with Firewall against Denial of Services
Alfan Pre
sek
al*
1
, Riri Fitri Sari
2
Dep
a
rtment of Electrical E
ngi
neer
ing, Un
iver
sitas
Indon
esi
a
, Kampus Baru
UI Depok 16
4
24, Indo
nesi
a
*Corres
p
o
ndi
n
g
author, e-ma
i
l
: alfanpr
esek
al
@gmai
l
.com
1
, riri@ui.ac.id
2
A
b
st
r
a
ct
Host Ide
n
tity Protocol (HIP)
is a new
kin
d
of
Internet p
r
otocol w
h
ic
h has b
een
dev
elo
ped
t
o
resolv
e the e
x
isting pr
obl
e
m
s of Internet
protocol
T
C
P
/IP. As a new
protocol HIP provid
es man
y
adva
n
tag
e
s co
mp
are
d
to T
C
P/IP such as
in th
e as
pect
of sec
u
rity a
nd
mobi
lity. U
n
fortunate
l
y, t
h
e
dep
loya
bil
i
ty ra
te of HIP w
a
s s
t
ill l
o
w
.
One of
the reas
on
is b
e
caus
e p
a
rticul
ar sol
u
tio
n
for
currently Int
e
rn
et
prob
le
ms
alre
a
d
y p
opu
lar
an
d
de
ploy
ed w
o
rl
dw
ide. In
th
is
w
o
rk w
e
comp
are th
e p
e
rfor
ma
nce
of HIP
and
T
C
P/IP using s
e
vera
l sce
nari
o
s. Simulati
ons
result sh
ow
tha
t
T
C
P respo
n
s
e
time i
n
n
o
r
m
al co
nditi
on (
z
e
r
o
attack cond
itio
n) 98,62
7
ms, w
h
ile HIP ha
s the resp
o
n
s
e
time of 99,7
11
ms. W
e
also co
mpar
e th
e
perfor
m
a
n
ce of
the HIP, T
C
P/IP, and SSL
a
gai
nst the l
o
w
to me
di
u
m
De
nial
of Servic
e
s
attack (DoS).
In
the cond
itio
n of low
to medi
u
m
Do
S attack, the order fro
m
b
e
st perfo
r
m
anc
e are T
C
P/IP,
HIP, and then th
e
w
o
rst one
is S
S
L. In the
con
d
itio
n of
hig
h
DoS
atta
ck thr
ee
of the
m
T
C
P/IP, SSL, and
HIP can
not w
o
rk.
Only HIP that imp
l
e
m
e
n
ts HIP Firew
a
ll w
i
th author
i
z
a
t
io
n s
c
enar
ios that a
r
e still ava
ila
bl
e for service.
Ke
y
w
ords
: ho
st identity proto
c
ol, den
ial
of servic
e, inter
net
protocol, secu
rity, firew
a
ll
Copy
right
©
2014 In
stitu
t
e o
f
Ad
van
ced
En
g
i
n
eerin
g and
Scien
ce. All
rig
h
t
s reser
ve
d
.
1. Introduc
tion
Internet
te
ch
nology devel
opment ha
s gone
thro
ugh
a lot
of succe
s
s sto
r
ie
s
sin
c
e th
e
first impl
eme
n
tation of th
e Intern
et. T
he Internet h
a
s
had
en
ormous imp
a
ct
on
peo
ple li
ve
arou
nd the
world. On
e of the indi
cator i
s
the
growi
n
g numb
e
r of
the use
r
. Unf
o
rtunately th
ere
are still probl
ems that is e
m
bedd
ed into
the existing
Internet a
r
chitecture
[1]. The first desi
gn
of
the
Intern
et wa
s cre
a
ted without co
nsi
derin
g
the
future
ch
allen
g
e
of the Inte
rn
et. The o
r
igi
n
al
Internet wa
s
develop
ed un
der research
netwo
rk in
USA. In
the first implementat
ion, the Internet
wa
s only for rese
arch pu
rp
ose
s
. In the next stage,
the growth of the
Internet wa
s uncontroll
ed to
spread
aro
u
n
d
the wo
rld. After Internet
beca
m
e
po
p
u
lar ma
ny problem
s ari
s
e
such a
s
lack of
se
curity, the limited addre
ss ava
ila
bility, and also m
obility. For example seve
ral larg
e-scal
e
se
curity thre
ats i.e. IP spo
o
fing, di
stributed
d
eni
al of se
rvice (DDoS
)
a
ttack, phi
shi
ng,
vulnera
b
ility scanni
ng, intrusi
on a
nd
wide
-s
pread
worm infecti
on have b
e
en long
sta
y
ed
unresolved, one of the
reason i
s
because of the lack of the
accountability mechanism
s
i
n
the
c
u
rrent Internet protoc
ol [2, 3].
To solve current p
r
obl
em
s of the Inte
rnet
ma
ny
id
eas we
re propo
sed, som
e
of
the
resea
r
ch try to re
de
sign th
e ba
sic
proto
c
ol of the
Internet [4]. As
an exampl
e t
here
are several
idea
s pro
p
o
s
ed to create future Internet
Protocol
i.e. IP Sec [5], Accounta
b
le In
ternet Proto
c
ol
(AIP) [6], and Mobile IP [7]. Those id
ea
s we
re p
r
op
o
s
ed b
e
cau
s
e
the Internet p
r
otocol TCP/IP
has ma
ny weakne
sses a
nd hard to face the fu
tu
re Intern
et challen
ge. Mo
reove
r
TCP/IP
proto
c
ol
s,
wh
ich
on
ce
acte
d a
s
the
ba
si
c p
r
oto
c
ol
of the
current
In
ternet have b
een una
ble
t
o
provide
se
cu
re platform for commu
nications [8]. Many
ideas tal
k
ab
out future Internet p
r
oto
c
ol
to
repla
c
e
existi
ng majo
r Inte
rnet p
r
oto
c
ol
TCP/IP. O
ne
of the sol
u
tio
n
s that i
s
alre
ady pro
p
o
s
ed
b
y
the IETF is Host Identity Protocol (HIP) [
9
, 10].
HIP enha
nce
s
the o
r
igin
a
l
Internet a
r
chite
c
ture
by adding
a n
e
w n
a
me
spa
c
e
s
for
splitting th
e h
o
st a
nd th
e l
o
catio
n
id
enti
f
ier. Th
e
ho
st
identity of
HIP no l
onge
r
use
IP ad
dre
ss,
HIP uses
cryptograp
hic
key a
s
ho
st
identity.
This ki
nd of th
e ho
st identi
t
y will enha
nce
accountability of the
protocol.
Moreov
er
HIP
al
so proposed another sol
u
tion
for
the other
probl
em
s, su
ch a
s
fo
r m
o
b
ility issue
s
HI
P can
han
dle
mobility thro
ugh its p
r
otocol. Unfo
rtunat
ely
the deployment of HIP i
s
still low.
One
of the
reason that made
deployability rate of
HIP low i
s
becau
se several
solutio
n
s for cu
rrent Internet
p
r
obl
ems h
a
ve be
en depl
oyed [
11]. For exa
m
ple
Evaluation Warning : The document was created with Spire.PDF for Python.
ISSN: 23
02-4
046
TELKOM
NI
KA
Vol. 12, No. 12, Decem
ber 20
14 : 8335 – 83
43
8336
due to th
e la
ck
of security in TCP/IP protocol,
the
r
e
is SSL p
r
oto
c
ol that tri
ed
to enha
nce t
h
e
se
curity a
s
pe
ct of the Inte
rnet. Cu
rrentl
y
SSL
is alre
ady well
kno
w
n a
nd d
e
pl
oyed world
w
i
de.
The next example is Mobil
e
IP that tries to improv
e mobility aspect of the Internet. Both of them
are g
ood
sol
u
tion for th
e
existing Int
e
rnet p
r
o
b
le
ms. Unfortun
ately the sol
u
tions
we
re
not
integrate
d
. T
hat is th
e re
aso
n
why HI
P tried intr
od
uce i
n
teg
r
ate
d
sol
u
tion fo
r variou
s Inte
rne
t
chall
enge
s in
a singl
e proto
c
ol.
In the follo
wi
ng
se
ction
s
,
we
give a
re
view o
n
the Internet
s
e
c
u
rity is
s
u
es
,
Denial
of
Serv
ice
s
(
D
o
S
) attac
k
. After that w
e
di
s
c
u
ss v
a
riou
s related re
sea
r
ch
to
pic ba
ckgroun
d
such
as
HIP and
SSL
as security p
r
otocol a
nd
al
so th
r In
trusi
on Dete
ction System
(I
DS). Then
the
ne
xt
se
ction will
explain abo
u
t
the propo
sed scen
ario
s. Finally, we analyze a
n
d
con
c
lu
de the
obtaine
d re
su
lts from seve
ral scena
rio
s
.
1.1. Host Ide
n
tit
y
Protocols
Ho
st Identity Proto
c
ol
(HIP) i
s
a
p
r
otoc
ol that
has be
en
p
r
opo
se
d by
Internet
Enginee
ring
Task Force
(IETF) sin
c
e 1
999. The fi
rst implementati
o
ns of HIP wi
th stable version
start
s
in the year 2
007. Th
e origi
nal ide
a
s for
HI
P archite
c
ture
gre
w
from the d
e
s
ire to p
r
ovid
e a
mean
s for providing better suppo
rt for secu
rity and
mobility within the IP archite
c
ture. The m
a
in
prin
cipal
of
HIP is th
e e
nhan
cem
ent
of the o
r
ig
in
al Intern
et a
r
chite
c
ture
by
addi
ng a
n
a
me
spa
c
e
s
b
e
tween IP laye
rs a
nd tran
sport p
r
oto
c
ol
.
This ne
w name sp
ace
co
nsi
s
ts of
the
cryptog
r
a
phi
c identifier and
locator
split.
With im
prove
m
ent o
n
the
archite
c
tural
as
pe
ct
,
HI
P
ca
n
deliv
er
sol
u
t
i
on f
o
r
sev
e
ral
Internet issu
es such a
s
mobility, multi-homi
ng,
and also
end-to
-
en
d
security. The
impleme
n
tation of
cryptog
r
aphi
c i
dentifi
e
rs
will
en
ha
nce
the
acco
untability of
HIP. With th
ose
impleme
n
tation
HIP can
enha
nce the
priva
c
y, goo
d lo
cation
an
onymity, and
assu
ring
st
rong
identities [12]
.
HIP Archite
c
ture imple
m
e
n
ts identifie
r and lo
cator split that different with
existing
TCP/IP proto
c
ol. In the existing Internet, each h
o
st
h
a
s
an IP add
re
ss that h
a
ve two fun
c
tion
s; it
acts both
a
s
locator to d
e
scrib
e
cu
rre
nt topol
o
g
ical
location i
n
t
he n
e
two
r
k,
and
as a
ho
st
identifier to
d
e
scrib
e
the
i
dentity of the
ho
st.
On th
e othe
r
side t
he
HIP se
parates th
e lo
ca
tor
and ide
n
tifier role
s of the
IP addre
s
s b
y
introdu
cing
a new
name
spa
c
e, the
Ho
st Identity (HI)
name spa
c
e.
Host identit
y is a public cryptog
r
aphi
c key from a
public-privat
e
key pair. T
h
e
publi
c
key ca
n be acce
ss by any partie
s
, but t
he priv
ate key only acce
ssi
ble by
its owne
r.
HIP can provide more a
c
co
untable conn
ection
comp
a
r
ed to TCP/IP protocol. As sho
w
n
in Figu
re
1
the T
C
P/IP before
conn
ection
e
s
tabl
ishe
d, there
is
me
cha
n
ism
pa
cket b
a
se
-
excha
nge
cal
l
ed thre
e-wa
y hand sha
k
e. The HIP
mech
ani
s
m
of the ba
se-excha
nge b
e
f
ore
con
n
e
c
tion e
s
tabli
s
he
d is
slightly different. Du
ring t
he conn
ectio
n
initialization
betwe
en the
two
HIP host
s
th
ere i
s
a four-way han
dsha
ke. Du
rin
g
the excha
nge,
the host
s ide
n
tify each ot
her
use
s
pu
blic
key cryptog
r
ap
hy. In this ba
se-exc
h
ang
e
the host
s ne
g
o
tiate with th
e crypto
gra
p
h
y
proto
c
ol
s to use to prote
c
t the sig
naling
and t
he data
massag
es. Basi
cally in HI
P one more
step
is nee
ded for
the base-ex
chang
e be
cau
s
e of the veri
f
i
cation p
r
o
c
e
ss b
e
twe
en two ho
sts. By this
kind of me
ch
anism
HIP wil
l
provide a be
tter ac
counta
b
le co
nne
ctio
n for the Internet use
r
s.
Figure 1. Co
mpari
s
o
n
of HIP and TCP
/IP Base Exchang
e
Evaluation Warning : The document was created with Spire.PDF for Python.
TELKOM
NIKA
ISSN:
2302-4
046
Perform
a
n
c
e
Com
pari
s
o
n
of Host Identi
t
y Protoc
ol an
d TCP/IP with Firewall… (A
lfan Presekal)
8337
HIP Base Excha
nge
con
s
i
s
ts of four m
e
ssag
es, two
message
s from initiator h
o
st (I1
and I2) an
d two messa
g
e
s
from re
sp
o
nder h
o
st (R1 and R2). The I1 message is a trig
ger
messag
es
ca
n be con
s
i
s
t of initiator and respon
der
HIT. It is possible to use NULL me
ssa
ge in
I1. The next
messag
e R1
respon
de
r already kno
w
in
itiator HIT so
in R1 re
spo
n
der will en
cryp
t
the messages by us
ing HI
T from initiator. After that, initia
tor
will prove its true identity by solvi
n
g
R1 me
ssage
from respo
nder u
s
in
g its private ke
y. Then initiator will sen
d
messag
e I2 to
respon
de
r en
crypted
usin
g
respond
er
HIT. As a
final Base Exch
an
ge re
spo
nde
r will sen
d
R2
to
initiator indi
ca
te if the conn
ection
will sta
r
t soon.
HIP u
s
ing th
e 12
8-bit
pu
blic
key
as
Ho
st Identity Tag
(HIT).
HIT loo
k
s li
ke an
IPv6
address with the speci
a
l 28-bit
prefix 2001:0010::/28,
called Orchid. The next part is 100 bits
taken f
r
om
a
crypto
gra
phi
c ha
sh
of the
publi
c
key. From th
e p
r
o
t
ocol
side,
HI
P con
s
i
s
ts of
a
control p
r
oto
c
ol, a
num
b
e
r of
exten
s
ions to
the
control
protocol, and
any
numbe
r
of d
a
ta
proto
c
ol
s. By default, the HIP c
ontrol
protocol is carrie
d dire
ct
ly in IPv4 and IPv6 packets,
without any in
tervening T
C
P or UDP he
ader.
The archite
c
tural en
han
ce
ment implem
ent
ed by HIP has profo
u
nd con
s
e
que
nce
s
. A
numbe
r of the previou
s
ly hard n
e
two
r
king pro
b
lem
s
becom
e sud
denly much easi
e
r. Mobili
ty,
multi homing,
and ba
selin
e end-to
-e
nd
security int
egrate ne
atly into the new
architectu
re.
The
use
of crypto
grap
hic ide
n
tifiers
allo
ws
e
nhan
ce
d a
c
countability, thereby
providi
ng a
ba
se fo
r
easi
e
r buil
d
u
p
of trust. With priva
c
y enhan
cem
e
nts, HIP allows g
ood lo
cation anony
mity,
assuri
ng
stro
ng identity o
n
ly towards
relevant tr
u
s
ted pa
rties. Fi
nally, the HIP proto
c
ol
s h
a
ve
been
ca
refull
y desig
ned t
o
take mi
ddle
boxes i
n
to a
c
cou
n
t, providi
ng for
overl
a
y netwo
rks a
n
d
enterp
r
i
s
e de
ployment co
n
c
erns.
From the
protocol p
o
int
of view, HIP con
s
ist
s
of
a cont
rol p
r
otocol, a nu
mber of
extensio
ns to
the control
proto
c
ol, a
n
d
any nu
mbe
r
of
data prot
ocol
s.
Th
e control proto
c
ol
con
s
i
s
ts of the base-ex
cha
nge, any nu
mber of st
atu
s
upd
ate pa
ckets
(that are
typically use
d
to
convey exten
s
ion
protocol
s), a
nd a th
re
e me
ssage
t
e
rmin
ation h
a
ndsha
ke that
allows the
p
eer
host
s
to clea
nly terminate
a proto
c
ol run
.
From an a
r
ch
itectural p
o
int
of view, the
HIP architect
u
re ha
s be
en
desig
ned to
resto
r
e
the cla
s
sical i
n
ter-networki
ng inva
riant
s, allowi
ng
ho
sts to u
s
e
com
m
unication
e
n
vironm
ent with
IPv4, IPv6, N
A
Ts, and oth
e
r middle b
o
xes. HIP prov
i
des b
u
ilt-in, a
r
chite
c
ted
su
pport for mo
b
ility,
multi-homi
ng
(incl
udin
g
mu
lti-acce
ss), and baseli
ne
secu
rity. It enhances the IP architectu
re by
introdu
cin
g
a
Ho
st Identity (HI) na
me
spa
c
e
rou
ghl
y between th
e IP layer a
nd the tra
n
sport
proto
c
ol
s.
Beside th
e b
a
si
c advanta
ge of integrated mob
ility, multi-homi
ng,
and se
cu
rity supp
ort,
HIP provide
s
for a numb
e
r of potenti
a
l archit
ectu
ral extension
s
. The inhe
rent delegatio
n
cap
ability ca
n be
used to
impleme
n
t sub net
wo
rk l
e
vel mobility
and m
u
lti-ho
ming, a
s
well
as
deleg
able
ap
plicatio
n n
a
m
e
s. T
he
archi
t
ecture
allo
ws
cont
rol traffic to
be
ea
sily se
pa
rated
from
data traffic, providing for en
han
ced p
r
ote
c
tion ag
ain
s
t unwanted traf
fic [12].
1.2. Secure
Socket L
a
y
e
r
Secu
re
so
cket layer (SS
L
) i
s
th
e m
o
st p
opul
ar
proto
c
ol
u
s
e
d
in
the Int
e
rnet
for
facilitating se
cure co
mmu
nicatio
n
s [13]
. Secure
So
ckets Laye
r
(SSL) is a st
anda
rd security
techn
o
logy f
o
r e
s
tabli
s
hi
n
g
an
en
crypt
ed lin
k
b
e
tween
a serve
r
and
a
client
typically a
web
s
e
r
v
er
(
w
e
b
site
)
a
n
d
a br
o
w
s
e
r
;
or
a ma
il
s
e
r
v
er and
a m
a
il
clie
nt.
SSL allows
sensitive
informatio
n such
as
credi
t card num
b
e
rs an
d logi
n cred
entials to be tra
n
smitted se
cu
rely.
Normally, data sent bet
we
en browse
rs
and web serv
ers i
s
in a
plain text and vulnera
b
le
to
eavesdro
ppin
g
. If an attacker is able to interc
ept all the data being
sent
between
a browse
r and
a
web se
rve
r
they ca
n see
a
nd
use
that inform
ation. Mo
re
sp
ecifically, SSL is a securi
ty
proto
c
ol. Pro
t
ocol
s de
scri
be ho
w
algo
rithms
sho
u
ld
be u
s
e
d
; in
this
ca
se, t
he SSL p
r
ot
ocol
determi
ne
s variabl
es of th
e encryption for
both the lin
k and the d
a
ta being tra
n
smitted.
Whe
n
SSL work on a
communi
catio
n
betwe
en client and se
rver, client u
s
e
s
we
b
bro
w
ser to
conne
ct to
a
web
s
ite
se
rv
er th
at is
se
cured
with SS
L. The
n
b
r
o
w
ser
will a
s
k t
o
the
web
se
rver to
identify itself. Server
will send to t
he
browser
a copy
of its
SSL ce
rtificate. On t
he
next step browser will
check whet
her it
trusts the S
S
L certificat
e. If so the
browser
will
send a
messag
e to t
he serve
r
. Th
e se
rver th
en
sen
d
s
ba
ck
a digitally si
g
ned a
c
kno
w
l
edgem
ent to
start
an SSL
en
crypted sessio
n. After that
the secu
re
communi
catio
n
thro
ugh
en
crypted
data
will
begin b
e
twe
e
n
bro
w
ser (cli
ent) and
se
rver.
Evaluation Warning : The document was created with Spire.PDF for Python.
ISSN: 23
02-4
046
TELKOM
NI
KA
Vol. 12, No. 12, Decem
ber 20
14 : 8335 – 83
43
8338
HTTPS sta
n
d
s
for
Hyperte
xt Transfe
r Protocol
ove
r
S
e
cu
re So
cket Layer, or
HT
TP over
SSL. This is t
he secure ve
rsio
n of the
Hyper Te
xt Tra
n
sfer P
r
oto
c
o
l
(HTTP
). Wh
en the web
s
ite
informatio
n t
hat re
ceive
d
or
sent i
s
i
m
portant
we
u
s
e
thi
s
proto
c
ol.
Fo
r exa
m
ple we use
this
proto
c
ol
wh
e
n
we ma
ke
a
payment
or
sent
se
ns
itiv
e pe
rsonal
in
formation. T
h
e information
in
this protocol
will be en
crypted using 128 bit
encr
yption and
cannot be r
ead by any party when
transmitted from our com
puter to our serve
r
s. Th
ere a
r
e two
prima
r
y differences bet
we
en
HTTPS a
nd
HTTP.
HTTP
S con
n
e
c
ts
o
n
po
rt 44
3,
while
HTTP i
s
on p
o
rt 8
0
. HTTPS en
cryp
ts
the data se
nt and re
ceive
d
with SSL, whi
l
e HTTP send
s it all as plai
n text.
Popula
r
servi
c
e
s
su
ch a
s
so
cial m
edia
and
m
a
il services are in
creasi
ngly mig
r
ating to
SSL to impro
v
e se
curity a
nd add
re
ss p
r
ivacy con
c
e
r
ns. As m
o
re t
r
an
sa
ction
s
a
nd services
a
r
e
prote
c
ted
by SSL, DDoS
attacks
on S
S
L se
cu
red
se
rvice
s
are
o
n
the
rise
an
d are ju
stifiably
getting mo
re
attention. So
me of the
s
e
attacks a
r
e
ac
tu
a
lly s
t
an
da
r
d
floo
d
an
d T
C
P
c
o
nn
ectio
n
based attacks that have b
een u
s
ed for years to di
srupt both se
cured a
nd cl
e
a
r text services.
There are al
so attacks targ
eting SSL itself [14].
There a
r
e n
u
m
ero
u
s
kn
own and
potenti
a
l atta
cks
wh
ich expl
oit the SSL han
dshake to
exhau
st serv
er
re
sou
r
ces. The Pu
shd
o
botnet
accomplishes this quit
e ea
si
ly by sen
d
in
g
garb
age d
a
ta
to a target SSL serve
r
. The SSL
pro
t
ocol is com
putationally e
x
pensive an
d
it
gene
rate
s extra wo
rkl
oad
on the se
rver to proc
ess
garb
age d
a
ta
as a legitim
a
te hand
sh
a
k
e.
Fire
wall
s d
o
n
’
t help
in thi
s
ca
se
b
e
cau
s
e the
cli
ents
have
com
p
let
ed the
T
C
P
hand
sh
ake a
n
d
are
sen
d
ing t
r
affic to an al
lowe
d se
rvice [15].Bas
ed
on those fact
SSL as secure p
r
oto
c
ol t
hat
provide crypt
ography
still
cannot resolve DoS a
ttack.
Solution t
hat
presented by Arbor
Network
[14] to solve DoS on SSL still need
to use mu
lt
iple levels te
chni
que that
will use m
o
re
r
e
sour
ces
.
2. Interne
t
Securit
y
Issues
Re
cently the
Internet Se
cu
rity became t
he
ma
in
po
pu
la
r
iss
u
e wor
l
d
w
id
e
.
Many c
a
s
e
s
related to Internet
s
e
c
u
rity oc
curs
every day.
The numbe
r
of cy
ber se
cu
rity
threat
s
in
crea
se
every year [16]. There are many ki
nds of Internet security threats
i.
e. hacktivism, vulnerabilities,
malwa
r
e a
nd
spam. Mo
st o
f
the threats remain un
re
so
lved by curre
n
t Internet technolo
g
ies.
One of the
po
pular Inte
rn
et se
cu
rity thre
ats is
th
e De
nial of Servi
c
es
(DoS
). Do
S can
be
defined a
s
a
n
action th
at prevent the n
e
twork el
eme
n
t from functi
oning in a
c
co
rdan
ce
with its
intende
d purpose. The n
e
twork elem
ent may be
rend
ered pa
rtially or entirely unusa
b
le
for
legitimate u
s
er. Th
e
Deni
al of Se
rvice
s
may
cau
s
e
o
peratio
ns whi
c
h
dep
end
o
n
timeline
s
to
be
delayed. Wh
en there are
a lot of DoS attacke
rs
and thei
r location we
re di
stribute
d
, it coul
d
become Di
stri
buted Denial
of Service
s
(DDoS).
Latest
se
curit
y
incide
nt tre
nd stati
s
tics [
17-1
9
], cu
rre
ntly sho
w
ing
an in
cre
a
se i
n
deni
al
of servi
c
e (DoS) attacks.T
h
is
ki
nd of attack
still has high possi
b
ility to occur in the current
Internet archi
t
ecture
due t
o
lack of accountability.
In the curre
n
t Internet, u
s
er
can fal
s
ify their
identity and t
he pa
cket u
s
i
ng spoofin
g t
e
ch
niqu
e. Th
ere i
s
n
o
a
ccurate
ho
st verification
in th
e
existing TCP/
IP protocol [20]. Mo
reover
the Internet architectu
re has no fundamental ability to
asso
ciate
an
action
with
th
e re
sp
on
sible
entity.
Real
-worl
d
se
cu
rity depe
nd
s o
n
a
c
counta
b
ility
and the
sam
e
applie
s to th
e Internet. Sp
oofing the
so
urce IP add
re
ss
of packet
s
on the inte
rn
e
t
is one of the major tool
s u
s
ed by ha
cke
r
s to laun
ch
DDoS attacks. In such
attacks, the attackers
forge the sou
r
ce IP of packets that are use
d
in
the attack by u
s
ing
an arbitra
r
y IP addre
s
s wh
ich
is sel
e
cte
d
either rand
omly or intention
a
ll
y [21].
Deni
al of Se
rvice atta
cks
overwhelm
a
target
with eit
her to
o ma
ny con
n
e
c
tion
reque
sts
or to
o m
u
ch
band
width.
T
he inte
nde
d
result i
s
to m
a
ke
the
targ
e
t
inacce
ssible
, althoug
h
other
infrast
r
u
c
ture
elements
(routers,
swit
ches, loa
d
bal
ancers, etc.)
may suffer collateral d
a
m
age
along th
e p
a
th of an
attack. A variety
of a
ttack types, in
cludi
ng
con
n
e
c
tion fl
ood
s, TCP S
Y
N
floods, ICMP
and UDP flood
s may b
e
use
d
in
such
a
n
attack [22]. DoS
is a threat that
potentially violates the avail
ability of a resource in
a system [23].
Deni
al of serv
ice attacks come
in a
variety o
f
form
s a
nd
a
i
m at a
vari
ety of
services.
CE
RT
Co
ordinatio
n
Cent
er
define
s
th
ree
basi
c
type
s o
f
attacks: co
n
s
umptio
n of
scarce,
limite
d
,
or no
n-rene
wabl
e
re
so
ur
ce
s,
de
st
ru
ct
i
o
n
or alteration
of configu
r
ati
on inform
atio
n, and
physi
cal de
stru
cti
on or alte
rati
on of netwo
rk
comp
one
nts [22].
The differe
nt types of denial of service attacks can b
e
broadly cla
s
sified int
o
vulnera
b
ility attacks (also calle
d se
man
t
ic attack
s) a
nd floodin
g
a
ttacks (al
s
o
called b
r
ute-fo
rce
Evaluation Warning : The document was created with Spire.PDF for Python.
TELKOM
NIKA
ISSN:
2302-4
046
Perform
a
n
c
e
Com
pari
s
o
n
of Host Identi
t
y Protocol
an
d TCP/IP with Firewall… (A
lfan Presekal)
8339
attac
ks). A
DoS vulnerabili
ty attack expl
oits o
n
e
or m
o
re
flaws i
n
a
poli
c
y o
r
in
t
he m
e
chani
s
m
that enfo
r
ces
the poli
c
y, o
r
a bu
g in
the
software
that i
m
pleme
n
ts th
e target
syste
m
, and
aim
s
t
o
con
s
um
e ex
cessive am
ou
nt of re
so
urces
of the
ta
rget by sendi
ng it a fe
w
carefully craf
ted
requ
est
s
. A DoS brute-fo
rce attack
, on
the other ha
n
d
, aims to de
ny service to legitimate users
of a
servi
c
e
b
y
invokin
g
va
st am
ount of
seemi
ngl
y val
i
d service
req
uest
s
a
nd tryi
ng to
exhau
s
t
a
key re
sou
r
ce
of the target. Currently the Inter
net Security issues
wa
s not
only related
to
techn
o
logy, there
are m
a
ny aspe
ct th
at related
with
t
h
is is
su
e,
su
ch a
s
politi
c
al intention. We
can fo
und th
e numb
e
r
of cyber ha
ckti
v
ism whi
c
h
o
r
gani
z
ta
rget
ed attack to
the governm
ent
web
s
ite a
s
a prote
s
t for go
vernme
nt poli
c
y [3, 25].
3. Rese
arch
Metho
d
In this research to obtain i
n
formatio
n re
gar
di
ng pe
rfo
r
man
c
e of ea
ch teste
d
pro
t
ocol
s
we u
s
e
re
sp
onse time m
easure
m
ent f
o
r eve
r
y test
ed conditio
n
and al
so
g
a
in informati
o
n
regardi
ng service availa
bility. To conduct the test we
use computer with
specificati
on
Processo
rCore i7 2.2 G
H
z, 8
GB RA
M, and u
s
ing
Windo
ws 7
64bit Ope
r
ati
ng System. On
singl
e ma
chi
ne we impl
e
m
ent virtuali
z
ation u
s
ing
V
M
Wa
re
wo
rkstation. Insi
d
e
virtual ma
chine
this scen
ario
use
s
Ubuntu
12.10. All virtual ma
chine
allocated wit
h
simila
r setti
ng 2 GB RA
M.
There are se
veral virtual
machi
n
e
s
in this sce
n
a
r
io: non-HIP clie
n
t, non-HIP se
rver, HIP clie
nt,
HIP serve
r
, and one ma
chin
e will pe
rform DoS attack. The virt
ual machine
in this scena
r
io
con
n
e
c
ted wi
th virtual network to com
m
unicate ea
ch other’
s
. For every test at least we use
two
virtual ma
chi
ne a
s
client
and
as serve
r
. The
r
e
ar
e
three te
st in
our i
m
plem
e
n
tation, first t
e
st
woul
d like to
measure ba
se perfo
rma
n
ce of HIP
and
TCP/IP witho
u
t DoS, se
co
nd we wo
uld l
i
ke
to
me
as
ur
e pe
r
f
o
r
ma
nc
e of T
C
P/IP, SSL
, a
n
d
H
I
P
to
deal with DoS attack
, and
the
third
we
observe servi
c
e availability duri
ng hi
gh i
n
tensity of DoS attack.
Before cond
uct test pe
rf
orma
ce of th
e proto
c
ol
s
on DoS atta
ck
simul
a
tion
, first we
comp
are the
base pe
rformace
for T
C
P/IP and
HIP using
ba
se re
spo
n
se t
i
me. To obt
ain
respons
e
time we
s
e
nd ICMP pac
k
et for both pr
oto
c
ols.
T
h
is
test con
d
u
c
ted on
sa
me co
ndition
of hardware
specification for server
and client. The first test ICMP
will
run over TCP/IP
protocol
and an
othe
r test ICMP will
run ove
r
HIP
proto
c
ol.
Fo
r HIP test bot
h client a
nd
server
are
set
to
impleme
n
t HI
P proto
c
ol
by
usi
ng
Ho
st I
dentity Pr
oto
c
ol
For Lin
u
x (HIPL)
[2
6]. Every
test wi
ll
sen
d
1
00 I
C
MP pa
ckets,
then
we
coll
e
c
t data
ba
se
d on
ave
r
age
re
sp
onse ti
me for eve
r
y 100
ICMP packet
s
. We repe
at measu
r
em
e
n
t of resp
on
se time 20 times to get a
v
erage
re
spo
n
se
time of TCP/IP and HIP.
Secon
d
te
st
woul
d like ev
aluate th
e pe
rforma
ce
of
selecte
d
p
r
oto
c
ol
s T
C
P, S
S
L and
HIP to deal several DoS
attack
scena
rios. In this test we add S
S
L as ne
w p
r
otocol varia
b
le
becau
se rece
ntly SSL kno
w
n a
s
mo
st
popul
ar
se
cu
re p
r
oto
c
ol [2
7]. We comp
are p
e
rfo
r
ma
nce
of the p
r
oto
c
ols b
a
sed
on
re
spo
n
se ti
me on
vario
u
s
DoS atta
ck co
ndition. T
o
gen
erate DoS
attack we u
s
e o
s
tinato tra
ffic gen
erato
r
. Usi
ng
os
tinato we generate variation
of DoS
attack
:
ICMP
flood, TCP sync
flo
od,
an
d UDP flood with
diff
erent
po
rt target. We
u
s
e
Ostinato
be
cause
comp
ared to
anothe
r traffic ge
ne
rator,
Ostin
a
to is
easy to
use
with
commo
n
GUI a
n
d
ha
ve
better performac
e
to generate TCP Sync
[28].
The third sce
nario
s
we
would li
ke to t
e
st
targeted
proto
c
ol
s an
d implem
ent
HIP with
firewall.
Thi
s
HIP firewall
will
be
perform
as acce
ss control firewall.
HIP firewall
will
cl
assify
betwe
en HIP and no
n-HIP packet. The
scen
ario
sho
w
s in Figu
re 2.
Figure 2. HIP Firewall
Evaluation Warning : The document was created with Spire.PDF for Python.
ISSN: 23
02-4
046
TELKOM
NI
KA
Vol. 12, No. 12, Decem
ber 20
14 : 8335 – 83
43
8340
After the fire
wall cl
assify HIP and n
o
n-HIP pack
et, i
n
this sce
n
a
r
i
o
non
-
HIP pa
cket will
be dropped
while HIP packet will be
accept. The next
step the
syst
em will perform authorizatio
n
for u
s
e
r
who
ask fo
r a
c
ce
ss. A
u
thori
z
a
t
ion will
be
condu
ct b
a
se
d on
liste
d
Host Ide
n
tity Tag
(HIT
). The users who
do not have
sam
e
HIT
with
li
sted HIT
will be block,
whil
e the users
who
have HIT on t
he list will be
author
i
z
ed for further access.
To evaluate
performance
of proposed f
i
rewall,
this
proposed HIP
firewall
will be tested
on different DoS attack inte
nsity as well
as o
n
T
C
P/IP and SSL
pro
t
ocol. From t
he DoS test
we
woul
d li
ke to
know the
service av
ail
abili
ty for every
scenarios.
T
o
know service
availability we
run
web server servi
c
e on
the
server side.
T
h
is
server will run
in di
fferent
scenarios and
targeted as
vic
t
im of DoS attac
k
with
va
ri
ation of attack inten
s
ity.
4. Performan
ce Ev
aluation
In this pa
rt
we
wo
uld li
ke to
pre
s
e
n
t re
sult
of co
mpari
s
o
n
p
e
rforman
c
e
of
HIP an
d
TCP/IP as a
basi
c
p
r
oto
c
o
l
. The first ex
perim
ent co
mpares
ba
se
respon
se ti
me between
HIP
and T
C
P/IP by using 10
0 p
i
ng of ICMP p
a
ckets.
Figu
re 3 sho
w
s co
mparation 20
respon
se time
of the HIP an
d TCP/IP during zero
atta
ck
co
nditi
on,
without a
n
y DoS atta
ck.
From th
e gra
phic
comp
ared to
TCP/IP, HIP
has lo
ngg
er resp
on
se
time
. Average re
spo
n
se time on the TCP/I
P
wa
s 98,62
7 ms whil
e the
HIP resp
on
se time was
9
9
,711 ms. A
c
cordi
ng to the first sce
n
a
rio
TCP/IP has
a better resp
onse time co
mpared to
HI
P. This hap
p
ens
becau
s
e
by default the
con
n
e
c
tion e
s
tabli
s
hme
n
t of HIP are m
o
re compl
e
x comp
ared to TCP/IP.
Figure 3. ICM
P
resp
on
se time com
pari
s
on HIP and T
C
P/IP
In the se
con
d
scena
rio
we
woul
d like to
comp
are the
HIP, TCP/IP,
and SSL in a
low to
medium
DoS attack intensity.
The
DoS attack vary betwe
en 0 to one milli
on packet
s
per
second. There are three t
y
pes
of
attack
will be tested: T
C
P Sy
nc flood attack, UDP targeted
Port 10
500
flood
attack, a
nd
UDP
targ
eted Po
rt 1
1
0
flood
atta
ck. T
C
P
sync
flood atta
ck
and
UDP Po
rt 11
0 flood we
re
cho
s
e
n
be
ca
use b
o
th of them are co
m
m
on DoS att
a
ck. While
UD
P
Port 1050
0 was
cho
s
en
be
cau
s
e Po
rt 1
0500 u
s
e
d
by
HIP. Durin
g
the variatio
n o
f
attack o
c
curs
this scenari
o
will measure
the co
nnection time to the
server. To
m
easure
connection time to t
h
e
serve
r
we use httperf appli
c
ation.
From the
se
cond sce
nari
o
in the condit
i
on of
DoS at
tack all p
r
oto
c
ol
s are
still stable
unde
r 1
0
,000
DoS
pa
ckets p
e
r
se
co
nd
. Whe
n
the
n
u
mbe
r
of
attack is mo
re th
an 1
0
,000, th
e
con
n
e
c
tion ti
me in all
prot
ocol
s
were in
cre
a
sed.
Fig
u
r
es 4, 5, 6
sh
ow
s
the com
pari
s
on grap
hic
for ea
ch
of th
e sce
nari
o
. Accordi
ng to
th
e graphi
c the
ord
e
r
of the
perfo
r
man
c
e
from the
be
st to
the worst in the co
ndition
of low to med
i
um DoS atta
ck a
r
e T
C
P/IP, HIP, and the last SSL.
Evaluation Warning : The document was created with Spire.PDF for Python.
TELKOM
NIKA
ISSN:
2302-4
046
Perform
a
n
c
e
Com
pari
s
o
n
of Host Identi
t
y Protocol
an
d TCP/IP with Firewall… (A
lfan Presekal)
8341
Figure 4. Con
nectio
n
time durin
g TCP S
y
nc flood atta
ck
Figure 5. Con
nectio
n
time durin
g UDP targete
d
po
rt 1050
0 flood a
ttack
Figure 6. Con
nectio
n
time durin
g UDP targete
d
po
rt 110 flood atta
ck
Evaluation Warning : The document was created with Spire.PDF for Python.
ISSN: 23
02-4
046
TELKOM
NI
KA
Vol. 12, No. 12, Decem
ber 20
14 : 8335 – 83
43
8342
On the thi
r
d
scen
ario
we
compa
r
e p
e
rfo
r
man
c
e
every
proto
c
ol
s (T
CP/IP, SSL,
and
HIP)
and HIP Fire
wall with a
u
thori
z
ation. All
of the pr
otocols teste
d
re
gardi
ng servi
c
e availa
bility as
web
se
rver o
n
differen
c
e
DoS attack in
tensity (Lo
w
, Medium, an
d
High
). From
the test we g
o
t
following result:
Table 1. Com
pari
s
on
service availability
Protocol
Scenarios
DoS Attack Intensity
Lo
w Medium
High
TCP/IP
SSL
HIP
HIP + HIP Fire
wall + HIT Authori
z
ation
V
V
V
V
V
V
V
V
X
X
X
V
V = Service a
v
ailable (can
acce
ss
web p
age)
X = Service n
o
t available (can
not acce
ss we
b pag
e)
Accordi
ng to the experi
m
ent result, all
of the protocol
still can
provide
servi
c
e in the
con
d
ition lo
w
until mediu
m
DoS atta
ck. B
u
t in the
cond
ition of high
DoS attack, onl
y HIP Fire
wal
l
can
su
rvive. This i
s
hap
pe
n becau
se HI
P Firewa
ll will
block all non
-HIP pa
cket, then am
ong
HIP
packet will be
filtered again
on authori
z
at
ion pro
c
e
s
s.
Authori
z
ation
will allow
regi
stere
d
HIT on
ly
to run over th
e HIP.
5. Conclusio
n
From thi
s
work
we
ca
n
obtain p
e
rfo
r
mance comp
arison of
HIP and T
C
P/IP. In the
norm
a
l con
d
i
t
ion without any DoS attack re
sp
o
n
se time for 100 ICMP pa
ckets of HIP was
99,711 m
s
while TCP/IP 98,627 m
s
. In the low to me
dium DoS attack the orde
r of the proto
c
ol
from the
b
e
st
pe
rform
a
n
c
e
are T
C
P/IP, HIP, an
d S
S
L. Accordin
g to thi
s
i
n
fo
rmation
HIP
has
better pe
rformance in the
conditio
n
lo
w to medi
um
DoS attack
comp
ared wit
h
SSL. On the
con
d
ition of h
i
gh inten
s
ity DoS atta
ck
al
l of the p
r
oto
c
ol T
C
P/IP, SSL, and
HIP can
not work.
To
again
s
t thi
s
kind of
attack,
we
impl
eme
n
t enh
an
cem
ent of
HIP p
r
otocol
u
s
ing
HIP fire
wall
with
HIT auth
o
ri
zation. According to th
e
experim
ent e
nhan
cem
ent
impleme
n
tation of
HIP wa
s
su
ccesfully work to avoid h
i
gh inten
s
ity DoS attack.
From
this exp
e
rime
nt we
can
say th
at th
e
defa
u
lt HIP can
not
ove
r
come DoS
wh
en wo
rk
along
side
with anothe
r types of proto
c
o
l
. This
is because of the exist
ence of another p
a
cke
t
s
besi
de
HIP p
a
cket. HIP
ca
n work to
en
counter
Do
S when
thi
s
proto
c
ol
impl
eme
n
t
the additio
nal
function. Accordin
g to this fact, HIP cannot give
be
st perform
ance in today’s Internet
condit
i
on.
In exis
ting Internet all traf
fic
s
a
re
mixed
with va
riou
s pa
cket type
s. HIP
ca
n
work
be
st if
this
proto
c
ol is im
plemente
d
a stand al
one p
r
otocol on the
Internet.
Referen
ces
[1]
S She
n
kers,
et al. F
o
u
n
d
a
m
ental
Desi
g
n
Issues for
the
Future Internet.
Selected Area in
Comm
unication IEEE Journal
. 1995.
[2]
J Mirkovic et al. Buil
din
g
ac
counta
b
il
it
y
i
n
t
o
the future In
ternet.
4th W
o
rkshop o
n
Sec
u
re Netw
ork
Protocols, NPS
e
c
. 2008.
[3]
Y Oh,
T
Obi. Identif
yin
g
Phishi
ng T
h
reat
in Governm
e
nt W
eb Servic
es.
Internatio
n
a
l Jour
nal
of
Information and Networ
k Security (IJINS)
. 2
013; 23-
42.
[4]
C Marco, et
al. Res
earc
h
Ch
al
l
e
n
ges
T
o
w
a
rd th
e
Future Internet.
Elsevier
Co
mp
uter
a
n
d
Co
mmun
icati
o
n
. 2011.
[5]
Keromy
t
i
s AD, et al
. Implementing IPsec.
IEEE Global Tel
e
communic
a
tio
n
s
Confere
n
ce
. 199
7.
[6]
DG Anderse
n, et al. Accounta
b
le Intern
et Protocol (AIP).
SIGCOMM
. 2008
.
[7]
CE Perkins. Mobile net
w
o
rki
n
g throug
h Mob
i
le IP.
IEEE Inte
rnet Com
p
uting.
1998; 2(
1).
[8]
L Ya
n
y
an
et a
l
. Prosp
e
ct for th
e Future I
n
tern
et A Stud
y
Bas
ed
on T
C
P/IP Vuln
erab
iliti
e
s.
Internatio
na
l
Confer
ence
on
Computi
ng, Measur
e
m
ent, C
ontrol a
nd Se
n
s
or Netw
ork
. 2012.
[9]
R Mosko
w
i
tz et
al. Host Identity Protoc
ol.
IET
F
RF
C 5201
.
ht
tp://tools.ietf.org/htm
l/rfc5201
.
2008.
[10]
R. Mosko
w
i
tz
et al. Prospec
t for the F
u
ture
Internet A
Stud
y
B
a
se
d on T
C
P/IP Vu
lner
abi
lities
.
Internatio
na
l C
onfere
n
ce o
n
Co
mp
uting,
Me
asure
m
ent, Co
ntrol an
d Sens
or Netw
ork
. 2012.
[11]
T
.
Leva et al.
Ad
optio
n Barriers of
N
e
t
w
o
r
k
La
yer
Protoco
l
s: T
he
Case
of
Host Ide
n
ti
t
y
Protocol.
C
o
mp
uter Netw
ork Journ
a
l Elsav
i
er
. 2013.
Evaluation Warning : The document was created with Spire.PDF for Python.
TELKOM
NIKA
ISSN:
2302-4
046
Perform
a
n
c
e
Com
pari
s
o
n
of Host Identi
t
y Protoc
ol an
d TCP/IP with Firewall… (A
lfan Presekal)
8343
[12]
P Nika
n
d
e
r et
al. Host Id
en
tit
y
Protoc
ol (
H
IP):
Conn
ecti
vit
y
, Mo
bil
i
t
y
,
Multi-Hom
i
ng,
Securit
y
,
an
d
Privac
y
over
IPv4 a
n
d
IPv6
Net
w
orks.
IEEE
Co
mmunic
a
tio
n
Surv
eys
and
T
u
toria
l
s. Sec
ond
Quart
e
r
201
0; 12(2): 18
620
2.
[13]
H, Otrok et al. Improving the
Secure Socke
t La
yer Protoc
ol b
y
m
o
d
i
f
y
i
n
g its Authentic
ation functi
on
.
W
o
rld Auto
mat
i
on C
ongr
ess
. 200
6; 1-6.
[14]
J, Le
w
i
s. D
D
o
S Attacks o
n
SSL: Som
e
thing Ol
d, So
methin
g Ne
w
.
DDoS
an
d
Securit
y
R
eport
s
http://
w
w
w
.
ar
b
o
rnet
w
o
rks.co
m/asert/2012/
0
4
/
ddos-
a
ttacks-on-ssl-som
eth
i
ng-
olds
omethi
ng-n
e
w
/.
201
2.
[15]
J Larim
er. Pushdo SSL
DDoS Attacks.
IBM Int
e
rnet Security System
.
http://
w
w
w
.
iss.
net/threats/pus
hdoSS
L
DDoS.
h
tml. 2010.
[16]
S
y
mat
e
c. Internet Securit
y
T
h
reat Rep
o
rt 20
14.
Sym
a
tec Internet Secu
rity Threat Report.
201
4
;
19.
[17]
NSF
O
CUS Ltd. Mid-Ye
ar
DDoS T
h
reat
Rep
o
rt 201
3.
T
e
chnic
a
l
Rep
o
rt 201
3-07
. Be
iji
ng
:
NSF
O
CUSLtd;
2013.
[18]
Prole
x
ic
Ltd. P
r
ole
x
ic Q
uarter
l
y
Gl
ob
al D
D
o
S
Attack Repo
rt.
T
e
chnical R
eport
2
0
1
3
-07
.
Holl
y
w
o
o
d
:
Prole
x
ic Ltd;
2013.
[19]
Rad
w
a
r
e Inc.
Globa
l Ap
plic
a
t
ion a
nd
Net
w
or
k Secur
i
t
y
R
eport. T
e
chnic
a
l R
eport
201
3-01.Ma
h
w
a
h
:
Rad
w
a
r
e Inc.; 201
3.
[20]
NE Heasti
ngs
et al.
T
C
P/IP Spoofin
g F
o
u
ndam
entals.
IE
EE F
i
fteenth Annu
al Intern
a
t
iona
lPho
en
ix
Confer
ence
on
Computers a
n
d
Co
mmu
n
icati
o
n
. 199
6.
[21]
Yunj
i Ma. An
Effective Meth
od for D
e
fens
e ag
ainst IP S
poofi
ng Attack.
6th Internati
o
n
a
lCo
nfere
n
ce
W
i
reless Co
mmu
n
ic
ations N
e
tw
orking an
d
Mobil
e
Co
mput
ing (W
iCOM)
. 201
0.
[22]
M. Abliz. Internet Den
i
al of
Service Attacks and Defe
nse Mech
anis
m
s.
University of
Pittsburg
h
T
e
chnic
a
l Re
p
o
rt
, No.
T
R
-11-178. 20
11.
[23]
H, W
agui
h. A
Data M
i
ni
ng
Appro
a
ch for
the D
e
tectio
n
of Den
i
a
l
of S
e
rvice Attack.
Internatio
na
l
Journal of Artificial Intelligence
. 2013: 9
9
-10
6
.
[24]
CERT
. Denial
of Service Attacks. http://
w
ww.ce
rt.org/historical/tech?tip
s/denial?of?serv
ic
e.cfm.
[25]
M W
a
zid, et a
l
. Hacktivism tre
nds, di
gita
l for
ensic to
ols
an
d
chal
len
ges: A
surve
y
.
IEEE
Co
nferenc
e o
n
Information a
n
d
Co
mmu
n
icati
on T
e
chn
o
l
ogi
es (ICT
).
2013.
[26]
A Pathak et al. Host id
e
n
tit
y
pr
otocol for Li
nu
x.
Linux Jour
na
l.
2009: 1
87(5).
[27]
Kant K et al. A
r
chitectura
l Impact of
Secur
e
Socket La
yer
on Intern
et Ser
v
ers
. IEEE 30
th
Internatio
na
l
Confer
ence
on
Computer D
e
s
i
gn (ICCD)
. 2
0
12; 27-3
4
.
[28]
S Srivastav
a
et al.
Comp
a
r
ative St
u
d
y
of Vari
ous
T
r
affic Gener
ato
r
T
ools.
Recen
t
Advanc
ei
n
Engi
neer
in
g an
d Co
mp
utatio
n
a
l Scie
nces (R
AECS)
. 2014;
1-6.
Evaluation Warning : The document was created with Spire.PDF for Python.