a: f’ I"
`
`Q §E‘5‘-
`Q§§3
`Hg
`{1:c
`gf‘”3
`E *v
`Page 1 E‘3
`
`NEW UNITED STATES UTILITY PATENT APPLICATION
`under 37 C.F.R. 1.530;)
`
`/
`{
`
`t
`Atty. Docket No. 0047935672
`
`Commissioner of Patents
`.
`.
`Box Patent Applications
`Washington, DC. 20231
`
`EDGE
`nah-Ea
`3.3% S
`3:153
`”‘12 s
`
`80..
`C’
`in;
`_
`
`1
`
`u
`
`
`
`1.
`
`2.
`
`3‘
`
`4.
`
`5.
`
`0‘»-
`
`‘41
`
`Enclosed herewith is a new patent application and the following papers:
`
`First Named Inventor (or application identifier):
`
`Edmund Colby Munger, et a1.
`
`Title of Invention:
`
`Improvements To An Agile Network Protocol For Secure Communications With
`Assured System Availability
`
`Specification §4_ pages (including specification, claims, abstract) / A claims (2 independent)
`
`Declaration/Power of Attorney is:
`I
`attached in the regular manner,
`I]
`NQT included, but deferred under 37 C.F.R. § 1.53 (i).
`
`3_5 Distinct sheets of U Formal I Informal Drawings
`
`Preliminary Amendment.
`
`Information Disclosure Statement
`E]
`Form 1449
`
`E]
`
`A copy of each cited prior art reference
`
`Assignment with Cover Sheet.
`
`Priority is hereby claimed under 35 U.S.C. § 119(e) and §120 based upon the following application(s):
`
`I
`
`I
`
`I
`
`Cl
`
`I]
`
`I
`
`I
`
`
`
`99mm (new. 9009
`
`,
`
`90/90/90
`
`0/7/99
`
`10/29/99
`
`00/000,201
`
`00/197,704
`
`09/429,049
`
`8.
`
`9.
`
`10.
`
`U
`
`El
`
`U
`
`Priority document(s).
`
`Statement Claiming Small Entity Status.
`
`Microfiche Computer Program (Appendix).
`
`1
`
`MICROSOFT 1002
`
`1
`
`MICROSOFT 1002
`
`

`

`NEW UNITED STATES UTILITY PATENT APPLICATION
`under 37 c.1111. 1.5301)
`
`Page 2
`
`1 1.
`
`Calculation of Fees:
`
`Atty. Docket No. 00479.85672
`
`
`
`_XCESSCLAIMS
`
`
`BasicFilin; Fee 37 C.FR. \ 1.16 a
`
`Total ClaimsinExcess of20 37C...FR 1.16 c
`
`18.00
`
`$690.00
`
`$918.00
`
`$468.00
`$0.00
`
`
`
`
`
`
`Indendent ClaimsinExeessof3 37 C.F.R. ‘ 1.16 n —1 78.00
`
`
`MultileD nendentClaims 37C...FR ~ 116 d — 260.00
`
`
`Subtotal- Filin; Fee Due
`$2,076.00
`
`Reductionb 50%,1mea11Ent1
`37 c..FR. 1.9, 127, 1.28 —$ $0.00
`
`
`TOTALFJLINGFEEDUE
`11—2076.00—40.00
`
` $2,116.00
`PAYMENT is:
`
`
`
`I
`
`included in the amount of the GRAND TOTAL by our enclosed check. A general authorization under 37
`C.F.R § l.25(b), second sentence, is hereby given to credit or debit our Deposit Account No. 19-0733 for the
`instantfiling and forany other fees during the pendency ofthis application under 37 C.F.R. §§ 1.16, 1.17 and
`1.18.
`
`CI
`
`not included, but deferred under 37 C.F.R. § 153(1).
`
`All correspondence for the attached application should be directed to:
`
`Banner & Witcofl‘, Ltd.
`1001 G Street, NW.
`Washington, D. C. 20001-4597
`Telephone: (202) 508-9100
`Facsimile: (202) 508-9299
`
`
`
`14.
`
`Other:
`
`
`
`Date:
`
`Fem15, 20129
`
`BCW/pp
`
`By:
`
`
`' {fl/
`
`Bradley C. Wright
`Reg. No. 38,061
`
`2
`
`

`

`047985672
`
`IMPROVEMENTS TO AN AGILE NETWORK PROTOCOL
`FOR SECURE COMMUNICATIONS
`WITH ASSURED SYSTEM AVAILABILITY
`
`10
`
`
`
`CROSS-REFERENCE TO RELATED APPLICATION
`
`This application claims priority from and is a continuation-in—part of previously filed U.S.
`
`application serial number 09/429,643, filed on October 29, 1999. The subject matter of that
`
`application, which is bodily incorporated herein, derives from provisional U.S. application
`
`numbers 60/106,261 (filed October 30, 1998) and 60/137,704 (filed June 7, 1999).
`
`BACKGROUND OF THE INVENTION
`
`A tremendous variety of methods have been proposed and implemented to provide
`
`security and anonymity for communications 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 eavesdropping. For example, terminal 100 may
`
`transmit secret information 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 "visiting."
`
`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
`
`25
`
`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
`
`3
`
`

`

