my seminar project report 2nd

8/18/2019 My Seminar Project Report 2nd

1/25

VISVESHWARAIAH TECHNOLOGICAL UNIVERSITY

BELGAUM

A SEMINAR REPORTon

“IPv4/IPv6 Handoff on Lock-Keeper for High

Flexibility and ec!rity"

Submitted in partial fulllment of the requirement for the degree of

#$%H&L'( I) &)*I)&&(I)*

in

&L&%+(')I% $), %'.)I%$+I') ,&P$(+&)+

by

P.)I+H K.$( % +

[1RN1E!11"#

$1%

() I)+I+.+& 'F +&%H)'L'*0

%hanna1andra2 #angalore 3 6557

,$+&8 9th $(%H 95:6

&;$L.$+&, #08


2/25

IPv4/IPv6 Handoff on Lock-Keeper for High

Flexibility and ec!rity $1%

ABSTRACT

In re1pon1e to the e@erging deploy@ent of IPv6 on net>ork device12 thi1 paper propo1e1 the

integration of IPv6 on Lock-Keeper2 an i@ple@entation of a high level 1ec!rity 1y1te@ for

preventing online attack1 It i1 de1igned to per@it the 1ec!re data exchange over phy1ically

1eparated net>ork1 in an IPv4-ba1ed environ@ent $ ne> interco@@!nication @od!le i1

added to @anage IPv4/IPv6 handoff in1ide the Lock- Keeper2 >hich provide1 1everal

benefit1

Fir1t2 the Lock-Keeper gain1 the flexibility to >ork in IPv4/IPv6 environ@ent1 econd2 an

application layer gate>ay to bridge IPv4 and IPv6 net>ork1 i1 achieved +hird2 the IP-layer

protocol i1olation i1 realiAed in1ide the Lock-Keeper to enhance the 1ec!rity of the protected

net>ork by exchanging data bet>een phy1ically 1eparated net>ork1 !1ing different IP

protocol1.

IPv6 i1 extre@ely pop!lar >ith co@panie12 organiAation1 and Internet 1ervice provider1 ill be !1ed to provide a 1@ooth tran1ition fro@ IPv4 to IPv6 >ith @ini@!@

effect on the net>ork +he1e @echani1@1 are ,!al-tack2 +!nnel and +ran1lation +hi1

re1earch >ill 1hed the light on IPv4 and IPv6 and a11e11 the a!to@atic and @an!al tran1ition

1trategie1 of the IPv6 by co@paring their perfor@ance1 in order to 1ho> ho> the tran1ition

1trategy affect1 net>ork behavio!r

+he @otivation for thi1 @ethod i1 to allo> i1olated IPv6 ho1t12 located on a phy1ical link

>hich ha1 no directly connected IPv6 ro!ter2 to beco@e f!lly f!nctional IPv6 ho1t1 by !1ingan IPv4 do@ain that 1!pport1 IPv4 @!ltica1t a1 their virt!al local link It !1e1 IPv4 @!ltica1t

a1 a Bvirt!al &thernetB

&III SEM '()E [E!E# 'RNSITPage *


3/25



TABLE OF CONTENTS

: I)+(',.%+I')CCCCCCCCCCCCCCCCCCCCC4

:: IP;4 CCCCCCCCCCCCCCCCCCCCCCC

:9 IP;6CCCCCCCCCCCCCCCCCCCCCCCC6

:D L'%K-K&&P&(CCCCCCCCCCCCCCCCCCC7

:4 L'%K-K&&P&( $(%HI+&%H+.(&CCCCCCCCCCC:5

9 +($)I+I') +($+&*I&

9: ,.$L +$%KCCCCCCCCCCCCCCCCCCC::

99 +.))&LI)*CCCCCCCCCCCCCCCCCCCC:9

9D +($)L$+I')CCCCCCCCCCCCCCCCCCC:D

