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 attack cond itio n) 98,62 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 sin c e th e   first impl eme n tation of th e Intern et. T he Internet h a 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 the   future  ch allen g e  of the Inte rn et. The o r igi n al  Internet wa 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 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 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 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 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 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 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 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 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 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 the host s ne g o tiate with th e crypto gra p h 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 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 the messages by us ing HI T from initiator. After that, initia tor  will prove its true identity by solvi n 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 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 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 the cla s sical i n ter-networki ng inva riant s, allowi ng  ho sts to u s 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 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 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 b e tween  a serve r  and  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   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 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 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 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 attacks a r e   ac tu a lly s t an da r d  floo d  an d T C 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 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 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 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 of cy ber se cu rity  threat 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 Deni al of Se rvice s  may  cau s e  o peratio ns whi c 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  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 result i s  to m a ke  the  targ e t  inacce ssible , althoug 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 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 re so ur ce s,  de st ru ct i o 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 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 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 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 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 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 of cyber ha ckti v ism whi c 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 we u s 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 ar 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 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 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 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 ha ve   better performac e  to generate TCP Sync  [28].   The third sce nario 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 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 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 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 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 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 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 were in cre a sed.  Fig u r es 4, 5, 6  sh ow 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 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 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 scen ario  we  compa r e p e rfo r man c 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 DoS attack in tensity (Lo w , Medium, an d  High ). From  the test we g o 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 = 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 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 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 experim ent e nhan cem ent  impleme n tation of  HIP wa 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 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 besi de  HIP p a cket. HIP  ca n work to  en counter  Do S when  thi s  proto c ol   impl eme n 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 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 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 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 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 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 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 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 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 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 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.