`0479.85672
`
`may be symmetrical 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 destination 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 concealed 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 originating
`
`terminals are connected through a mix (a server) to multiple target servers. It is difficult 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
`
`
`
`20
`
`25
`
`4
`
`

`

`0479.85672
`
`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,’ protects the identity of the originating
`
`terminal from the intermediate proxies by providing that originating terminals belong to groups
`
`of proxies called crowds. The crowd proxies are interposed between originating and target
`
`terminals. 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 fiom a user during low-duty periods can reveal
`
`the identities of sender and receiver.
`
`Firewalls attempt to protect LANs from unauthorized 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.
`
`
`
`
`20
`
`25
`
`5
`
`

`

`0479.85672
`
`W A
`
`secure mechanism for communicating over the internet, including a protocol referred
`
`to as the Tunneled Agile Routing Protocol (TARP), uses a unique two-layer encryption format
`
`and special TARP routers. TARP routers are similar in function to regular 1P routers. Each
`
`TARP router has one or more IP addresses and uses normal IP protocol to send H’ packet
`
`messages (“packets” or “datagrarns”). The IP packets exchanged between TARP terminals via
`
`TARP routers are actually encrypted packets whose true destination address is concealed except
`
`to TARP routers and servers. The normal or “clear” or “outside” LP 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 encrypted cormnunication 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
`
`
`
`20
`
`25
`
`
`
`6
`
`