94 P('+'%'L I'L$+I') F'( &%.(I+0CCCCCCC:4D IP;4/IP;6 H$),'FF I)I,& +H& L'%K-K&&P&(CCCCC:

D: IP %')FI*.($+I') ') L'%K-K&&P&(CCCCCCCC:6

4 (&.L+ $), %')%L.I')

4: &EP&(I&)+$L (&.L+CCCCCCCCCCCCCC:7

49 %')%L.I')CCCCCCCCCCCCCCCCCCCC:

(&F&(&)%&CCCCCCCCCCCCCCCCCCCCCC95

&III SEM '()E [E!E# 'RNSITPage * +


4/25



LIST OF FIGURES

:: IP;4 H&$,&(CCCCCCCCCCCCCCCCCCCCCCCCCCCC:9 FI;& %L$& 'F IP;4 $,,(&CCCCCCCCCCCCCCCCCCCC7:D IP;6 H&$,&(CCCCCCCCCCCCCCCCCCCCCCCCCCCCCC

:4 L'%K-K&&P&( %'P')&)+CCCCCCCCCCCCCCCCCCCCC:5: +H& +$+& 'F GI+%H I)+&(;$L

I) +H& I)*L& *$+& L'%K-K&&P&( 0+&CCCCCCCCCCCCCCC::9: ,.$L +$%KCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC:499 +.))&LI)*CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC:9D H&$,&( +($)L$+I')CCCCCCCCCCCCCCCCCCCCCCCCC:

94 P('+'%'L I'L$+I') F'( &%.(I+0CCCCCCCCCCCCCCCCCC:6D: &)$#LI)* IP;4/IP;6 ') $LL )&+G'(K I)+&(F$%& 'F L'%K-K&&P&(CCC:7D9 IP %')FI*.($+I') ') L'%K-K&&P&(CCCCCCCCCCCCCCCCCC:DD IP-#$& &E%H$)*& ',.L& F.)%+I')$LI+0CCCCCCCCCCCCCCC95

4: P&(%&)+$L& I)%(&$& I) +($)F&( +I& F'( ,IFF&(&)+ FIL& I&CCC99

&III SEM '()E [E!E# 'RNSITPage * "


5/25



%H$P+&( :

I)+(',.%+I')

&III SEM '()E [E!E# 'RNSITPage * ,


6/25


7/25



IPv4

+he Internet depend1 on protocol that i1 kno>n a1 Internet Protocol ver1ion 4 hich

!1e1 %la11le11 Interdo@ain (o!ting orld #eca!1e the technology i1 developing2 and @any different 1ervice1

and device1 !1e D* and 4*2 IPv4 i1 approaching it1 li@it there i1 not eno!gh IP1 available

fro@ internet 1ervice provider1


8/25


9/25



-ig 1)+ IP.% header

+he IPv6 provide1 1ol!tion1 for >eakne11 in IPv42 1!ch a1 addre11 exha!1tion8 IPv6nprovide1

addre11e1 >ith :97 bit2 there are no private addre11e12 and the tran1@i11ion of data i1 end to

end IPv4 depend1 on @an!al or dyna@ic ho1t config!ration for addre11ing2 >herea1 IPv6

!1e1 a!to config!ration8 the config!ration i1 done a!to@atically >itho!t the need to 1end a

!ery and >ait for a re1pon1e fro@ the ,H%P 1erver +he 1ec!rity >ith IPv4 i1 optional2 1o

data tran1ferred over the Internet co!ld be hackedM IPv62 ho>ever2 ha1 IP1ec in-b!ilt 1o that

data i1 encrypted

IPSEC

IPec i1 an Internet layer protocol de1igned for providing 1ec!rity at the net>ork layer It i1

!1ed to provide a!thenticity2 integrity and confidentiality bet>een t>o peer1 co@@!nicating

over the net>ork It en1!re1 1afe tran1@i11ion of data acro11 net>orking device1

+he obNective of IPec i1 to provide8

$!thentication 3 It en1!re1 data ha1 been 1ent by an identified 1ender

,ata %onfidentiality 3 It provide1 protection to data by encrypting the infor@ation beingtran1@itted

,ata Integrity 3 pecifie1 that there are no change1 >hile tran1@itting data acro11 the

net>ork1 and packet1 are 1ent to the receiver intact

$void replay attack1 3 +he tran1@itted packet1 do not get altered by any of the attack1

deployed by any attacker

LOCK-KEEPER



10/25



Lock-Keeper i1 a high-level 1ec!rity 1ol!tion ba1ed on the 1i@ple idea of BPhy1ical

eparationB It i1 a hard>are-ba1ed device and >ork1 to provide 1ec!re data exchange

bet>een phy1ically 1eparated net>ork1 #a1ed on the 1i@ple principle that Bthe !lti@ate

@ethod to 1ec!re a net>ork i1 to di1connect itB the Lock-Keeper can entirely prevent 1e11ion-

ba1ed and protocol-ba1ed net>ork attack1 ork fro@ external >orld

In re1pon1e to the e@erging deploy@ent of IPv6 on net>ork device12 in thi1 paper2 IPv6 i1

integrated to the net>ork 1ec!rity device na@ed “Lock-Keeper" +he Lock-Keeper 1y1te@

ha1 been offered a1 a high level 1ec!rity prod!ct to prevent online attack1 again1t an internal

IPv4-ba1ed net>ork It >ork1 a1 1>itch and per@it1 data exchange bet>een t>o phy1ically

1eparated net>ork1 >itho!t e1tabli1hing direct phy1ical connection1

Fig!re :4 Lock-Keeper co@ponent1

Fig 4 1ho>1 the ab1tract principle of Lock-KeeperO1 operation +he Lock-Keeper 1y1te@

con1i1t1 of fo!r co@ponent18 I))&(2 '.+&(2 *$+&2 and a 1>itch @od!le +o 1!pport IPv6

on Lock-Keeper2 a ne> IPv4/IPv6 handoff tran1for@ation @echani1@ i1 i@ple@ented for

@anaging the IPv4/IPv6 interco@@!nication proce11 in1ide the Lock-Keeper

Feat!e" #$ L#%&-&ee'e!

&III SEM '()E [E!E# 'RNSITPage * 1$


11/25



• +he Highe1t Level Protection of the Internal )et>ork

• I@ple@entation of the 1ec!rity principle of BPhy1ical eparationB

• Flexible ,e1ign ba1ed on the 1ec!rity concept of Bec!re it fir1t2

b!ild it laterB

• i@ple and ea@le11 %o@bination >ith other +hird-Party ec!rity ethod1

• $dditional F!nctionalitie1 >ith &nhanced ec!rity8

• Integrated $pplication Proxy/erver for File/&@ail-&xchange

• IPv6 over Lock-Keeper

• ec!re Geb ervice *ate>ay

• trong and Federated $!thentication for '$ &nviron@ent

T(e L#%&-Kee'e! S)"te*

Hard>are $rchitect!re of the ingle *ate Lock-Keeper

Fig : +he 1tate1 of 1>itch interval in the ingle *ate Lock-Keeper y1te@

+he ingle *ate Lock-Keeper 1y1te@2 >hich con1i1t1 of three active ingle #oard %o@p!ter1

ork2 eg2 the Internet +he third Lock-

Keeper #%2 *$+&2 i1 1et !p to perfor@ a detailed analy1i1 of the traffic pa11ing thro!gh $ll

three co@ponent1 are connected to a patented 1>itching !nit that re1trict1 their

co@@!nication

&III SEM '()E [E!E# 'RNSITPage * 11


12/25


Flexibility and ec!rity $1%+he t>o defined 1tate1 of 1>itch 1tate1 ith their re1pectively connected net>ork12 ie internal net>ork and external net>ork2

cannot be connected directly at any ti@e +he 1>itch P%# enable1 and di1able1 connection1

on the phy1ical level2 ie2 interr!pt1 the data tran1@i11ion cable1 +he f!nction and ti@ing of

thi1 !nit i1 a!tono@o!1 and cannot be changed or di1engaged by 1o@eone >ho ha1 acce11 to

the re1t of the 1y1te@ +h!12 neither external attacker1 nor in1ider1 can change or bypa11 the

1tate of the phy1ical 1eparation of the net>ork1



13/25



%H$P+&( 9

+($)I+I') +($+&*I&

&III SEM '()E [E!E# 'RNSITPage * 1+


14/25



TRANSITION STRATEGIES+ran1ition 1trategie1 are @ethod1 that provide a @ean1 of connection bet>een IPv4 and IPv62

a1 the1e t>o protocol1 cannot !nder1tand each other +herefore2 in order to tran1fer data2 a

1pecial @ethod i1 needed

+he three 1trategie1 are:

• ,!al-tack8 +hi1 @ethod i1 !1ed to !nder1tand 1i@!ltaneo!1ly IPv4 and IPv68 regardle11 of

>hich protocol i1 !1ed2 >hen the traffic i1 received the node i1 able to re1pond

• +!nnel8 +hi1 1trategy i1 e@ployed >hen there are t>o net>ork1 that are !1ing the 1a@e IPver1ion b!t are 1eparated by another net>ork that ha1 a different IP +he t!nnel @ethod

e1tabli1he1 a virt!al link thro!gh the net>ork1 by providing a connection in the @iddle of

the@

• +ran1lation8 +hi1 @ethod i1 1i@ilar to )$+2 a1 it change1 the IP packet fro@ IPv4 to IPv6and

vice ver1a2 depending on the 1o!rce and the de1tination

Da+-Sta%&

+he ,!al tack techni!e !1e1 IPv4 and IPv6 >ithin the 1a@e 1tack in parallel +he choice of

protocol i1 decided by the ad@ini1trator policie12 along >ith >hat kind of 1ervice i1 re!ired

and >hich type of net>ork i1 !1ed +hi1 technology doe1 not @ake any change to the packet

header and at the 1a@e ti@e doe1 not @ake encap1!lation bet>een IPv4 and IPv6 +hi1

technology i1 kno>n a1 native d!al 1tack or ,!al IP layer

Fig 9: ,!al tack

&III SEM '()E [E!E# 'RNSITPage * 1"


15/25



+o deter@ine >hich ver1ion to !1e >hen 1ending a packet to a de1tination2 the 1o!rce ho1t

!erie1 the ,) If the ,) ret!rn1 an IPv4 addre112 the 1o!rce ho1t 1end1 an IPv4 packet If

