`Munger et al.
`
`(10) Patent N0.:
`(45) Date of Patent:
`
`US 6,502,135 B1
`Dec. 31, 2002
`
`US006502135B1
`
`(75)
`
`(54) AGILE NETWORK PROTOCOL FOR
`SECURE COMMUNICATIONS WITH
`ASSURED SYSTEM AVAILABILITY
`Inventors: Edmund Colby Munger, Crownsville,
`MD (US); Douglas Charles Schmidt,
`Severna Park, MD (US); Robert
`Dunham Sh0I‘t,
`Leesburg,
`(US); Victor Larson, Fairfax, VA (US);
`Michael Williamson, South Riding, VA
`(US)
`
`DE
`E1’
`E1;
`
`W0
`W0
`W0
`wo
`
`199 24 575
`2 317 792
`3
`33/
`W0 99 38081
`W0 99 48303
`WO 00/70458
`W0 01 50533
`
`12/1999
`4/1998
`
`7/1999
`9/1999
`11/2000
`7/2001
`
`OTHER PUBLICATIONS
`
`(73) Assignee: Science Applications International
`Corporation, San Diego, CA (US)
`
`( * ) Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 0 days.
`
`Fasbender, Kesdogan, and Kubitz: “Variable and Scalable
`Security: Protection of Location Information in Mobile IP”,
`IEEE publication, 1996, pp. 963-967.
`
`(List continued on next page.)
`
`(21) Appl. No.: 09/504,783
`
`(22) Filed:
`
`Feb. 15, 2000
`
`Related U.S. Application Data
`
`(63)
`
`(60)
`
`Continuation—in—part of application No. 09/429,643, filed on
`Oct. 29, 1999
`Provisional application No. 60/106,261, filed on Oct. 30,
`1998, and provisional application No. 60/137,704, filed on
`Jun. 7, 1999.
`
`Int. Cl.7 ............................................ .. G06F 15/173
`(51)
`
`(52) U.S. Cl.
`............ ..
`709/225; 709/229; 709/245
`(58) Field of Search ............................... .. 709/249, 223,
`709/225, 229, 245; 713/201
`
`(56)
`
`References Cited
`U.S. PATENT DOCUMENTS
`
`4,933,846 A
`
`6/1990 Humphrey et al.
`
`(List continued on next page.)
`FOREIGN PATENT DOCUMENTS
`
`DE
`
`0 838 930
`
`12/1999
`
`Primary Examiner—Krisna Lim
`(74) Attorney, Agent, or Firm—Banner & Witcoff, Ltd.
`
`(57)
`
`ABSTRACT
`
`A plurality of computer nodes communicate using seem-
`ingly random Internet Protocol source and destination
`addresses. Data packets matching criteria defined by a
`moving window of valid addresses are accepted for further
`processing, while those that do not meet the criteria are
`quickly rejected. Improvements to the basic design include
`(1) a load balancer that distributes packets across different
`transmission paths according to transmission path quality;
`(2) a DNS proxy server that transparently creates a virtual
`private network in response to a domain name inquiry; (3)
`a large-to-small link bandwidth management feature that
`prevents denial-of-service attacks at system chokepoints; (4)
`a traffic limiter that regulates incoming packets by limiting
`the rate at which a transmitter can be synchronized with a
`receiver; and (5) a signaling synchronizer that allows a large
`number of nodes to communicate with a central node by
`partitioning the communication function between two sepa-
`rate entities.
`
`17 Claims, 35 Drawing Sheets
`
`F100
`TARP
`TERMINAL
`
`
`
`SESS1ON KEY
`
`\/ TERMINAL
`
`140 J \
`
`TARP
`
`MICROSOFT 1001
`
`1
`
`MICROSOFT 1001
`
`
`
`US 6,502,135 B1
`Page 2
`
`U.S. PATENT DOCUMENTS
`
`......... .. 709/225
`
`.............. .. 709/243
`
`12/1996 Aziz
`5,588,060 A
`11/1997 Nguyen
`5,689,566 A
`8/1998 Esbensen
`5,796,942 A
`9/1998 Holloway et al.
`5,805,801 A
`11/1998 Hughes et al.
`5,842,040 A
`3/1999 Baehr et al.
`5,878,231 A *
`4/1999 Klaus
`5,892,903 A
`4/1999 Wesinger et al.
`5,898,830 A *
`5/1999 Holloway et al.
`5,905,859 A
`12/1999 Adelman et al.
`6,006,259 A
`1/2000 Tomoike ................... .. 370/338
`6,016,318 A *
`4/2000 Wesinger, Jr. et al.
`6,052,788 A
`6/2000 Liu .......................... .. 713/201
`6,079,020 A *
`9/2000 Alkhatib
`6,119,171 A
`........ .. 713/168
`1/2001 Schneider et al.
`6,178,505 B1 *
`5/2001 Arrow et al.
`............. .. 370/351
`6,226,751 B1 *
`6/2001 Sitaraman et al.
`6,243,749 B1
`9/2001 Ramanathan et al.
`..... .. 345/733
`6,286,047 B1 *
`. . . . . . . . .
`. . . .. 707/10
`6,330,562 B1 * 12/2001 Boden et al.
`
`6,332,158 B1 * 12/2001 Risley et al.
`709/219
`............ .. 370/389
`6,353,614 B1 *
`3/2002 Borella et al.
`OTHER PUBLICATIONS
`
`Linux FreeS/WAN Index File, printed from http://liberty-
`.freeswan.org/freeswanitrees/freeswan-1.3/doc/ on Feb.
`21, 2002, 3 pages.
`J. Gilmore, “Swan: Securing the Internet against Wiretap-
`ping”, printed from http://liberty.freeswan.org/freeswan_
`trees/freesswan-1.3/doc/rationale.html on Feb. 21, 2002, 4
`pages.
`Glossary for the Linux FreeS/WAN project, printed from
`http://liberty.freeswan/org/freeswanitrees/freeswan-1.3/
`doc/glossary.html on Feb. 21, 2002, 25 pages.
`
`Alar1 O. Frier et al., “The SSL Protocol Version 3.0”, Nov.
`18, 1996, printed from http://www.netscape.com/eng/ss13/
`draft302.txt on Feb. 4, 2002, 56 pages.
`Reiter, Michael K. and Rubin, Aviel D. (AT&T Labs—
`Research), “Crowds: Anonymity for Web Transactions”, pp.
`1-23.
`
`Dolev, Shlomi and Ostrovsky, Rafail, “Efficient Anonymous
`Multicast and Reception” (Extended Abstract), 16 pages.
`Rubin, Aviel D., Geer, Daniel, and Ranum, Marcus J. (Wiley
`Computer Publishing), “Web Security Sourcebook”, pp.
`82-94.
`
`Shree Murthy et al., “Congestion-Oriented Shortest Multi-
`path Routing”, Proceedings of IEEE INFOCOM, 1996, pp.
`1028-1036.
`Jim Jones et al., “Distributed Denial of Service Attacks:
`Defenses”, Global Integrity Corporation, 2000, pp. 1-14.
`Search Report (dated Jun. 18, 2002), International Applica-
`tion No. PCT/US01/13260.
`Search Report (dated Jun. 28, 2002), International Applica-
`tion No. PCT/US01/13261.
`Donald E. Eastlake, “Domain Name System Security Exten-
`sions”, DNS Security Working Group, Apr. 1998, 51 pages.
`D. B. Chapman et al., “Building Internet Firewalls”, Nov.
`1995, pp. 278-297 and pp. 351-375.
`P. Srisuresh et al., “DNS extensions to Network Address
`Translators”, Jul. 1998, 27 pages.
`Laurie Wells, “Security Icon”, Oct. 19, 1998, 1 page.
`W. Stallings, “Cryptography And Network Security”, 2”“
`Edition, Chapter 13, IP Security, Jun. 8, 1998, pp. 399-400.
`W. Stallings, “New Cryptography and Network Security
`Book”, Jun. 8, 1998, 3 pages.
`
`* cited by examiner
`
`2
`
`
`
`U.S. Patent
`
`Dec. 31, 2002
`
`Sheet 1 0135
`
`US 6,502,135 B1
`
`
`
`IP
`ROUTER
`
`29
`
`IP
`ROUTER
`
`IP
`ROUTER
`I 25
`INTERNET
`"3
`ROUTER
`
`‘I’
`
`28
`
`‘P
`ROUTER
`
`IP
`ROUTER
`32
`
`H,
`ROUTER
`
`26
`
`IP
`ROUTER
`
`110
`
`DESTINATION
`
`TERMINAL
`
`ENCRYPTION KEY
`
`T
`
`FIG. 1
`
`3
`
`
`
`U.S. Patent
`
`Dec. 31, 2002
`
`Sheet 2 0135
`
`US 6,502,135 B1
`
`
`
`
`12
`
`TARP
`
`ROUTER
`
`129
`
`IP
`ROUTER
`
`R
`
`SESSION KEY
`
`\
`
`FIG. 2
`
`4
`
`
`
`U.S. Patent
`
`Dec. 31, 2002
`
`Sheet 3 0135
`
`US 6,502,135 B1
`
`207a
`
`207b
`
`2070
`
`207d
`
`° ° °
`
`
`
`DATA STREAM §@
`
`
`
`INTERLEAVED
`PAYLOAD DATA
`
`E
`
`
`
`
`
`SESSION-KEY-ENCRYPTED
`PAYLOAD DATA§§Q
`
`TARP PACKET WIT
`ENCRYPTED PAYLOAD __
`
`LINK-KEY-ENCRY
`
`TARP PACKETS _
`
`'
`
`1-
`
`IP PACKETS w/ ENCRYPTED
`TARP PACKETS AS
`PAYLOAD @
`
`
`
`
`TARP
`
`ROUTER 2
`
`TARP
`ROUTER 1
`
`
`
`
`
`TARP
`ROUTER 3
`
`TARP
`ROUTER 5
`
`TARP
`ROUTER 7
`
`TARP
`ROUTER 4
`
`TARP
`ROUTER 6
`
`
`
`TARP
`DESTINATION
`
`FIG. 3A
`
`5
`
`
`
`U
`
`tn
`
`Dec. 31, 2002
`
`Sheet 4 of 35
`
`US 6,502,135 B1
`
`
`
`
`
`m§m><.u:~Ez_mo<o._><n_o._.z_
`
`
`
`En__>avagmazzozm
`
`
`
`
`
`mmm$><§Ez_8<o:Eo._.z_
`
`
`
`_.E>>mEo<n_has
`
`
`
`%2_<o§_ecnfiazm
`
`<._.<omo95%§_s_8Ev_.zo_m$ga:>%zm.va3m......
`
`
`
`
`
`
`802mm><s_Emozmaomw93%;.......
`
`
`
`
`omE_>_mVacsa§5zm_
`
`
`
`89%V50;8:305
`
`MN|m8<o§._8;
`
`pmas25%E5ll,‘&...22:8£8as
`
`w...IIIIIENEIE
`
`6
`
`
`
`
`
`
`U.S. Patent
`
`Dec. 31, 2002
`
`Sheet 5 of 35
`
`US 6,502,135 B1
`
`aoeofiV2:Ea
`
`§$&s.._>>
`
`v.Q_...._
`
`m_z_m_>_8Em_>:.<zmm_._.._<mzo
`
`w_,__mm_8Ehas
`
`mommooya
`
`n__Q0_.:._2,
`
`a§>_§z§:%
`
`%;m><:1_:_§Ez
`
`§_oE
`
`ezamaog
`
`mg;M2282m_>_zz$:<$15
`
`928Ez_72$.3mommmoog.31::
`
`7
`
`
`
`
`U.S. Patent
`
`Dec. 31, 2002
`
`Sheet 6 0135
`
`US 6,502,135 B1
`
`BACKGROUND LOOP-DECOY
`GENERATION
`
`S0
`
`EITHENTICATETARP PACKET
`
`S2
`
`S3
`
`S4
`
`88
`
`510
`
`311
`
`
`
`TRANSMIT DECOY?
`
`YES
`
`DECREMENT
`
`YES
`
`NO
`
`
`
`GENERATE NEXT-HOP TARP
`ADDRESS AND STORE LINK KEY
`AND IP ADDRESS
`
`
`
`GENERATE NEXT-HOP TARP
`ADDRESS AND STORE LINK KEY
`AND IP ADDRESS
`
`
`
`DETERMINE DESTINATION TARP
`ADDRESS AND STORE LINK KEY
`AND IP ADDRESS
`
`
`
`GENERATE IP HEADER
`AND TRANSMIT
`
`FIG. 5
`
`35
`
`DUMP DECOY
`
`OUTER LAYER DECRYPTION OF
`TARP PACKET USING LINK KEY
`
`CHECK FOR DECOY AND
`
`INCREMENT PERISHABLE DECOY
`COUNTER AS APPROPRIATE
`
`8
`
`
`
`U.S. Patent
`
`Dec. 31, 2002
`
`Sheet 7 0135
`
`US 6,502,135 B1
`
`BACKGROUND LOOP-DECOY
`GENERATION
`
`GROUP RECEIVED IP PACKETS
`INTO INTERLEAVE WINDOW
`
`LJUILILJ
`
`DETERMINE DESTINATION TARP
`ADDRESS, INITIALIZE TTIL, STORE
`IN TARP HEADER
`
`RECORD WINDOW SEQ. NOS. AND
`INTERLEAVE SEQ. NOS IN TARP
`HEADERS
`
`320
`
`521
`
`S22
`
`323
`
`S24
`
`
`
`CHOOSE FIRST HOP TARP
`ROUTER, LOOK UP IP ADDRESS
`AND STORE IN CLEAR IP HEADER,
`OUTER LAYER ENCRYPT
`
`INSTALL CLEAR IP HEADER
`AND TRANSMIT
`
`325
`
`FIG. 6
`
`9
`
`
`
`U.S. Patent
`
`Dec. 31, 2002
`
`Sheet 8 0135
`
`US 6,502,135 B1
`
`DIVIDE BLOCK INTo PACKETS
`
`
`
`
`USING WINDOW SEQUENCE DATA,
`ADD CLEAR IP HEADERS
`GENERAIED FROM TARP
`HEADERS
`
`
`
`
`
`[HA~$gIg,II:IgT,Eg>,ggggg;<EIS
`
`S40
`
`BACKGROUND LOOP-DECOY
`
`GENERATION
`
`S42
`
`AUTHENTICATE TARP PACKET
`
`RECEIVED
`
`s43
`
`DECRYPT OUTER LAYER
`ENCRYPTION WITH LINK KEY
`
`INCREMENTPERISHABLE
`
`COUNTER IF DECOY
`
`S44
`
`S45
`
`THROW AWAY DECOY OR KEEP
`IN RESPONSE TO ALGORITHM
`
`S46
`
`CACHE TARP PACKETS UNTIL
`
`WINDOW IS ASSEMBLED
`
`S47
`
`S48
`
`DEINTERLEAVE PACKETS
`FORMING WINDOW
`
`DECRYPT BLOCK
`
`FIG. 7
`
`10
`
`10
`
`
`
`U.S. Patent
`
`Dec. 31, 2002
`
`Sheet 9 of 35
`
`US 6,502,135 B1
`
`n_m<._.
`
`E$52
`
`Mmm.Ev_o<n_5<EaQE05z>mm
`
`@555vs,‘V?7:3
`
`
`
` mudV2zo:.<_._._z_zoammwsommQzo:<:_z_
`zoaammmsam
`
`w_o_u_
`
`
`
`._<z__>_mm:.._.zm__._o
`
`a
`
`E
`
`11
`
`
`
`U.S. Patent
`
`Dec. 31, 2002
`
`Sheet 10 0135
`
`US 6,502,135 B1
`
`
`
`¢»¢o~w_Ném___@<vo~m_Ném_
`
`E.§.E.§_§§:.§
`
`
`
`NNe¢o~w_Nem,._o~vo~m_Ném_
`
`
`
`m«Vo~w_Ném_¢_<vo~m_Nem_
`
`m.o_.._
`
`
`
`
`
` 2_g§N_§_m:_3N.S~.EE_§_2N..2_§_§.§_§N_N_3N.£N.:2_8_3~.mE_E%.gN.M:N.F2_§_3N.SN.E
`
`mas
`
`ammpaom
`
`
`
`
`
`am_._.zm__._o
`
`m>_§m
`
`£§.§.§_$§.E.§Qwas
`
`
`
`Nq¢o~w,Ném_._N~voN¢.~ém_
`
`
`
`©m<vo~w_Nem_.mm:voN¢_Nem_
`
`
`
`mw¢o~w_Ném_.~wvo~w_Ném,
`
` _NN_3N.wE.E§oN.§_SF.3.32%.3;Qm_._m<._. fiomew.§.N:VoN_£N_E$32.2“.E_m2_§.§.Ea_g§N_SF.
`._.__>_mz<m._.
`
`
`
`
`
`mwE$CS%§H
`
`
`
`«NWwasm>Ew_
`
`12
`
`12
`
`
`
`
`U.S. Patent
`
`Dec. 31, 2002
`
`Sheet 11 of 35
`
`US 6,502,135 B1
`
`:9
`
`N2:
`
`22
`
`:9
`
`“ES
`
`$59.
`
`“asm%_
`
`$52
`
`maso%_
`
`E53
`
`58
`
`mm?
`
`88
`
`S.©_u_
`
`ES
`
`‘V,8,
`
`13
`
`13
`
`
`
`
`
`
`U.S. Patent
`
`Dec. 31, 2002
`
`Sheet 12 0135
`
`US 6,502,135 B1
`
`3:mmnmm§<2:.9;<3:ms:3”m$%o<3:am
` mva<n_m_2”m$%n_<>>_._55mg:31m$%n_<>>_._5%
`
`
`
`
`Eemx1|§:$5:
`
`mzétmzmmxmmzétmzmwxm
`
`V8:V8:
`
`<8:ms:
`
`mg:Os:
`
`E3:<3:
`_>__5maE1m$%o<n=.53E“mafia.n=$58
`RNew:
`
`3SE5285S”m$%o<n__5%Ew$%oE_M258
`
`03:
`
`ga<oSa2:;5<3E
`
`14
`
`S.o_”_
`
`IIIY
`
`NE
`
`a23%.
`
`
`08:2am:_>__6_w_o
`mg:2.m$%9:_5%E<2:2.mmw_oQ<n__M958
`
`14
`
`
`
`
`
`
`
`
`U.S. Patent
`
`Dec. 31, 2002
`
`Sheet 13 0135
`
`US 6,502,135 B1
`
`32
`
`as
`
`<3.o_u_
`
`
`
`o3:01;:oo._<n_o_._>>_._mo._<..._o_._n__<o._<%E_
`
`xx:X22xgsX22
`
`15
`
`zo:<o_E<
`
`15
`
`
`
`U.S. Patent
`
`Dec. 31, 2002
`
`Sheet 14 0135
`
`US 6,502,135 B1
`
`BEm_o._.<z_s__mom_o
`
`$3,;
`
`82%mm26
`
`025z_
`
`82%mm25
`
`02%z_
`
`82%mmz<o
`
`02%z_
`
`m_wm#_8<n__
`
`82>mm25
`
`025z_
`
`82>mmz<o
`
`02$z_
`
`83>ms25
`
`02$z_
`
`ms.O_n_
`
`8:;ma25
`
`ozéz_
`
`
`
`m2<>>E<I.m
`
`2&0:
`
`$82._._<mam_s_<w
`
`Em:_>_8mo
`
`s_8z$_
`
`2%_._o<mmeax:
`
`302
`
`mo
`
`:ms_a8_>m
`
`m88m__>_oE
`
`._
`
`16
`
`16
`
`
`
`U.S. Patent
`
`Dec. 31, 2002
`
`Sheet 15 of 35
`
`US 6,502,135 B1
`
`mhzmzo
`
`Hm¥o<m
`
`mmmoommmm>
`
`.o4<ezm
`
`o_m_
`
`Hm>momo
`
`Fmxu<m
`
`2.o_u_
`
`
`
`2058m:<>_E
`
`V
`
`was,025
`
`
`
`;_o_Eon_Osman:
`
`mas,02$
`
`17
`
`17
`
`
`
`
`
`U.S. Patent
`
`Dec. 31, 2002
`
`Sheet 16 of 35
`
`U
`
`B
`
`1
`
`B.53OE
`
`
`
`m+I.lI|I|.v$N_zo$_oz>mfigzma9:ma_8mme025z_Em:MA......................--vEN_zo$az>$zm_%mmEEozmmmom02$z_.Em§
`
`
`
`
`
`
`
`
`
`%_m_:,m_n__8mn_m_mfiozmm
`
`$E_>_wz<E
`
`18
`
`18
`
`
`
`U.S. Patent
`
`Dec. 31, 2002
`
`Sheet 17 0135
`
`US 6,502,135 B1
`
`$2222$2022222222
`
`
`
`
`
`u$2222o.2_282__.E>>
`
`
`
`2,82-0222@2o:§2o22o22m2222@
`
`
`
`
`
`22m2$E2V2222,»:225%
`
`
`
`.222_E2a2o2mE2m2<E
`
`
`
`se§::22:2a_8_2ma
`
`E2o2_m28202$
`
`E2mE»m2.me.20202%2222222m>mo#_2_22222
`
`2_<2n,_>nm____,_2M_2%m%_Wmo._22222_o228_._o
`
`
`222222252820o2__282_.E_2,m_>_22<
`
`>>ooz_>>m:<onS.22$20,2322m>_m_.82E2
`
`
`
`
`M21520m_m_m>_m_om_m_mE»m2m_e22,222%m_<n_
`
`
`
`EE2m2<E2__2222222H$2222
`20202222225.E2m:<2m_2m_w
`
`
`22_o&82o522.922»..222_o2282o
`_22222222mE2w2<E2_22%
`
`19
`
`m2.0_.._
`
`19
`
`
`
`U.S. Patent
`
`Dec. 31, 2002
`
`Sheet 18 0135
`
`US 6,502,135 B1
`
`f
`
`FIG.16
`
`-—T—:—-—-1:1}
`
`‘.._.
`
` >
`
`E
`
`L‘?
`O?
`'
`
`3<
`
`4095
`
`$
`
`I13
`C7
`V’
`
`3‘
`
`CD
`
`I!)
`C)
`‘
`
`1V
`
`3
`
`20
`
`20
`
`
`
`
`
`(ETHERNETLAN-TWOAADDRESSBLOCKS)
`
`20
`
`
`
`U.S. Patent
`
`Dec. 31, 2002
`
`Sheet 19 0135
`
`US 6,502,135 B1
`
`000
`
`W|NDOW_S|ZE
`
`
`
`
`
`
`I INACTIVE
`ACTIVE
`
`5;, USED
`
`
`,/////////////////////M
`
`,///////////////////////A
`
`
`
`
`
`
`
`
`
`W'”°°W-S'ZE 7//////////////////////A
`7//////////////////////A
`
`
`7//////////////////////A
`7/////////////////////Z
`
`FIG. 17
`
`21
`
`
`
`U.S. Patent
`
`Dec. 31, 2002
`
`Sheet 20 of 35
`
`US 6,502,135 B1
`
`| INACTIVE
`ACTIVE
`
`flfl& USED
`
`—_
`
`000
`
`
`_'////////////////I/////.
`,'////////////////I/////.
`
`
`
`WlNDOW_S|ZE
`
`WlNDOW_S|ZE
`
`7////////////I//I////I
`
`FIG. 18
`
`22
`
`22
`
`
`
`U.S. Patent
`
`Dec. 31, 2002
`
`Sheet 21 0135
`
`US 6,502,135 B1
`
`V//////////////////////A
`
`
`
`7//////////////////////A
`2'///////////////////////.
`,7////////////////////M
`,7//////////////////////.
`7//////////////////I///A
`
`
`
`
`
`
`
`
`FIG. 19
`
`23
`
`O00
`
`W|NDOW_S|ZE
`
`WlNDOW_S|ZE
`
`
`
`O00
`
`
`
` V//////////////////////A
`
`7///////////////////////.
`7///////////////////////.
`
`
`
`23
`
`
`
`U.S. Patent
`
`Dec. 31, 2002
`
`Sheet 22 0135
`
`US 6,502,135 B1
`
`2011
`
`FIG.20
`
`
`
`COMPUTER #2
`
`2002
`
`
`
`
`
`COMPUTER #1
`
`2001
`
`2008
`
`2005
`
`24
`
`24
`
`
`
`U.S. Patent
`
`Dec. 31, 2002
`
`Sheet 23 of 35
`
`US 6,502,135 B1
`
`2101
`
`2102
`
`2103
`
`2104
`
`2105
`
`2106
`
`2107
`
`2108
`
`2109
`
`AD TABLE
`
`IP1
`
`{P3
`
`IP2
`
`IP4
`
`AE TABLE
`
`AF TABLE
`
`BD TABLE
`
`BE TABLE
`
`BF TABLE
`
`IIIIIIIIKIIIIIII
`
`CD TABLE
`
`CE TABLE
`
`CF TABLE
`
`FIG. 21
`
`25
`
`LINK DOWN
`
`2100 /{
`
`25
`
`
`
`U.S. Patent
`
`Dec. 31, 2002
`
`Sheet 24 0135
`
`US 6,502,135 B1
`
`
`
`MEASURE
`QUALITY OF
`TRANSMISSION
`PATH X
`
`MORE
`
`
`
`
`
`THAN ONE
`TRANSMITTER
`TURNED
`
`ON?
`
`TO MIN. VALUE
`
`2209
`
`SET WEIGHT
`
`
`
`DECREASE
`WEIGHT FOR
`PATH X
`
`PATH X
`
`
`
`WEIGHT LESS
`THAN STEADY
`STATE
`VALUE?
`
`
`
`FOR PATH X
`TOWARD STEADY
`
` INCREASE WEIGHT
`STATE VALUE
`
` ADJUST WEIGHTS
`
`
`FOR REMAINING
`PATHS SO THAT
`
`WEIGHTS EQUAL ONE
`
` FIG. 22A
`
`26
`
`26
`
`
`
`U.S. Patent
`
`Dec. 31, 2002
`
`Sheet 25 0135
`
`US 6,502,135 B1
`
`
`
`(EVENT) TRANSMITTER
`FOR PATH x
`
`TURNS OFF
`
`
`
`
`AT LEAST
`ONE TRANSMITTER
`TURNED ON?
`
`
`
`DROP ALL PACKETS
`UNTILA TRANSMITTER
`TURNS ON
`
`
`
`NO
`
`
`
`2210
`
`2211
`
`2212
`
`SET WEIGHT
`TO ZERO
`
`
`
`
`ADJUST WEIGHTS
`FOR REMAINING
`PATHS So THAT
`WEIGHTS EQUAL ONE
`
`2213
`
`2214
`
`FIG. 22B
`
`27
`
`27
`
`
`
`U.S. Patent
`
`Dec. 31, 2002
`
`Sheet 26 of 35
`
`US 6,502,135 B1
`
`2GE
`
`:m_>_§a<
`
`29523
`
`
`
`>._._._<:ov_z_._
`
`;m__>m%m$s_
`
`zo_5_,_a
`
`EOE
`
`$E_>_mz<E
`
`
`
` was:_>_wz<m._./an
`
`28
`
`28
`
`
`
`
`U.S. Patent
`
`m
`
`US 6,502,135 B1
`
`uasamM.asas
`
`
`
`$5n_s_8E2200N
`
`«N_o_u_
`
`29
`
`
`
`U.S. Patent
`
`Dec. 31, 2002
`
`Sheet 28 of 35
`
`US 6,502,135 B1
`
`593
`
`m._._m$2
`
`mm.0_..._
`
`62meg
`
`fiesommB;
`
`30
`
`30
`
`
`
`U.S. Patent
`
`W.m.,mm
`
`0M.m
`
`US 6,502,135 B1
`
`
`
`m3%Emmwmswsoma
`
`882&0:m_
`
`:8mmsommzs
`
`Ba:93
`
`mm.0_n_
`
`mmmmmxmg
`
`mmggm
`
`0
`
`z_&oI
`
`$2
`
`mmmaomm
`
`31
`
`
`
`
`U.S. Patent
`
`Dec. 31, 2002
`
`Sheet 30 0135
`
`US 6,502,135 B1
`
`2701
`
`RECEIVE DNS
`REQUEST FOR
`
`TARGET SITE
`
`2703
`
`RETURN
`
`"HOST UNKNOWN"
`
`ERROR
`
`
`
`
`
`ACCESS TO
`SECURE SITE
`REQUESTED?
`
`YES
`
` USER
`
`
`
`AUTHORIZED TO
`
`CONNECT?
`
`2702
`
`2704
`
`YES
`
`2706
`
`ESTABLISH
`VPN WITH
`
`TARGET SITE
`
`FIG. 27
`
`32
`
`32
`
`
`
`U.S. Patent
`
`Dec. 31, 2002
`
`Sheet 31 of 35
`
`US 6,502,135 B1
`
`momw
`
`Nomm
`
`meow
`
`mmpaom
`
`Hmo:
`
`Nfimmhamzoo
`
`mm.o_u_
`
`Ewe:
`
`_%mmH=m2oo
`
`33
`
`33
`
`
`
`
`U.S. Patent
`
`Dec. 31, 2002
`
`Sheet 32 0135
`
`US 6,502,135 B1
`
`‘_.
`‘)
`0
`
`EG
`
`on
`C\l
`
`<9"
`j
`8 U.
`2
`9
`E
`&
`
`8
`2
`3
`><
`“T
`
`E-
`
`C\l
`=I=I=
`[I
`fi’
`§
`
`0
`0
`E5
`0
`II:
`
`
`
`53
`3
`
`$1‘
`Q
`
`_..I
`
`E
`:-
`2
`§
`
`ca:
`l.IJ
`ES
`<
`IE
`
`§
`€\l
`
`é’
`C\l
`
`34
`
`ECD
`J:
`(2
`I
`
`I
`§
`N
`8
`N
`
`to
`3
`$1
`
`30
`
`§
`
`8
`Q
`
`
`
`IIIII
`IIIII
`
`IIIII
`IIIII
`
`3
`an
`
`3
`
`O
`...J
`
`§
`°"
`
`5%
`88
`ca:
`
`3
`%
`
`3:
`
`E
`Es‘
`Q_
`
`EC
`
`) 0
`
`‘g
`
`34
`
`
`
`U.S. Patent
`
`Dec. 31, 2002
`
`Sheet 33 of 35
`
`US 6,502,135 B1
`
`$Es_mz<E
`
`m_>_m_omm
`
`8m-oz>w
`
`e_§_o
`
`35
`
`32cm.O_n_
`
`88
`
`35
`
`
`
`U.S. Patent
`
`Dec. 31, 2002
`
`Sheet 34 0135
`
`US 6,502,135 B1
`
`3103
`
`3106
`
`3104
`
` CLIENT#2
`
`105
`
`HACKER
`
`FIG.31
`
`
`
` 320832093210 TX/RX
`TX/RX
`TX/RX
`
`9O
`
`S
`’)
`
`36
`
`?
`E
`
`to
`
`36
`
`
`
`U.S. Patent
`
`Dec. 31, 2002
`
`Sheet 35 0135
`
`US 6,502,135 B1
`
`CLIENT
`
`SERVER
`
`PASS DATA UP STACK
`CKPT_O=CKPT_N
`GENERATE NEW CKPT_N
`GENERATE NEW CKPT_R
`FOR TRANSMITTER SIDE
`TRANSMIT SYNC_ACK
`CONTAINING CKPT_O
`
`CKPT_O=CKPT_N
`GENERATE NEW CK
`PT_N
`GENERATE NEW CK
`PT_R
`FOR TRANSMITTER SIDE
`TRANSMIT SYNC_ACK
`CONTAINING CKPT_O
`
`SEND DATA PACKET
`USING CKPT_N
`CKPT_O=CKPT_N
`GENERATE NEW CKPT_N
`START TIMER, SHUT
`TRANSMITTER OFF
`
`IF CKPT_O IN SYNC_ACK
`MATCHES TRANSMITTER'S
`CKPT_O
`UPDATE RECE|VER'S
`CKPT_R
`KILL TIMER, TURN
`TRANSMITTER ON
`
`SEND DATA PACKET
`USING CKPT_N
`CKPT_O=CKPT_N
`GENERATE NEW CKPT_N
`START TIMER, SHUT
`TRANSMITTER OFF
`
`WHEN TIMER EXPIRES
`TRANSMIT SYNC_REQ
`USING TRANSMITTERS
`CKPT_O, START TIMER
`
`IF CKPT_O IN SYNC_ACK
`MATCHES TRANSMITTER'S
`CKPT_O
`UPDATE RECEIVER'S
`CKPT_R
`KILL TIMER, TURN
`TRANSMITTER ON
`
`SYNC_REQ
`
`FIG. 32
`
`37
`
`37
`
`
`
`US 6,502,135 B1
`
`1
`AGILE NETWORK PROTOCOL FOR
`SECURE COMMUNICATIONS WITH
`ASSURED SYSTEM AVAILABILITY
`
`CROSS-REFERENCE TO RELATED
`APPLICATION
`
`This application claims priority from and is a
`continuation-in-part of previously filed U.S. application Ser.
`No. 09/429,643, filed on Oct. 29, 1999. The subject matter
`of that application, which is bodily incorporated herein,
`derives from provisional U.S. application No. 60/106,261
`(filed Oct. 30, 1998) and No. 60/137,704 (filed Jun. 7, 1999).
`BACKGROUND OF THE INVENTION
`
`Atremendous variety of methods have been proposed and
`implemented to provide security and anonymity for com-
`munications over the Internet. The variety stems, in part,
`from the different needs of different Internet users. A basic
`
`heuristic framework to aid in discussing these different
`security techniques is illustrated in FIG. 1. Two terminals, an
`originating terminal 100 and a destination terminal 110 are
`in communication over the Internet. It is desired for the
`
`communications to be secure, that is, immune to eavesdrop-
`ping. For example, terminal 100 may transmit secret infor-
`mation to terminal 110 over the Internet 107. Also, it may be
`desired to prevent an eavesdropper from discovering that
`terminal 100 is in communication with terminal 110. For
`
`example, if terminal 100 is a user and terminal 110 hosts a
`web site, terminal 100’s user may not want anyone in the
`intervening networks to know what web sites he is “visit-
`ing.” Anonymity would thus be an issue, for example, for
`companies that want to keep their market research interests
`private and thus would prefer to prevent outsiders from
`knowing which web-sites or other Internet resources they
`are “visiting.” These two security issues may be called data
`security and anonymity, respectively.
`Data security is usually tackled using some form of data
`encryption. An encryption key 48 is known at both the
`originating and terminating terminals 100 and 110. The keys
`may be private and public at the originating and destination
`terminals 100 and 110, respectively or they may be sym-
`metrical keys (the same key is used by both parties to
`encrypt and decrypt). Many encryption methods are known
`and usable in this context.
`
`To hide traffic from a local administrator or ISP, a user can
`employ a local proxy server in communicating over an
`encrypted channel with an outside proxy such that the local
`administrator or ISP only sees the encrypted traffic. Proxy
`servers prevent destination servers from determining the
`identities of the originating clients. This system employs an
`intermediate server interposed between client and destina-
`tion server. The destination server sees only the Internet
`Protocol
`(IP) address of the proxy server and not
`the
`originating client. The target server only sees the address of
`the outside proxy. This scheme relies on a trusted outside
`proxy server. Also, proxy schemes are vulnerable to traffic
`analysis methods of determining identities of transmitters
`and receivers. Another important limitation of proxy servers
`is that the server knows the identities of both calling and
`called parties. In many instances, an originating terminal,
`such as terminal A, would prefer to keep its identity con-
`cealed from the proxy, for example, if the proxy server is
`provided by an Internet service provider (ISP).
`To defeat traffic analysis, a scheme called Chaum’s mixes
`employs a proxy server that transmits and receives fixed
`length messages,
`including dummy messages. Multiple
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`2
`
`originating terminals are connected through a mix (a server)
`to multiple target servers. It is diflicult to tell which of the
`originating terminals are communicating to which of the
`connected target servers, and the dummy messages confuse
`eavesdroppers’ efforts to detect communicating pairs by
`analyzing traffic. A drawback is that there is a risk that the
`mix server could be compromised. One way to deal with this
`risk is to spread the trust among multiple mixes. If one mix
`is compromised, the identities of the originating and target
`terminals may remain concealed. This strategy requires a
`number of alternative mixes so that the intermediate servers
`
`interposed between the originating and target terminals are
`not determinable except by compromising more than one
`mix. The strategy wraps the message with multiple layers of
`encrypted addresses. The first mix in a sequence can decrypt
`only the outer layer of the message to reveal
`the next
`destination mix in sequence. The second mix can decrypt the
`message to reveal the next mix and so on. The target server
`receives the message and, optionally, a multi-layer
`encrypted payload containing return information to send
`data back in the same fashion. The only way to defeat such
`a mix scheme is to collude among mixes. If the packets are
`all fixed-length and intermixed with dummy packets, there
`is no way to do any kind of traffic analysis.
`Still another anonymity technique, called ‘crowds,’ pro-
`tects the identity of the originating terminal from the inter-
`mediate proxies by providing that originating terminals
`belong to groups of proxies called crowds. The crowd
`proxies are interposed between originating and target termi-
`nals. Each proxy through which the message is sent
`is
`randomly chosen by an upstream proxy. Each intermediate
`proxy can send the message either to another randomly
`chosen proxy in the “crowd” or to the destination. Thus,
`even crowd members cannot determine if a preceding proxy
`is the originator of the message or if it was simply passed
`from another proxy.
`ZKS (Zero-Knowledge Systems) Anonymous IP Protocol
`allows users to select up to any of five different pseudonyms,
`while desktop software encrypts outgoing traffic and wraps
`it in User Datagram Protocol (UDP) packets. The first server
`in a 2+-hop system gets the UDP packets, strips off one layer
`of encryption to add another, then sends the traffic to the next
`server, which strips off yet another layer of encryption and
`adds a new one. The user is permitted to control the number
`of hops. At the final server,
`traffic is decrypted with an
`untraceable IP address. The technique is called onion-
`routing. This method can be defeated using traffic analysis.
`For a simple example, bursts of packets from a user during
`low-duty periods can reveal the identities of sender and
`receiver.
`
`to protect LANs from unauthorized
`Firewalls attempt
`access and hostile exploitation or damage to computers
`connected to the LAN. Firewalls provide a server through
`which all access to the LAN must pass. Firewalls are
`centralized systems that require administrative overhead to
`maintain. They can be compromised by virtual-machine
`applications (“applets”). They instill a false sense of security
`that leads to security breaches for example by users sending
`sensitive information to servers outside the firewall or
`
`encouraging use of modems to sidestep the firewall security.
`Firewalls are not useful for distributed systems such as
`business travelers, extranets, small teams, etc.
`
`SUMMARY OF THE INVENTION
`
`A secure mechanism for communicating over the internet,
`including a protocol referred to as the Tunneled Agile
`
`38
`
`38
`
`
`
`US 6,502,135 B1
`
`3
`
`Routing Protocol (TARP), uses a unique two-layer encryp-
`tion format and special TARP routers. TARP routers are
`similar in function to regular IP routers. Each TARP router
`has one or more IP addresses and uses normal IP protocol to
`send IP packet messages (“packets” or “datagrams”). The IP
`packets exchanged between TARP terminals via TARP rout-
`ers are actually encrypted packets whose true destination
`address is concealed except to TARP routers and servers.
`The normal or “clear” or “outside” IP header attached to
`TARP IP packets contains only the address of a next hop
`router or destination server. That is, instead of indicating a
`final destination in the destination field of the IP header, the
`TARP packet’s IP header always points to a next-hop in a
`series of TARP router hops, or to the final destination. This
`means there is no overt indication from an intercepted TARP
`packet of the true destination of the TARP packet since the
`destination could always be next-hop TARP router as well as
`the final destination.
`
`Each TARP packet’s true destination is concealed behind
`a layer of encryption generated using a link key. The link key
`is the encryption key used for cncryptcd communication
`between the hops intervening between an originating TARP
`terminal and a destination TARP terminal. Each TARP
`
`router can remove the outer layer of encryption to reveal the
`destination router for each TARP packet. To identify the link
`key needed to decrypt the outer layer of encryption of a
`TARP packet, a receiving TARP or routing terminal may
`identify the transmitting terminal by the sender/receiver IP
`numbers in the cleartext IP header.
`
`Once the outer layer of encryption is removed, the TARP
`router determines the final destination. Each TARP packet
`140 undergoes a minimum number of hops to help foil traffic
`analysis. The hops may be chosen at random or by a fixed
`value. As a result, each TARP packet may make random trips
`among a number of geographically disparate routers before
`reaching its destination. Each trip is highly likely to be
`different for each packet composing a given message
`because each trip is independently randomly determined.
`This feature is called agile routing. The fact that different
`packets take different routes provides distinct advantages by
`making it difficult for an interloper to obtain all the packets
`forming an entire multi-packet message. The associated
`advantages have to do with the inner layer of encryption
`discussed below. Agile routing is combined with another
`feature that furthers this purpose; a feature that ensures that
`any message is broken into multiple packets.
`The IP address of a TARP router can be changed, a feature
`called IP agility. Each TARP router, independently or under
`direction from another TARP terminal or router, can change
`its IP address. A separate, unchangeable identifier or address
`is also defined. This address, called the TARP address, is
`known only to TARP routers and terminals and may be
`correlated at any time by a TARP router or a TARP terminal
`using a Lookup Table (LUT). When a TARP router or
`terminal changes its IP address, it updates the other TARP
`routers and terminals which in turn update their respective
`LUTs.
`
`The message payload is hidden behind an inner layer of
`encryption in the TARP packet that can only be unlocked
`using a session key. The session key is not available to any
`of the intervening TARP routers. The session key is used to
`decrypt the payloads of the TARP packets permitting the
`data stream to be reconstructed.
`
`Communication may be made private using link and
`session keys, which in turn may be shared and used accord-
`ing to any desired method. For example, public/private keys
`or symmetric keys may be used.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`4
`To transmit a data stream, a TARP originating terminal
`constructs a series of TARP packets from a series of IP
`packets generated by a network (IP) layer process. (Note that
`the terms “network layer,” “data link layer,” “application
`layer,” etc. used in this specification correspond to the Open
`Systems Intercomection (OSI) network terminology.) The
`payloads of these packets are assembled into a block and
`chain-block encrypted using the session key. This assumes,
`of course, that all the IP packets are destined for the same
`TARP terminal. The block is then interleaved and the
`
`interleaved encrypted block is broken into a series of
`payloads, one for each TARP packet to be generated. Special
`TARP headers IPT are then added to each payload using the
`IP headers from the data stream packets. The TARP headers
`can be identical to normal IP headers or customized in some
`
`way. They should contain a formula or data for deinterleav-
`ing the data at the destination TARP terminal, a time-to-live
`(TTL) parameter to indicate the number of hops still to be
`executed, a data type identifier which indicates whether the
`payload contains,
`for example, TCP or UDP data,
`the
`scndcr’s TARP address, the destination TARP address, and
`an indicator as to whether the packet contains real or decoy
`data or a formula for filtering out decoy data if decoy data
`is spread in some way through the TARP payload data.
`Note that although chain-block encryption is discussed
`here with reference to the session key, any encryption
`method may be used. Preferably, as in chain block
`encryption, a method should be used that makes unautho-
`rized decryption difficult without an entire result of the
`encryption process. Thus, by separating the encrypted block
`among multiple packets and making it difficult
`for an
`interloper to obtain access to all of such packets, the contents
`of the communications are provided an extra layer of
`security.
`Decoy or dummy data can be added to a stream to help
`foil traffic analysis by reducing the peak-to-average network
`load. It may be desirable to provide the TARP process with
`an ability to respond to the time of day or other criteria to
`generate more decoy data during low traffic periods so that
`communication bursts at one point in the Internet cannot be
`tied to communication bursts at another point to reveal the
`communicating endpoints.
`Dummy data also helps to break the data into a larger
`number of inconspicuously-sized packets permitting the
`interleave window size to be increased while maintaining a
`reasonable size for each packet. (The packet size can be a
`single standard size or selected from a fixed range of sizes.)
`One primary reason for desiring for each message to be
`broken into multiple packets is apparent if a chain block
`encryption scheme is used to form the first encryption layer
`prior to interleaving. A single block encryption may be
`applied to portion, or entirety, of a message, and that portion
`or entirety then interleaved into a number of separate
`packets. Considering the agile IP routing of the packets, and
`the attendant difficulty of reconstructing an entire sequence
`of packets to form a single block-encrypted message
`element, decoy packets can significantly increase the diffi-
`culty of reconstructing an entire data stream.
`The above scheme may be implemented entirely by
`processes operating between the data link layer and the
`network layer of each server or terminal participating in the
`TARP system. Because the encryption system described
`above is insertable between the data link and network layers,
`the processes involved in supporting the encrypted commu-
`nication may be completely transparent to processes at the IP
`(network) layer and above. The TARP processes may also be
`completely transparent to the data link layer processes as
`
`39
`
`39
`
`
`
`US 6,502,135 B1
`
`5
`well. Thus, no operations at or above the Network layer, or
`at or below the data link layer, are affected by the insertion
`of the TARP stack. This provides additional security to all
`processes at or above the network layer, since the difficulty
`of unauthorized penetration of the network layer (by, for
`example, a hacker) is increased substantially. Even newly
`developed servers running at
`the session layer leave all
`processes below the session layer vulnerable to attack. Note
`that
`in this architecture, security is distributed. That
`is,
`notebook computers used by executives on the road, for
`example, can communicate over the Internet without any
`compromise in security.
`IP address changes made by TARP terminals and routers
`can be done at regular intervals, at random intervals, or upon
`detection of “attacks.” The variation of IP addresses hinders
`
`traffic analysis that might reveal which computers are
`communicating, and also provides a degree of immunity
`from attack. The level of immunity from attack is roughly
`proportional to the rate at which the IP address of the host
`is changing.
`As mentioned, IP addresses may be changed in response
`to attacks. An attack may be reveal