`

`0479.85672
`
`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 1P 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 according to any desired method. For example, public/private keys or symmetric
`
`keys may be used.
`
`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 UP) layer process. (Note that the
`
`terms “network layer,” “data link layer," “application layer,” etc. used in this specification
`
`correspond to the Open Systems Interconnection (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 [PT are then added to each payload
`
`using the [P 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 deinterleaving
`
`
`
`20
`
`25
`
`
`
`7
`
`

`

`0479.85672
`
`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 sender’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 unauthorized 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
`
`20
`
`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
`
`25
`
`packets to form a single block-encrypted message element, decoy packets can significantly
`
`increase the difficulty 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.
`
`
`
`8
`
`

`

`0479.85672
`
`Because the encryption system described above is insertable between the data link and network
`
`layers, the processes involved in supporting the encrypted communication 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 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
`
`revealed, for example, by a regular series of messages indicating that a router is being probed in
`
`some way. Upon detection of an attack, the TARP layer process may respond to this event by
`
`changing its IP address. In addition, it may create a subprocess that maintains the original IP
`
`address and continues interacting with the attacker in some manner.
`
`Decoy packets may be generated by each TARP terminal on some basis determined by an
`
`algorithm. For example, the algorithm may be a random one which calls for the generation of a
`
`packet on a random basis when the terminal
`
`is idle. Alternatively,
`
`the algorithm may be
`
`responsive to time of day or detection of low traffic to generate more decoy packets during low
`
`traffic times. Note that packets are preferably generated in groups, rather than one by one, the
`
`groups being sized to simulate real messages. In addition, so that decoy packets may be inserted
`
`in normal TARP message streams, the background loop may have a latch that makes it more
`
`
`
`
`
`20
`
`25
`
`9
`
`

`

`0479.85 672
`
`likely to insert decoy packets when a message stream is being received. Alternatively, if a large
`
`number of decoy packets is received along with regular TARP packets, the algorithm may
`
`increase the rate of dropping of decoy packets rather than forwarding them. The result of
`
`dropping and generating decoy packets in this way is to make the apparent incoming message
`
`size different from the apparent outgoing message size to help foil traffic analysis.
`
`In various other embodiments of the invention, a scalable version of the system may be
`
`constructed in which a plurality of IP addresses are preassigned to each pair of communicating
`
`nodes in the network. Each pair of nodes agrees upon an algorithm for “hopping” between IP
`
`addresses (both sending and receiving), such that an eavesdropper sees apparently continuously
`
`random IP address pairs (source and destination) for packets transmitted between the pair.
`
`Overlapping or “reusable” IP addresses may be allocated to different users on the same subnet,
`
`since each node merely verifies that a particular packet includes a valid source/destination pair
`
`from the agreed—upon algorithm. Source/destination pairs are preferably not reused between any
`
`two nodes during any given end-to-end session, though limited IP block sizes or lengthy sessions
`
`might require it.
`
`Further improvements described in this continuation-impart application 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 separate entities
`
`BRIEF DESCRIPTIQN OF THE DRAWINGS
`
`FIG. 1 is an illustration of secure communications over the Internet according to a prior
`
`art embodiment.
`
`FIG. 2 is an illustration of secure communications over the Internet according to a an
`
`embodiment of the invention.
`
`
`
`
`20
`
`25
`
`10
`
`10
`
`

`

`0479.85672
`
`FIG. 3a is an illustration of a process of forming a tunneled IP packet according to an
`
`embodiment of the invention.
`
`FIG. 3b is an illustration of a process of forming a tunneled IP packet according to
`
`another embodiment of the invention.
`
`FIG. 4 is an illustration of an 081 layer location of processes that may be used to
`
`implement the invention.
`
`FIG. 5 is a flow chart illustrating a process for routing a tunneled packet according to an
`
`embodiment of the invention.
`
`FIG. 6 is a flow chart illustrating a process for forming a tunneled packet according to an
`
`embodiment of the invention.
`
`FIG. 7 is a flow chart illustrating a process for receiving a tunneled packet according to
`
`an embodiment of the invention.
`
`FIG. 8 shows how a secure session is established and synchronized between a client and a
`
`TARP router.
`
`FIG. 9 shows an IP address hopping scheme between a client computer and TARP router
`
`using transmit and receive tables in each computer.
`
`FIG. 10 shows physical link redundancy among three Internet Service Providers (ISPs)
`
`and a client computer.
`
`‘
`
`FIG. 11 shows how multiple IP packets can be embedded into a single “frame” such as an
`
`Ethernet frame, and further shows the use of a discriminator field to camouflage true packet
`
`recipients.
`
`FIG. 12A shows a system that employs hopped hardware addresses, hopped IP addresses,
`
`and hopped discriminator fields.
`
`FIG. 123 shows several different approaches for hopping hardware addresses,
`
`IP
`
`addresses, and discriminator fields in combination.
`
`FIG. 13 shows a technique for automatically re-establishjng synchronization between
`
`sender and receiver through the use of a partially public sync value.
`
`
`
`20
`
`25
`
`11
`
`11
`
`

`

`047985672
`
`FIG. 14 shows a “checkpoint” scheme for regaining synchronization between a sender
`
`and recipient.
`
`FIG. 15 shows fluther details of the checkpoint scheme of FIG. 14.
`
`FIG. 16 shows how two addresses can be decomposed into a plurality of segments for
`
`comparison with presence vectors.
`
`FIG. 17 shows a storage array for a receiver’s active addresses.
`
`FIG. 18 shows the receiver’s storage array afier receiving a sync request.
`
`FIG. 19 shows the receiver’s storage array afier new addresses have been generated.
`
`FIG. 20 shows a system employing distributed transmission paths.
`
`FIG. 21 shows a plurality of link transmission tables that can be used to route packets in
`
`the system of FIG. 20.
`
`FIG. 22A shows a flowchart for adjusting weight value distributions associated with a
`
`plurality of transmission links.
`
`FIG. 223 shows a flowchart for setting a weight value to zero if a transmitter turns off.
`
`FIG. 23 shows a system employing distributed transmission paths with adjusted weight
`
`value distributions for each path.
`
`FIG. 24 shows an example using the system of FIG. 23.
`
`FIG. 25 shows a conventional domain—name look-up service.
`
`FIG. 26 shows a system employing a DNS proxy server with transparent VPN creation.
`
`FIG. 27 shows steps that can be carried out to implement transparent VPN creation based
`
`on a DNS look-up function.
`
`
`
`
`
`20
`
`FIG. 28 shows a system including a link guard fimction that prevents packet overloading
`
`on a low-bandwidth link LOW BW.
`
`FIG. 29 shows one embodiment of a system employing the principles of FIG. 28.
`
`25
`
`FIG. 30 shows a system that regulates packet transmission rates by throttling the rate at
`
`which synchronizations are performed.
`
`FIG. 31 shows a signaling server 3101 and a transport server 3102 used to establish a
`
`VPN with a client computer.
`
`10
`
`12
`
`12
`
`

`

`047985672
`
`FIG. 32 shows message flows relating to synchronization protocols of FIG. 31.
`
`W R
`
`eferring to FIG. 2, a secure mechanism for communicating over the intemet employs a
`
`number of special routers or servers, called TARP routers 122-127 that are similar to regular IP
`
`routers 128-132 in that each has one or more IP addresses and uses normal IP protocol to send
`
`normal-looking IP packet messages, called TARP packets 140. TARP packets 140 are identical
`
`to normal IP packet messages that are routed by regular 1P routers 128-132 because each TARP
`
`packet 140 contains a destination address as in a normal 1P packet. However,
`
`instead of
`
`indicating a final destination in the destination field of the IP header, the TARP packet’s 140 IP
`
`header always points to a next-hop in a series of TARP router hops, or the final destination,
`
`TARP terminal 110. Because the header of the TARP packet contains only the next-hop
`
`destination, there is no overt indication from an intercepted TARP packet of the true destination
`
`of the TARP packet 140 since the destination could always be the next-hop TARP router as well
`
`as the final destination, TARP terminal 110.
`
`Each TARP packet’s true destination is concealed behind an outer layer of encryption
`
`generated using a link key 146. The link key 146 is the encryption key used for encrypted
`
`communication between the end points (TARP terminals or TARP routers) of a single link in the
`
`chain of hops connecting the originating TARP terminal 100 and the destination TARP terminal
`
`110. Each TARP router 122-127, using the link key 146 it uses to communicate with the
`
`previous hop in a chain, can use the link key to reveal the true destination of a 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 (which may indicate
`
`the link key used) by the sender field of the clear 1P header. Alternatively, this identity may be
`
`hidden behind another layer of encryption in available bits in the clear lP header. Each TARP
`
`router, upon receiving a TARP message, determines if the message is a TARP message by using
`
`authentication data in the TARP packet. This could be recorded in available bytes in the TARP
`
`packet’s TP header. Alternatively, TARP packets could be authenticated by attempting to decrypt
`
`
`
`10
`
`15
`
`20
`
`25
`
`ll
`
`13
`
`13
`
`

`

`0479.85672
`
`using the link key 146 and determining if the results are as expected. The former may have
`
`computational advantages because it does not involve a decryption process.
`
`Once the outer layer of decryption is completed by a TARP router 122-127, the TARP
`
`router determines the final destination. The system is preferably designed to cause each TARP
`
`packet 140 to undergo a minimum number of hops to help foil traffic analysis. The time to live
`
`counter in the IP header of the TARP message may be used to indicate a number of TARP router
`
`hops yet to be completed. Each TARP router then would decrement the counter and determine
`
`from that whether it should forward the TARP packet 140 to another TARP router 122-127 or to
`
`the destination TARP terminal 110. If the time to live counter is zero or below zero afier
`
`decrementing, for an example of usage, the TARP router receiving the TARP packet 140 may
`
`forward the TARP packet 140 to the destination TARP terminal 110. If the time to live counter is
`
`above zero afier decrementing, for an example of usage, the TARP router receiving the TARP
`
`packet 140 may forward the TARP packet 140 to a TARP router 122—127 that the current TARP
`
`terminal chooses at random. As a result, each TARP packet 140 is routed through some
`
`minimum number of hops of TARP routers 122-127 which are chosen at random.
`
`Thus, each TARP packet, irrespective of the traditional factors determining traffic in the
`
`Internet, makes random trips among a number of geographically disparate routers before
`
`reaching its destination and each trip is highly likely to be different for each packet composing a
`
`given message because each trip is independently randomly determined as described above. This
`
`feature is called agile routing. For reasons that will become clear shortly, 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. Agile routing is combined with
`
`another feature that furthers this purpose, a feature that ensures that any message is broken into
`
`multiple packets.
`
`A TARP router receives a TARP packet when an EP address used by the TARP router
`
`coincides with the IP address in the TARP packet’s IP header IPC. The IP address of a TARP
`
`router, however, may not remain constant. To avoid and manage attacks, each TARP router,
`
`independently or under direction from another TARP terminal or router, may change its IP
`
`
`
`
`20
`
`25
`
`12
`
`14
`
`14
`
`

`

`047985672
`
`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. In reality, whenever a TARP router looks up the address of a
`
`destination in the encrypted header, it must convert a TARP address to a real IP address using its
`
`LUT.
`
`While every TARP router receiving a TARP packet has the ability to determine the
`
`packet’s final destination, the message payload is embedded 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 TARP routers 122-127 intervening between the originating 100 and
`
`destination 110 TARP terminals. The session key is used to decrypt the payloads of the TARP
`
`packets 140 permitting an entire message to be reconstructed.
`
`In one embodiment, communication may be made private using link and session keys,
`
`which in turn may be shared and used according any desired method. For example, a public key
`
`or symmetric keys may be communicated between link or session endpoints using a public key
`
`method. Any of a variety of other mechanisms for securing data to ensure that only authorized
`
`computers can have access to the private information in the TARP packets 140 may be used as
`
`desired.
`
`Referring to FIG. 3a, to construct a series of TARP packets, a data stream 300 of IP
`
`packets 207a, 207b, 207c, etc., such series of packets being formed by a network (1?) layer
`
`process, is broken into a series of small sized segments. In the present example, equal-sized
`
`segments 1-9 are defined and used to construct a set of interleaved data packets A, B, and C.
`
`Here it is assumed that the number of interleaved packets A, B, and C f