the ,) ret!rn1 an IPv6 addre112 the 1o!rce ho1t 1end1 an IPv6 packet

T,,e+,

+!nneling i1 a 1trategy !1ed >hen t>o co@p!ter1 !1ing IPv6 >ant to co@@!nicate >ith each

other and the packet @!1t pa11 thro!gh a region that !1e1 IPv4 +o pa11 thro!gh thi1 region2

the packet @!1t have an IPv4 addre11 o the IPv6 packet i1 encap1!lated in an IPv4 packet

>hen it enter1 the region2 and it leave1 it1 cap1!le >hen it exit1 the region It 1ee@1 a1 if the

IPv6 packet goe1 thro!gh a t!nnel at one end and e@erge1 at the other end +o @ake it clear that the IPv4 packet i1 carrying an IPv6 packet a1 data2 the protocol val!e i1 1et to 4:

+!nneling i1 1ho>n in Fig!re

Fig 99 +!nneling

Hea/e! T!a,"+at#,

Fig 9D Header +ran1lation

&III SEM '()E [E!E# 'RNSITPage * 1,


16/25


17/25



&III SEM '()E [E!E# 'RNSITPage * 1/


18/25



%H$P+&( D

IP;4/IP;6 H$),'FF I)I,& +H&

L'%K-K&&P&(



19/25



IPV40IPV6 HANDOFF INSIDE THE LOCK-KEEPER

Fig D: &nabling IPv4/IPv6 on all net>ork interface1 of Lock-Keeper

'n each co@ponent of Lock-Keeper2 there i1 a 1eparated net>ork card +he1e three net>ork

card1 are connected by the LK->itch od!le and re1pon1ible for the data tran1@i11ion

in1ide the Lock-Keeper 1y1te@ #e1ide12 on I))&( and '.+&(2 there are t>o additional

net>ork interface12 re1pectively expo1ing 1ervice1 to internal and external !1er1 &achinterface co!ld have IPv42 IPv62 or both o2 there are @any po11ibilitie1 for IP co@bination1

on Lock-Keeper to 1!pport IP protocol i1olation and to achieve the IPv4/IPv6 handoff #y

properly config!ring the Lock- Keeper net>ork interface12 the packet1 co!ld pa11 thro!gh the

Lock-Keeper !1ing different IP protocol1 +he @o1t flexible one i1 to enable both IPv4 and

IPv6 on all interface1 a1 1ho>n in Fig:5 In thi1 ca1e2 the Lock-Keeper >ill gain high

flexibility to >ork in IPv4/IPv6 net>ork1 at both 1ide12 '.+&( and I))&(

IP %#,$!at#," #, L#%&-Kee'e!

+he “E" in the Fig:: @ean1 that the protocol i1 not 1!pported at the corre1ponding net>ork

interface +he @o1t intere1ting config!ration ca1e1 are 1ho>n in %a1e : and %a1e 9 In the1e

ca1e12 the Lock-Keeper can co@@!nicate >ith IPv4 and IPv6 at both 1ide12 I))&( and

'.+&( #e1ide1 achieving high flexibility2 a virt!al barrier i1 created on the *$+& o2

@e11age1 >ill be carried thro!gh the Lock-Keeper part1 !1ing t>o different IP protocol1



20/25


21/25


Flexibility and ec!rity $1%@od!le 1elect1 the proper IP protocol to carry data For exa@ple2 if the data received by IPv6

at the '.+&(2

IP-#E @od!le can decide to !1e IPv4 for *$+& I))&( co@@!nication In thi1 >ay2 the

net>ork protocol 1eparation i1 achieved to enhance 1ec!rity by exchanging data bet>een

phy1ically 1eparated net>ork1 !1ing different IP protocol1

Fig!re DD IP-#a1e eEchange @od!le f!nctionality

IP protocol i1olation 1ec!rity i1 a po>erf!l 1ol!tion in @ixed IPv4/IPv6 net>ork1 #eca!1e

IPv4 fire>all1 cannot be deployed for IPv62 both IPv4-ba1ed and IPv6-ba1ed fire>all1 are

needed to be config!red and @anaged caref!lly 'ther>i1e2 the internal net>ork1 can be

v!lnerable to 1o@e attack d!e to IPv6 protocol @i1!1ed &ven in ca1e of enabling IPv4 and

IPv6 on all of the Lock-Keeper interface12 the IP protocol i1olation i1 1till po11ible if the IP-

#E >ork1 according to the algorith@ >hich i1 1ho>n in Fig!re :9



22/25



%H$P+&( 4

(&.L+ $),

%')%L.I')



23/25



E1PERIMENTAL RESULT

&ven tho!gh IPv6 data header length i1 t>ice a1 that of the IPv4 header i@plying that IPv6ha1 a higher overhead than IPv42 the ti@e delay thro!gh the Lock-Keeper i1 al@o1t identical

in both ca1e12 ie2 >ith original IPv4-only and >ith integrating IPv6 #y experi@ent2 >e

fo!nd that the Lockkeeper ha1 abo!t 557 increa1e1 in the tran1fer ti@e than >ith IPv4-

only >hen an external !1er !1e1 IPv6 to get :*# file for@ IPv6-internal 1erver IPv4

o!tperfor@1 IPv6 by only abo!t 555: for tran1ferring :5K# file For 1@aller file 1iAe12 the

tran1fer ti@e1 are ro!ghly e!al Fig 7 1ho>1 the percentage increa1e in tran1fer ti@e thro!gh

the ,!al *ate Lock-Keeper by integrating IPv6 co@paring to the original IPv4-only Lock-

Keeper >hen tran1ferring different file 1iAe1

Fig 4)1 Per2entale in2rea3e in tran3fer time for di4erent le 3i5e3 due to integrating IP.% on 6o2789eeper 2omparing to the original 6o278

9eeper

+he above re1!lt1 have been po11ible 1ince IPv6 header 1tr!ct!re i1 de1igned to get a

1i@plified 1tandard for@at >hich can be proce11ed fa1ter than IPv4 header1 oreover2 the

1>itching @echani1@2 !e!ing delay2 and 1canning ti@e in1ide the Lock-Keeper fro@ the

1ignificant portion of the total tran1fer ti@e rather than the proce11ing ti@e

&III SEM '()E [E!E# 'RNSITPage * +


24/25



CONCLUSION

• IPv6 i1 a viable 1ol!tion to IPv4 addre11ing 1pace depletion proble@ $ccordingly2 IPv6 i1

being integrated into @ore and @ore ne> prod!ct1 Ho>ever2 the @igration to IPv6 @ay

take @any year1 and ne> prod!ct1 1ho!ld be able to co@@!nicate >ith both IPv4 and

IPv6 d!ring the coexi1tence period

• Increa1ing the !1ability of the Lock-Keeper to >ork >ith both IPv4 and IPv6

• &nhancing the 1ec!rity of the Lock-Keeper protected net>ork by integrating an IPv4/IPv6

protocol handoff @echani1@

• Providing a phy1ical 1eparation ba1ed IPv4/IPv6 i1olation approach

>e integrate IPv6 on the Lock-Keeper to extend it to >ork in both IP4/IPv6 environ@ent1 in

a 1ec!re >ay $n IPv4/IPv6 i1olation @echani1@ ba1ed on the protocol 1eparation i1 !1ed to

per@it the 1ec!re data exchange over phy1ically 1eparated net>ork1

&III SEM '()E [E!E# 'RNSITPage * "


25/25



REFERENCES

Q:R F %heng2 P Ferring2 % einel2 * S llenhei@2 and ? #ern2 “+he ,!al*ate Lock-

Keeper8 $ Highly &fficient2 Flexible and $pplicable )et>ork ec!rity ol!tion2" in

Proceeding1 of the 4th $%I International %onference on oft>are &ngineering2 $rtificial

Intelligence2 )et>orking2 and Parallel/,i1trib!ted %o@p!ting

my seminar project report 2nd

Documents