An agile network protocol for secure communications with assured system availability

Description: TECHNICAL FIELD [Detailed description of the invention]

【0001】

Related application This application claims the priority of the subjects of two patent provisional applications already filed, Provisional Application Nos. 60/106261 (filed October 30, 1998) and No. 60/137704 (filed June 7, 1999). And the subject matter is incorporated as a whole. [0002]

Background of the invention A wide variety of methods have been proposed and implemented to ensure the security and anonymity of communications over the Internet. This variety is due in part to the different needs of different Internet users. Figure 1 shows the basic heuristic structure that helps discuss these various security techniques. The two terminals, that is, the source terminal 100 and the destination terminal 110, communicate via the Internet. It is desirable that the communication be secure, that is, the communication is not eavesdropped. For example, terminal 100 may send confidential information to terminal 110 via the Internet 107. It may also be desirable for eavesdroppers to be unaware that the terminal 100 is communicating with the terminal 110. For example, if terminal 100 is a user and terminal 110 operates a website, then the user of terminal 100 knows who in the network is "accessing" which website. You may not want to be. So, for example, you want to keep the subject of your market research private, and thus prevent outsiders from knowing which of your website or other Internet resources you are "accessing". Anonymity is important for companies that want to. These two security issues can be called data security and anonymity, respectively. [0003]

Data security is usually addressed using some form of data encryption. The encryption key 48 is known on both the source terminals 100 and 110. This key may be a private key and a public key on the source terminal 100 and the destination terminal 110, respectively, or a symmetric key (the same key is used by both parties for encryption and decryption). Many encryption methods are known and can be used in this case. [0004]

To hide traffic from local administrators or ISPs, users can use local epoxies when communicating with external epoxies through encrypted channels so that this local administrator or ISP sees only encrypted traffic. You can use the server. The proxy server prevents the called server from determining the identity of the calling client. This system uses an intermediate server that intervenes between the client and the destination server. The called server only looks at the proxy server's Internet Protocol (IP) address, not the source client. The target server only sees the address of the external proxy. This method relies on a trusted external proxy server. In addition, the proxy method is easily affected by the traffic analysis method for determining the IDs of the sender and the receiver. Another important limitation of proxy servers is that the server knows the identities of both the caller and the called party. In many examples, a source terminal, such as Terminal A, wants to hide the terminal's ID from the proxy if a proxy server is provided by the Internet Service Provider (ISP). [0005]

To disable traffic analysis, a method called Chaum's mix uses a proxy server that sends and receives fixed-length messages, including dummy messages. Multiple source terminals are connected to multiple target servers through a mix (server). It is difficult to determine which source terminal is communicating with which of the connected target servers, and dummy messages allow eavesdroppers to detect communication pairs by analyzing traffic. Things get harder. The disadvantage of this method is that the mix server can be breached. One way to deal with this danger is to distribute responsibility across multiple mixes. That is, even if one mix is broken, the IDs of the source terminal and the target terminal can be kept hidden. This method requires some alternative mixes so that the intermediate server between the source terminal and the target terminal cannot be determined unless a plurality of mixes are compromised. In this method, the message is covered with multiple encrypted address layers. The first mix in the sequence can only decode the outer layer of the message to know the next destination mix in the sequence. The second mix decodes this message to find out the next mix, and so on. The target server receives the message and optionally receives a multilayer encrypted payload containing return information to send back the data as well. The only way to disable such a mix scheme is to collusion the mix. If all the packets are fixed length and the packets are mixed with dummy packets, then any kind of traffic analysis is not possible. [0006]

Another anonymity technique called "cloud" is a technique that protects the identity of the source terminal from intermediate proxies by making the source terminal belong to a proxy group called the cloud. The cloud proxy intervenes between the source terminal and the target terminal. Each proxy through which the message passes is randomly selected by the upstream proxy. Each intermediate proxy can send a message to another randomly selected proxy or destination in the "cloud". Therefore, even cloud members cannot determine if the originator of the message is the previous proxy or if the message was only forwarded from another proxy. [0007]

The ZKS (Zero Norridge System) Anonymous IP Protocol allows users to choose between five different anonymous ones, while desktop software encrypts outbound traffic and User Datagram Protocol (UDP) packets. Hidden inside. The first server in the 2+ -hop system gets the UDP packet, strips one encryption layer, adds another encryption layer, and then sends this traffic to the next server. This server removes yet another encryption layer and adds a new encryption layer. The user can control the number of hops. At the last server, traffic is decrypted with an untraceable IP address. This technique is called onion routing. This method can be disabled using traffic analysis. In a simple example, a burst of packets from a user during a low duty period may reveal the sender and receiver identities. [0008]

Firewalls attempt to protect the LAN from unauthorized access, malicious use of computers connected to the LAN, or damage to such computers. A firewall is a centralized system that needs to maintain an administrative overhead. Firewalls can be broken by virtual machine applications (applets). Such applications cause a security breach, for example by sending sensitive information to a server outside the firewall or recommending that a modem be used to bypass firewall security. Infiltrate. Firewalls are not useful for distributed systems such as business travelers, extranets, and small teams. [0009]

Outline of the invention Security mechanisms that communicate over the Internet, including a protocol called the Tunnel Azil Routing Protocol (TARP), use a unique two-layer cryptographic format and a specialized TARP router. TARP routers are similar in function to legitimate IP routers. Each TARP router has one or more addresses and uses the usual IP protocols to send IP packet messages (packets or datagrams). An IP packet exchanged between TARP terminals via a TARP router is an actually encrypted packet in which the true destination address is hidden except for the TARP router and server. TARP A regular IP header or "plain" or "external" IP header attached to an IP packet contains only the address of the next hop router or destination server. That is, the IP header of a TARP packet does not always indicate the last destination in the destination field of the IP header, but always points to the next or last destination in a set of TARP router hops. This means that the intercepted TARP packet has no clear indication of the true destination of the TARP packet, since the destination is always the next hop TARP router and the final destination. [0010]

The true destination of each TARP packet is hidden in the encryption layer generated using the link key. The link key is an encryption key used for encrypted communication between hops intervening between the source TARP terminal and the destination TARP terminal. Each TARP router can remove the encryption outer layer to know the destination router of each TARP packet. The receiving TARP or routing terminal identifies the sending terminal by the sender / receiver IP number in the plaintext IP header to identify the link key required to decrypt the encrypted outer layer of the TARP packet. be able to. [0011]

After the encrypted outer layer is removed, the TARP router determines the final destination. Each TARP packet 140 receives a minimum number of hops to help disable traffic analysis. Hops can be randomly selected or can be of constant value. As a result, each TARP packet can randomly move between several geographically distinct routers before arriving at the destination. Since each move is independently and randomly determined, it is very likely that it will be different for each packet that makes up a given message. This function is called azil routing. The various packets take different routes, making it difficult for an intruder to get all the packets that make up the entire multi-packet message. The advantage associated with this is the advantage related to the encryption inner layer described later. Azil routing is combined with other features that facilitate this purpose: allowing any message to be split into multiple packets. [0012]

The IP address of the TARP router does not have to be constant, and this function is called IP agility. Each TARP router can change its IP address independently or under the direction of another TARP terminal or TARP router. Another modifiable identifier or address is also defined. This address, called the TARP address, is known only to TARP routers and TARP terminals and can be correlated at any time by the TARP router or TARP terminal using a look-up table (LUT). When the TARP router or TARP terminal changes its IP address, it updates other TARP routers or TARP terminals, and these TARP routers or TARP terminals update their respective LUTs. [0013]

The message payload is hidden in the encrypted inner layer in the TARP packet, which cannot be unlocked without using the session key. The session key is a key that cannot be used by any of the intervening TARP routers. The session key is used to decrypt the payload of the TARP packet and allow the data stream to be reconstructed. [0014]

The link key and session key can be used to keep the communication private, and the link key and session key can be shared and used according to any desired method. For example, you can use a public / private key or a symmetric key. [0015]

When transmitting a data stream, the TARP source terminal composes a series of TARP packets from a series of IP packets generated by a network (IP) layer process. (Note that the "network layer," "data link layer," "application layer," etc. used herein correspond to open system interconnect (OSI) network terminology.) The payload is assembled as blocks and chain blocks encrypted using the session key. Of course, in this case, it is assumed that all IP packets are destined for the same TARP terminal. This block is then interleaved, and the interleaved encrypted block is split into a set of payloads for each TARP packet to be generated. Then, using the IP header obtained from the data stream packet, a special TARP header IP for each payload_rIs added. The TARP header can be the same as a regular IP header or can be customized in some way. The TARP header is a method or data for deinterleaving data on the destination TARP terminal, a time-to-lib (TTL) parameter indicating the number of hops to perform, whether the payload contains, for example, TCP data or UDP. Data type identifier indicating whether the data is included, the sender's TARP address, the destination TARP address, an indicator of whether the packet contains actual data or decoy data, or the decoy data is TARP payload data. It should include a method of removing decoy data when disseminated in some way through. [0016]

Although chain block ciphers are discussed herein for session keys, it should be noted that any encryption method can be used. Preferably, as with chain block ciphers, methods should be used that make unauthorized decryption difficult unless the entire result of the encryption process is obtained. Therefore, separating the encrypted block between multiple packets and making it difficult for an intruder to access all such packets provides a special layer of security to the content of the communication. [0017]

Decoy data or dummy data can be added to the stream to help disable traffic analysis by reducing the peak-to-average network load. More decoys during low traffic periods in response to time or other criteria so that a communication burst at one point in the Internet can be combined with a communication burst at another point to make the communication endpoint invisible. -It is desirable to give the TARP process the ability to generate data. [0018]

Dummy data allows the data to be split into more unobtrusive sized packets to increase the size of the interleaved window, while at the same time helping to maintain a reasonable size for each packet. (The packet size can be a single standard size, or you can choose from a range of sizes.) One main reason why it is desirable to split each message into multiple packets is before interleaving. This is apparent when the first layer of encryption is formed using a chain block cipher. A single block cipher can be applied to part or all of the message, and then that part or whole can be interleaved to obtain several separate packets. Given the difficulty of azil IP routing of packets and the accompanying restructuring of the entire sequence of packets to form a single block-encrypted message element, decoy packets are data streams. It turns out that it significantly increases the difficulty of reconstructing the whole. [0019]

The above scheme can be fully implemented by a process running between the data link layer and the network layer of each server or terminal participating in the TARP system. Since the encryption system described above can be inserted between the data link layer and the network layer, the process used to support encrypted communication should be a process above the IP (network) layer. On the other hand, it may be completely transparent. The TARP process may also be completely transparent to the data link layer process. Therefore, neither the operation above the network layer nor the operation below the data link layer is affected by inserting the TARP stack. This greatly increases the difficulty of unauthorized access to the network layer (for example, by hackers), thus providing additional security for all processes above the network layer. Even for newly developed servers running at the session layer, all processes below the session layer can be compromised. Note that security is distributed in this architecture. That is, for example, a notebook computer used by a mobile manager can communicate over the Internet without compromising security. [0020]

IP address changes by TARP terminals and TARP routers can be done at regular or random intervals, or when an "intrusion" is detected. Changing the IP address suppresses traffic analysis, which allows you to know which computer is communicating, and also provides some protection against intrusion. The degree of protection against intrusion is approximately proportional to the rate at which the host's IP address changes. [0021] [0021]

As mentioned above, the IP address can be changed in response to an intrusion. For example, an intrusion can be detected by a series of messages that were an organization indicating that a router is being investigated in a certain way. When an intrusion is detected, the TARP tier process can respond to this event by changing its IP address. The TARP tier process can also create subprocesses that maintain the initial IP address and in some way continue to interact with the intruder. [0022]

Decoy packets can be generated by each TARP terminal according to certain criteria determined by the algorithm. For example, the algorithm may be a random algorithm that requires random packets to be generated when the terminal is idle. Alternatively, the algorithm can generate more decoy packets at low traffic in response to detection of time or low traffic. Note that packets are preferably generated as a group of sizes that simulate the actual message, rather than being generated one at a time. Also, the background loop may have a latch that increases the likelihood of inserting a decoy packet when the message stream is being received so that the decoy packet can be inserted into a regular TARP message stream. it can. Alternatively, if a large number of decoy packets are received along with legitimate TARP packets, the algorithm can increase the rate at which these decoy packets are removed rather than forwarded. When decoy packets are removed and generated in this way, the apparent incoming message size is different from the apparent outgoing message size, and traffic analysis can be disabled. [0023]

In various other aspects of the invention, a scalable version of the system in which multiple IP addresses are pre-assigned to each communication node pair in the network can be configured. Each node pair agrees on an algorithm for "hopping" between IP addresses (both sender and receiver), so eavesdroppers are apparently contiguous in packets transmitted between communication node pairs. View random IP addresses. Duplicate IP addresses or "reusable" IPs for several different users on the same subnet, as each node only verifies that it contains a valid source / destination pair according to the agreed algorithm. Addresses can be assigned. Preferably, the source / destination pair is reused between two nodes during a given end-to-end session unless the IP block size is limited or the session is long. There is nothing to do. [0024]

Detailed description of aspects As can be seen in Figure 2, the security mechanism for communicating over the Internet is that each router has one or more IP addresses and uses regular IP protocols with TARP Packet 140. It uses some special routers or servers called TARP routers 122-127, which are similar to legitimate IP routers 128-132 in that they send IP packet messages similar to regular packets. .. The TARP packet 140 is identical to a regular IP packet message routed by legitimate IP routers 128-132, as each contains a destination address similar to a regular IP packet. But TARP packet 140 The IP header does not indicate the last destination in the destination field of the IP header, but always points to the next or last destination in a set of TARP router hops, namely the TARP terminal 110. Since the header of the TARP packet contains only the next hop destination, the destination is always the next hop TARP router and the last destination, i.e. the TARP terminal 110, so the intercepted TARP packet is the true of that TARP packet. There is no clear indication of the destination of the call. [0025]

The true destination of each TARP packet is hidden in the encrypted outer layer generated using the link key 146. The link key 146 is used for encrypted communication between the endpoint (TARP terminal or TARP router) of a single link in the chain of hops connecting the source TARP terminal 100 and the destination TARP terminal 110. It is an encryption key. Each TARP router 122-127 can know the true destination of the TARP packet using the link key 146 used to communicate with the previous hop in the chain. The receiving TARP or routing terminal can indicate the link key used by the sending field in the plaintext IP header to identify the link key needed to decrypt the encrypted outer layer of the TARP packet. ) The sender terminal can be identified. Alternatively, the ID can be hidden by another encryption layer in the available bits in the plaintext IP header. When each TARP router receives a TARP message, it determines whether the message is a TARP message by using the authentication data in the TARP packet. This can be recorded in the available bytes in the IP header of the TARP packet. Alternatively, the TARP packet can be authenticated by attempting decryption using the link key 146 and determining if the result is the expected result. This method has a computational advantage because it does not involve a decoding process. [0026]

After the decryption outer layer is completed by TARP routers 122-127, the TARP router determines the final destination. The system is preferably configured to allow each TARP packet 140 to undergo a minimum number of hops to help disable traffic analysis. A time-to-live counter in the IP header of a TARP message can be used to indicate the number of remaining TARP router hops to complete. Each TARP router then decrements this counter to determine whether the TARP packet 140 should be forwarded to the other TARP routers 122-127 or to the destination TARP terminal 110. When the time-to-live counter becomes zero or less after the decrement, as an example of use, the TARP router that has received the TARP packet 140 can transfer the TARP packet 140 to the destination TARP terminal 110. If the time-to-live counter exceeds zero after the decrement, as an example, the TARP router that received the TARP packet 140 will have this TARP terminal 122-127 randomly selected by this current TARP terminal. TARP packet 140 can be forwarded. As a result, each TARP packet 140 is routed through the minimum number of hops of randomly selected TARP routers 122-127. [0027]

Therefore, each TARP packet randomly travels between several geographically distinct routers before arriving at the destination, regardless of the traditional factors that determine traffic within the Internet. Since it is determined independently and randomly as described above, it is very likely that it will be different for each packet that makes up a given message. This function is called azil routing. For reasons that will soon become apparent, different packets take different paths, making it difficult for an intruder to get all the packets that make up the entire multi-packet message. Azil routing is combined with other features that facilitate this purpose: allowing any message to be split into multiple packets. [0028]

The TARP router has the IP address used by the TARP router as the IP header IP of the TARP packet._CReceive a TARP packet when it matches the IP address in. However, the IP address of the TARP router does not have to be constant. To avoid and manage intrusions, each TARP router can change its IP address independently or under the direction of another TARP terminal or TARP router. Another modifiable identifier or address is also defined. This address, called the TARP address, is known only to TARP routers and TARP terminals and can be correlated at any time by the TARP router or TARP terminal using a look-up table (LUT). When the TARP router or TARP terminal changes its IP address, it updates other TARP routers or TARP terminals, and these TARP routers or TARP terminals update their respective LUTs. In fact, the TARP router must use the router's own LUT to translate the TARP address to the actual IP address whenever it references the destination address in the encrypted header. [0029]

Any TARP router that receives a TARP packet can determine the final destination of the packet, but the message payload is embedded in the encrypted inner layer inside the TARP packet that cannot be unlocked without the use of a session key. The TARP routers 122 to 127 intervening between the source TARP terminal 100 and the destination TARP terminal 110 cannot use the session key. The session key can be used to decrypt the payload of TARP packet 140 and reconstruct the entire message. [0030]

In one aspect, the link key and session key can be used to keep the communication private, and the link key and session key can be shared and used according to any desired method. For example, public key method can be used to transfer a public or symmetric key between a link endpoint or a session endpoint. Any of a variety of other mechanisms that secure the data so that only authorized computers can access the private information in the TARP packet 140 can be used as needed. [0031]

As can be seen in Figure 3a, when configuring a series of TARP packets, the data stream 300, such as IP packets 207a, 207b, 207c, that is, the series of packets formed by the network (IP) layer process, is a series. Divided into smaller segments. In this example, segments 1-9 of equal size are defined and used to form a set of interleaved data packets A, B, and C. In this case, assuming that the number of interleaved packets A, B, and C formed is three, the IP packets 207a to 207c used to form the three interleaved packets A, B, and C. Assume that the number is also three. Of course, the number of IP packets deployed in the group of interleaved packets can be any convenient number as well as the number of interleaved packets in which the incoming data stream is deployed. The number of interleaved packets in which the data stream is expanded is called the interleaved window. [0032]

When creating a packet, the sending software interleaves the regular IP packet 207a with subsequent packets to form a new set of interleaved payload data 320. This payload data 320 then forms a set of session key encrypted payload data 330 using the session key, where each data A, B, and C forms the payload of the TARP packet. Encrypted by. New TARP packet IP using the IP header data of the first packet 207a ~ 207c_TIs formed. TARP packet IP_TCan be the same as a regular IP header, or can be customized in some way. In a preferred embodiment, the TARP packet IPT is an IP header containing additional data that provides the following information necessary for routing and reconstructing messages. Some of this data is usually contained in a regular IP header, or can be included in a regular IP header. 1. Window sequence number-An identifier that indicates where the packet belongs in the first message sequence. 2. Interleaved Sequence Number-An identifier that indicates the interleaved sequence used to form a packet so that it can be deinterleaved with other packets in the interleaved window. 3. Time to Live (TTL) Data-Indicates the number of TARP router hops a packet should perform before it arrives at its destination. Note that the TTL parameter can provide data to be used in the probabilistic formula to determine whether a packet should be routed to a destination or another hop. 4. Data type identifier-Indicates whether the payload should contain, for example, TCP data or UDP data. 5. Sender Address-Indicates the sender's address in the TARP network. 6. Destination Address-Indicates the address of the destination terminal in the TARP network. 7. Decoy / Real-Indicator of whether the packet contains actual message data, dummy decoy data, or a combination. [0033]

Obviously, packets entering a single interleaved window must contain only packets with a common destination. Therefore, in the example shown, it is assumed that all IP headers of IP packets 207a-207c contain the same destination address or are received by at least the same terminal so that they can be deinterleaved. Note that dummy or decoy data or packets can be added to form an interleaved window that is otherwise required by a given message size. Adding decoy or dummy data to the stream to even out the load on the network can help disable traffic analysis. Therefore, more during low traffic periods in response to time or other criteria so that the communication burst at one point in the Internet cannot be combined with the communication burst at another point to know the communication endpoint. It is desirable to give the TARP process the ability to generate decoy data for. [0034]

Dummy data allows the data to be split into more unobtrusive sized packets to increase the size of the interleaved window, while at the same time helping to maintain a reasonable size for each packet. (The packet size can be a single standard size, or you can choose from a range of sizes.) One main reason why it is desirable to split each message into multiple packets is before interleaving. This is apparent when the first layer of encryption is formed using a chain block cipher. A single block cipher can be applied to part or all of the message, and then that part or whole can be interleaved to obtain several separate packets. [0035]

As can be seen with reference to FIG. 3b, in the alternative aspect of the TARP packet configuration, a series of IP packets are accumulated to form a predetermined interleaved window. A single block 520 for chain block ciphers is constructed using the payload of the packet and the session key. It is assumed that the payload used to form the block is destined for the same terminal. The block size can match the interleaved window shown in the example aspect of Figure 3b. After encryption, the encrypted block is split into separate payloads and segments, which are interleaved as in the aspect of Figure 3a. The resulting interleaved packets A, B, and C are then packaged as TARP packets with TARP headers, as in the example in Figure 3a. The rest of the process is shown in Figure 3a and is as discussed with reference to Figure 3a. [0036]

After the TARP packet 340 is formed, the TARP header IP_TThe entire TARP packet 340, including, is encrypted using the link key to communicate with the first hop TARP router. The first hop TARP router is randomly selected. The final unencrypted IP header IPC is added to each encrypted TARP packet 240 to form a regular IP packet 360 that can be sent to the TARP router. Note that the process of configuring TARP packet 360 does not have to be step-by-step as described above. The above description is only a useful heuristic for describing the final product, the TARP packet. [0037]

Note that the TARP packet IPT can have a complete custom header configuration that is quite different from the regular IP header, except that it contains the information identified above. This is because this header is only interpreted by the TARP router. [0038]

The above method can be fully implemented by a process operating between the data link layer and the network layer of each server or terminal participating in the TARP system. As can be seen with reference to FIG. 4, the TARP transceiver 405 may be a source terminal 100, a destination terminal 110, or TARP routers 122 to 127. At each TARP transceiver 405, a sender process is generated that receives regular packets from the network (IP) layer and produces TARP packets that can be transmitted over the network. A receiving process is created that receives a regular IP packet, including a TARP packet, and produces a regular IP packet that is "passed" to the network (IP) layer. If the TARP transceiver 405 is a router, the received TARP packet 140 is authenticated as a suitable TARP packet and then only passed to another TARP router or TARP destination terminal 110 as a stream of IP packet 415. Note that it is not processed. The intervening process, the "TARP layer" 420, can be combined with the data link layer 430 or network layer 410. In either case, this process receives legitimate IP packets, including embedded TARP packets, and intervenes in data link layer 430 to "pass" a series of reassembled IP packets to network layer 410. .. As an example of combining TARP layer 420 with data link layer 430, programmatically, a communication card, such as Ethernet (registered trader) Mark) -The normal process of executing a card can be extended. Alternatively, TA The RP layer process is a loaded network layer of dynamically loadable modules. And form the part that is performed to support communication between the data link layer be able to. [0039]

Since the encryption system described above can be inserted between the data link layer and the network layer, the process used to support encrypted communication should be a process above the IP (network) layer. On the other hand, it may be completely transparent. The TARP process may also be completely transparent to the data link layer. Therefore, neither the operation above the network layer nor the operation below the data link layer is affected by inserting the TARP stack. This greatly increases the difficulty of unauthorized access to the network layer (for example, by hackers), thus providing additional security for all processes above the network layer. Even for newly developed servers running at the session layer, all processes below the session layer can be compromised. Note that security is distributed in this architecture. That is, for example, a notebook computer used by a mobile manager can communicate over the Internet without compromising security. [0040]

IP address changes by TARP terminals and TARP routers can be done at regular or random intervals, or when an "intrusion" is detected. Changing the IP address suppresses traffic analysis, which allows you to know which computer is communicating, and also provides some protection against intrusion. The degree of protection against intrusion is approximately proportional to the rate at which the host's IP address changes. [0041]

As mentioned above, the IP address can be changed in response to an intrusion. For example, an intrusion can be detected by a series of messages that were an organization indicating that a router is being investigated in a certain way. When an intrusion is detected, the TARP tier process can respond to this event by changing its IP address. To do this, the TARP process constructs a TARP-formatted message, for example, in the form of Internet Control Message Protocol (ICMP) datagrams. This message contains the TARP address of the machine, the previous IP address of the machine, and the new IP address of the machine. The TARP layer sends this packet to at least one known TARP router, which receives the message, validates it, and then LUTs the router itself with the new IP address of the TARP address mentioned above. Update. The TARP router then creates a similar message and broadcasts this message to those TARP routers so that other TARP routers can update the LUT. This update process should be relatively fast, as the total number of TARP routers on a given subnet is expected to be relatively small. However, this process may not work well with a relatively small number of TARP routers and / or a relatively large number of clients. For this reason, this architecture has been modified to provide scaling. This improvement yielded the second aspect described below. [0042]

The TARP process can also create subprocesses that maintain the initial IP address and continue to interact with the intruder when an intrusion is detected. This dialogue gives you the opportunity to track down the intruder or study the method of the intruder (inside the fishbowl, which "thinks" of the fishbowl as the sea, but is actually caught and observed. It's called "fish bowling", likened to a small fish in the sea). The history of communications between an intruder and an abandoned (fish-bowled) IP address can be recorded or transmitted for human analysis, or can be further synthesized to respond in some way. [0043]

As mentioned above, the TARP terminal or TARP router can add decoys or dummy data or packets to the outgoing data. Such decoy packets not only favorably distribute the data into more separate packets, but also even out the additions on the inactive part of the internet to help nullify traffic analysis attempts. You can also. [0044]

Decoy packets can be generated by each TARP terminal 100, 110 or each router 122-127 according to certain criteria determined by the algorithm. For example, the algorithm may be a random algorithm that requires random packets to be generated when the terminal is idle. Alternatively, the algorithm can generate more decoy packets at low traffic in response to detection of time or low traffic. Note that packets are preferably generated as a group of sizes that simulate the actual message, rather than being generated one at a time. Also, the background loop may have a latch that increases the likelihood of inserting a decoy packet when the message stream is being received so that the decoy packet can be inserted into a regular TARP message stream. it can. That is, when a series of messages are received, the decoy packet generation rate can be increased. Alternatively, if a large number of decoy packets are received along with legitimate TARP packets, the algorithm can increase the rate at which these decoy packets are removed rather than forwarded. When decoy packets are removed and generated in this way, the apparent incoming message size is different from the apparent outgoing message size, and traffic analysis can be disabled. Whether it is a decoy packet or another packet, the packet reception rate can be shown to the decoy packet removal process and the decoy packet generation process through the perishable decoy legitimate packet counter. (Perishable counters respond to time to contain large values when rapidly and continuously incremented, and small values when incremented slowly or rapidly and continuously a small number of times. It is a counter that resets or decrements the value.) The destination TARP terminal 110 simply roots the packet. [0045]

As can be seen in FIG. 5, the following specific steps can be used in the above-mentioned method of routing TARP packets. -A background loop operation that applies the algorithm that determines the generation of S0 decoy IP packets is executed. This loop is interrupted when an encrypted TARP packet is received. -S2 TARP packets can be inspected and authenticated in some way before attempting to decrypt them using the link key. That is, the router can ensure that the packet is a genuine TARP packet by performing the selected action on some data contained with the plaintext IP header attached to the encrypted TARP packet contained in the payload. It can be determined. This makes it possible to avoid performing decryption on packets that are not genuine TARP packets. The S3 TARP packet is decrypted, revealing the destination TARP address and whether this packet is a decoy packet or part of the actual message. S4 If this packet is a decoy packet, the perishable decoy counter is incremented. The S5 router can choose to discard the decoy packet, if it is a decoy packet, based on the decoy generation / removal algorithm and the perishable decoy counter value. If the received packet is a decoy packet and it is determined that it should be discarded (S6), control returns to step S0. -The TTL parameter of the S7 TARP header is decremented to determine if the TTL parameter is greater than zero. If the S8 TTL parameter is greater than zero, a TARP address is randomly selected from the list of TARP addresses maintained by the router, and the link key and IP address corresponding to this TARP address is the new one containing this TARP packet. It is stored so that it can be used when creating an IP packet. If the S9 TTL parameter is less than or equal to zero, the link key and IP address corresponding to the destination TARP address is stored for use when creating a new IP packet containing this TARP packet. -S10 TARP packet is encrypted using the stored link key. -S11 An IP header is added to the packet containing the stored IP address, the encrypted TARP packet is covered with the IP header, and the completed packet is sent to the next hop or destination. [0046]

As can be seen with reference to FIG. 6, the following specific steps can be used in the above method of generating TARP packets. -S20 background loop operation applies an algorithm that determines the generation of decoy IP packets. This loop is interrupted when a data stream containing IP packets is received for later transmission. -S21 Received IP packets are grouped as a set of messages having a fixed IP destination address. This set is further divided to match the maximum size of the interleaved window. The set is encrypted and interleaved to give a set of payloads that will be TARP packets. -The TARP address corresponding to the S22 IP address is determined from the reference table and stored to generate the TARP header. The initial TTL count is generated and stored in the header. The TTL count can be a random value with a minimum and maximum value, a constant value, or can be determined by some other parameter. S23 The window sequence number and interleaved sequence are recorded in the TARP header of each packet. S24 One TARP router address is randomly selected for each TARP packet and the IP address corresponding to this address is stored for use in the plaintext IP header. The link key corresponding to this router is identified, and TARP packets containing interleaved and encrypted data and TARP headers are encrypted using this link key. S25 A plaintext IP header with the actual IP address of the first hop router is generated and attached to each of the encrypted TARP packets and the resulting packet. [0047]

As can be seen with reference to FIG. 7, the following specific steps can be used in the above-mentioned way of receiving TARP packets. -A background loop operation that applies the algorithm that determines the generation of S40 decoy IP packets is executed. This loop is interrupted when an encrypted TARP packet is received. The S42 TARP packet is examined and authenticated before it is decrypted using the link key. The S43 TARP packet is decrypted with the appropriate link key, revealing the destination TARP address and whether this packet is a decoy packet or part of the actual message. S44 If this packet is a decoy packet, the perishable decoy counter is incremented. The S45 receiver may choose to discard the packet, if it is a decoy packet, based on the decoy generation / removal algorithm and the perishable decoy counter value. -The TARP packet is cached until all the packets that form the S46 interleaved window are received. S47 After all the packets in the interleaving window have been received, the packets are deinterleaved. S48 Then, the packet block of each combined packet forming the interleaved window is decrypted using the session key. · S49 Then the decrypted block is split using window sequence data and IP_rIP with normal header_CIt is changed to the header. Window sequence number is IP_CIncluded in the header. S50 Then the packet is passed to the IP layer process. [0048]

Increased scaling potential The IP agility feature described above depends on the ability to send IP address changes to all TARP routers. Each aspect that includes this feature is referred to as a "boutique" aspect because of the potential limitations in scaling such features for large networks such as the Internet. (But the boutique aspect is robust when used on a small network, for example a small virtual private network). One problem with the boutique aspect is that if IP address changes occur frequently, the number of TARP routers and / or clients is very high due to the message traffic needed to update all routers fast enough. If the number increases, a large load will be applied to the Internet. The bandwidth load used to update all TARP routers, for example the bandwidth load applied to the network in ICMP packets, exceeds the capacity of the internet for large implementations close to the scale of the internet. there is a possibility. In other words, the scaling potential of boutique systems is limited. [0049]

A system can be configured that trades some of the features of the above embodiments to provide the benefits of IP agility without additional message load. This is done by IP address hopping according to a shared algorithm that manages IP addresses used between links participating in communication sessions between nodes, such as TARP nodes. (Note that the IP hopping technique can also be applied to boutique aspects.) The IP agility features discussed for boutique systems are distributed under this scalable method and managed by the shared algorithm described above. Can be modified as follows. Other features of the boutique system can be combined with this new kind of IP agility r. [0050]

This new aspect has the advantage of providing local algorithms exchanged by each pair of nodes communicating and IP agility managed by a set of IP addresses. This local management is session independent in that it can manage communication between node pairs, regardless of the session or endpoint transferred between the node pairs that communicate directly. [0051]

In this scalable aspect, a block of IP addresses is assigned to each node in the network. (This scaling potential increases in the future when Internet Protocol addresses increase to 128-bit fields and the number of clearly addressable nodes increases significantly). Therefore, each node can communicate with other nodes in the network using any of the IP addresses assigned to that node. In practice, each node pair that communicates can communicate with each other using multiple source and destination IP addresses. [0052]

Each communicating node pair in the chain participating in any session has two IP address blocks called net blocks, an algorithm, and the next source / source used to send the next message. Stores a randomized seed for selecting a destination IP address pair for each net block. In other words, this algorithm manages the sequential selection of IP address pairs from each netblock, one sender IP address, and one receiver IP address. The combination of algorithm, seed, and net block (IP address block) is called "hop block". The router issues separate send and receive hop blocks to the router's clients. The transmit and receive addresses in the IP header of each outgoing packet sent by the client are filled with the transmit and receive IP addresses managed by the algorithm. The algorithm is "clocked" (indexed) by the counter each time a pair is used so that the algorithm creates a new transmit pair for the next packet to be transmitted. [0053]

The router's receive hop block is the same as the client's send hop block. The router uses the receive hop block to predict what the outbound IP address / inbound IP address pair will be for the next expected packet from this client. Since each packet may not be received in order, it is not possible for the router to reliably predict what IP address will come on the next sequential packet. The router takes this issue into account and produces a range of predictions that include the number of outgoing packet sending / receiving addresses that may follow the next packet received. Therefore, if a given packet is very unlikely to arrive at the router before the five packets previously sent by the client, the router should compare to the next packet received. Six transmit / receive IP address pairs (or "hop windows") can be generated. When a packet is received, it is marked in the hop window as received, so a second packet with the same IP address pair is dropped. If an out-of-sequence packet does not arrive within a given timeout period, it may be required to be retransmitted, or simply received, depending on the protocol used for the communication session and, in some cases, by convention. Can be discarded from the table. [0054]

When the router receives the client's packet, it compares the packet's outgoing and incoming IP addresses with the next N expected outgoing IP address receiving address pairs, and if the packet is not a member of this set, Reject the packet. Incoming packets that do not have the expected source / destination IP address that fits in the window are rejected, thus blocking possible hackers. (With the number of possible combinations, it is difficult to randomly fit a fairly large window into it.) If the packet is a member of this set, the router accepts the packet and further processes it. To do. This link-based IP hopping scheme, called "IHOP", is a network element that is independent and does not necessarily involve the elements of the boutique system described above. When the routing agility feature described for the boutique aspect is combined with this link-based IP hopping scheme, the next step in the router is to decrypt the TARP header to determine the destination TARP router for the packet, and the next step in the packet. It is to determine what the hop should be. The TARP router then forwards the packet to a random TARP router or to the destination TARP router where the destination router establishes link-based IP hopping communication. [0055]

Figure 8 shows how client computer 801 and TARP router 811 should establish a secure session. Client 801 sends a "safe synchronization" request ("SSYN") packet 821 to TARP router 811 when establishing a HOP session with TARP router 811. This SYN packet 821 contains the authentication token of client 811 and can be sent to router 811 in encrypted format. The destination IP number and destination IP number on packet 821 are the current static IP address of client 801 and the "known" static IP address of router 811. (For security reasons, it is desirable to reject any packet from outside the local network whose destination is a known static IP address of the router.) Router 811 receives SSYN packet 821 of client 801 and receives SSYN packet 821 of client 801. After verifying the validity, it responds by sending an encrypted "safe synchronization acknowledgment" ("SSYN ACK") 822 to the client 801. This SSYN The ACK822 includes a transmit hop block and a receive hop block that the client 801 uses when communicating with the TARP router 811. Client 801 acknowledges and responds with response packet 822 of TARP router 811 by generating an encrypted SSYN ACK ACK packet 823 sent from that static IP address to a known fixed IP address of TARP router 811. Client 801 simultaneously generates SSYN ACK ACK packets. This SSYN ACK packet, called the Safe Session Initialization (SSI) packet 824, is in the client's transmit table 921 (Figure 9), which is specified in the transmit hop block given by the TARP router 811 in the SSYN ACK packet 822. Sent with the first {sender, receiver} IP pair. The TARP router 811 is an SSI transmitted with the first {sender, receiver} IP pair in the TARP router's transmit table 923. Respond to SSI packet 824 with ACK packet 825. After these packets are successfully exchanged, a secure communication session is established and all other secure communications between the client 801 and the TARP router 811 will continue this secure session as long as they remain in sync. It is done through. If synchronization is lost, client 801 and TARP router 802 can reestablish a secure session by the procedure outlined in Figure 8 and described above. [0056]

When a secure session is active, both client 901 and TARP router 911 (Figure 9) maintain the transmit tables 921, 923 and receive tables 922, 924 given by the TARP router during session synchronization 822, respectively. It is important that the sequence of IP pairs in the client send table 921 is the same as the sequence of IP pairs in the TARP router receive table 924. Similarly, the sequence of IP pairs in the client receive table 922 must be the same as the sequence of IP pairs in the router send table 923. This is necessary to maintain session synchronization. Client 701 needs to maintain only one outbound table 921 and one inbound table 922 during a secure session. Each sequential packet sent by client 901 uses the next {sender, receiver} IP address pair in the transmit table, whether it is a TCP session or a UDP session. The TARP router 911 expects that each packet arriving from client 911 holds the next IP address shown in the receive table. [0057]

However, packets may not arrive in order, so the router can maintain a "look ahead" buffer in the receive table, making IP pairs that have already been received as invalid IP pairs for future packets. Mark. Future packets that are in the IP look ahead buffer but contain IP pairs that are marked as received IP pairs are dropped. Communication from TARP router 911 to client 901 is maintained as well. In particular, Router 911 selects the next IP address pair from Router 911's transmit table 923 when configuring a packet to send to Client 901, and Client 901 chooses the expected IP on the packet it receives. Maintain a pair of look-ahead buffers. Each TARP router maintains a separate transmit table / receive table pair for each client that has a secure session with the TARP router or has a secure session through the TARP router. [0058] [0058]

The client receives the client's hop block that links it to the Internet from the first server, while the router exchanges the hop block. When a router establishes a link-based IP hopping communication method with other routers, each pair exchange router exchanges its transmit hop block. The transmit hop block of each router becomes the receive hop block of the other router. Communication between routers is managed as described in the example where the client sends a packet to the first router. [0059]

The above method works well in an IP environment, but many local networks connected to the Internet are Ethernet systems. Ethernet requires the use of known processes ("address decomposition protocol" and "reverse address decomposition protocol") to translate the IP address of the called party into a hardware address, and vice versa. .. However, when using the link-based IP hopping method, the correlation process becomes cumbersome. An alternative to the link-based IP hopping method can be used within an Ethernet network. The solution is to allow nodes that link the Internet to Ethernet (called border nodes) to communicate with nodes outside the Ethernet LAN using a link-based IP hopping method. Within the Ethernet LAN, each TARP node has a single IP address that is traditionally addressed. The TARP node in the LAN uses a single IP header extension field to authenticate the packet, rather than comparing the {sender, receiver} IP address pairs to authenticate the packet. Therefore, the border node uses the algorithm shared by the TARP node in the LAN to generate the symbol stored in the empty field in the IP header, and the TARP node in the LAN is from this particular source IP address. Generates a range of symbols based on the node's own expectations for the next packet expected to be received. A packet is rejected if it does not fit within the expected set of symbols (for example, a number) and accepted if it fits. Communication from the TARP node in the LAN to the border node is performed in the same way. However, for security reasons, the algorithms are necessarily different. Therefore, each communication node generates a transmission table and a reception table as in FIG. That is, the sending table of the TARP node in the LAN is the same as the receiving table of the border node, and it is in the LAN. [0060]

The algorithm used for IP address hopping can be any desired algorithm. For example, the algorithm may be a pseudo-random number generator that generates numbers in a range that covers an allowed IP address with a given seed. Alternatively, session participants can assume certain algorithms and simply specify the parameters to apply them. For example, the hypothesized algorithm may be a particular pseudo-random number generator, where session participants can simply exchange seed values. [0061]

Note that there is no permanent physical difference between the source terminal node and the destination terminal node. Any device at any endpoint can initiate pair synchronization. Also note that authentication / synchronization requests (and acknowledgments) and hop block exchanges can all be performed by a single message so that separate message exchanges are not required. [0062]

As another extension of the architecture described above, multiple physical paths can be used by the client to provide link redundancy and also prevent attempts to deny services and traffic monitoring. As shown in Figure 10, for example, client 1001 can establish three simultaneous sessions with each of the three TARP routers given by different ISPs 1011, 1012, 1013. As an example, client 1001 can connect to an ISP using three different telephone lines 1021, 1022, 1023, two telephone lines and a cable modem, and so on. In this method, the packets to be transmitted are randomly transmitted between various physical paths. This architecture provides a high degree of communication redundancy and provides improved protection against denial of service attacks and traffic monitoring. [0063]

Other extended aspects Various extensions of the techniques, systems, and methods described above will be described below. As mentioned above, the security of communication between computers within a computer network (Internet, Ethernet, etc.) is the apparently random source Internet Protocol (IP) of data packets sent over the network. ) Can be improved by using the address and destination IP address. This feature prevents an eavesdropper from determining which computer in the network is communicating, while at the same time two communicating computers are receiving a given data packet with a legitimate packet. Make it easy to recognize whether or not there is one. In one aspect of the system described above, the IP header extension field is used to authenticate incoming packets over Ethernet. [0064]

Various extensions of the aforementioned techniques described herein include (1) using the hopped hardware or "MAC" address in a broadcast network, and (2) having the computer synchronize with the sender. Self-synchronization techniques that allow automatic recovery, (3) synchronization algorithms that allow sender and receiver computers to quickly reestablish synchronization in the event of packet loss events or other events, and (4) It includes a fast packet rejection mechanism that rejects invalid packets. Any or all of these extensions can be combined with the features described above in any of a variety of ways. [0065]

A. Hardware address hopping Internet Protocol-based communication techniques on a LAN or Internet Protocol-based communication techniques over any dedicated physical medium typically embed IP packets within lower-level packets, often referred to as "frames." As shown in Figure 11, for example, the first Ethernet frame 1150 has a frame header 1101 and two embedded IP packets IP1 and IP2, whereas the second Ethernet frame 1160 has a different frame. It has a header 1104 and a single IP packet IP3. Each frame header generally contains source hardware address 1101A and destination hardware address 1101B. In FIG. 11, other known fields in the frame header are omitted for clarity. Two hardware nodes communicating over a physical communication channel insert appropriate source and destination hardware addresses that indicate which node on the channel or network should receive the frame. [0066]

A malicious eavesdropper can obtain information about the contents of a frame and / or the communicator of that frame by examining the frame on the local network (or in addition to it) rather than the IP packet itself. This is especially true for broadcast media such as Ethernet, where the hardware address of the machine that generated the frame and the hardware address of the machine to which the frame is sent must be inserted in the frame header. All nodes on the network can optionally see all packets sent over the network. This can be a problem for secure communications, especially if the communicator does not want a third party to be able to identify who is exchanging information. One way to deal with this problem is to extend the address hopping method to the hardware layer. According to various aspects of the invention, the hardware address is "hopped" in a manner similar to the method used to change the IP address, thus the eavesdropper generated a particular message. Cannot determine which hardware node it is, or which node the intended receiver is. [0067]

Figure 12A shows a system in which medium access control (MAC) hardware addresses are hopped to improve security on networks such as Ethernet. Although this description cites an exemplary case of an Ethernet environment, the principles of the invention can be applied to other types of communication media as well. For Ethernet, the sending and receiving MAC addresses are inserted into an Ethernet frame and visible to anyone on the LAN within the broadcast range of that frame. In order to realize secure communication, it is desirable to generate a frame having a MAC address that does not belong to a specific transmitting side or receiving side. [0068]

As shown in Figure 12A, computer nodes 1201 and 1202 communicate over a communication channel such as Isanet. Each node runs one or more application programs 1203 and 1218 that communicate by sending packets with communication software 1204 and 1217, respectively. Examples of application programs include video conferencing, email, document processing programs, and so on. Communication software 1204 and 1217 can include, for example, an OSI layered architecture or "stack" that standardizes different services realized at different functional levels. [0069]

The lowest levels of communication software 1204 and 1217 communicate with hardware components 1206 and 1214, respectively, and each component allows one or more registers to reconfigure or control the hardware according to various communication protocols. It can include 1207 and 1215. Hardware components (eg, Ethernet network interface cards) communicate with each other via a communication medium. Each hardware component is typically pre-assigned with a fixed hardware address or MAC number that identifies the hardware component to other nodes on the network. As detailed below, various aspects of the principles of the invention are one or more algorithms that track a range of valid addresses to validate received packets. Allows "hopping" of various addresses using multiple moving windows. Packets transmitted according to one or more principles of the invention are generally "safe" packets to distinguish them from regular data packets sent in clear text using machine-correlated regular addresses. Or called "secure communication". [0070]

One simple way to generate an unattributable MAC address is an extension of the IP hopping method. In this case, the two machines on the same LAN communicate securely, exchanging random number generators and seeds, and creating a sequence of quasi-random MAC addresses for synchronous hopping. In this case, the implementation and synchronization issues are similar to the same IP hopping issue. [0071]

However, this technique can use the currently active MAC address on the LAN, which can disrupt communication between these machines. Since Ethernet MAC addresses are currently 48 bits in length, it is actually extremely unlikely that an active MAC address will be abused at random. However, this number includes a large number of nodes (as seen in a wide range of LANs), a large number of frames (as in the case of packet voice or streaming video), and a large number of parallel virtual private networks (VPNs). When multiplied by the number of, the possibility of using the MAC address of an insecure machine in the address hopping frame is not negligible. Simply put, any method that has the potential to disrupt communication on other machines on the LAN is opposed by a visionary system administrator. Nevertheless, this is technically feasible and can be safely done on a LAN with a small number of machines, or if all machines on the LAN have MAC hop communication. be able to. [0072]

Synchronous MAC address hopping can involve some overhead when establishing a session, especially if there are multiple sessions or nodes involved in the communication. An easier way to randomize the MAC address is to allow each node to receive and process any frame that occurs on the network. Typically, each network interface driver checks the destination MAC address in the header of every frame that occurs to see if it matches the machine's MAC address. If they do not match, this frame is discarded. However, in one aspect, these checks can be overridden and any packets generated are passed to the TARP stack for processing. This is called "promise cure" mode because every frame that occurs is processed. Promiscuous mode ensures that the destination machine can process the frame, allowing the sender to use a completely random MAC address that is out of sync. The TARP stack handles the determination of whether a packet is destined for that machine, and the TARP stack checks to see if the source and destination IP addresses match in the TARP stack's IP synchronization table. .. If no match is found, this packet is dropped. If there is a match, the packet is released and the inner header is evaluated. If the inner header indicates that the packet is destined for this machine, the packet is pushed onto the IP stack, otherwise the packet is dropped. [0073]

One drawback of purely random MAC address hopping is the effect of this hopping on processing overhead. That is, the machine's CPU is used much more often than if the network interface driver unilaterally discriminates and rejects packets because it must handle every frame that occurs. As a compromise, a single fixed MAC address or a small number of MAC addresses (for example, each virtual private network on Ethernet) should be used for MAC hop communication, regardless of the actual recipient to which the message is destined. There is a method to select one MAC address for each). In this mode, the network interface can inspect each frame that occurs against one (or a few) pre-established MAC addresses, which allows the CPU to make no distinction between physical layer packets. I'm done. With this method, important information is not leaked to intruders on the LAN. In particular, any secure packet can be pre-identified by the unique packet type in the outer header. However, because all machines that communicate securely either use the same MAC address or choose from a small set of given MAC addresses, the association between a particular machine and a particular MAC address is effectively lost. Will be. [0074]

With this method, the CPU cannot communicate securely (or) because the network interface driver cannot always unilaterally distinguish between secure packets destined for this machine and secure packets from other VPNs. Used more often than in the case of synchronous MAC address hopping). However, it is easy to eliminate unsafe traffic on network interfaces, thus reducing the amount of processing required by the CPU. If there are boundary conditions where these do not apply, for example, if all traffic on the LAN is safe, the CPU will be used as much as purely random address hopping. Alternatively, if each VPN on the LAN uses a different MAC address, the network interface can completely distinguish secure frames destined for the local machine from the secure frames that make up other VPNs. it can. These are technical trade-offs and can be best handled by giving management options when the user installs the software and / or establishes a VPN. [0075]

However, even in this case, there is still a small possibility that the MAC address used by one or more nodes on the LAN will be selected. One solution to this problem is to officially assign one address or a range of addresses used in MAC hop communication. This is typically done through an assignment number registration authority, for example, in the case of Ethernet, the Institute of Electrical and Electronics Engineers (IEEE) has assigned a MAC address range to the vendor. The officially assigned address range ensures that secure frames fit into properly configured and properly functioning machines on the LAN. [0076]

Next, reference is made to FIGS. 12A and 12B to illustrate a number of combinations and features according to the principles of the invention. As mentioned above, assume that the two computer nodes 1201 and 1202 are communicating over a network or communication medium such as Ethernet. The communication protocols of each node (1204 and 1217, respectively) include modified elements 1205 and 1216 that perform certain functions derived from standard communication protocols. In particular, computer node 1201 has an apparently random source and destination IP address (and, in one aspect, an apparently random IP header disk) to send each packet to the other computer node. Perform the first "hop" algorithm 1208X to select the riminator field). For example, node 1201 maintains an outbound table 1208 that contains a triad of destination (S), destination (D), and discriminator fields (DS) that are inserted in the outgoing IP packet header. This table is generated by using the appropriate algorithm known to the receiving node 1202 (eg, a random number generator seeded with the appropriate seeds). As each new IP packet is formed, the sender's sending table 1208 sequential entries are used to fill in the IP source, IP destination, and IP header extension fields (for example, the discriminator field). It will be appreciated that the send table does not need to be pre-created, but instead can be created by running an algorithm during operation as it forms each packet. [0077]

On the receiving node 1202, the same IP hop algorithm 1222X is maintained, and the above algorithm is added to the receiving table 1222, which lists the valid triplets of source IP address, destination IP address, and discriminator field. Used to generate using. This is indicated by the fact that the first five entries in transmit table 1208 match the second five entries in receive table 1222. (Each table can be slightly off at any particular time due to packet loss, out-of-order packets, or transmission delays). Node 1202 also maintains a receive window W3 that represents a list of valid IP sources, IP destinations, and discriminator fields that are accepted when received as part of an incoming IP packet. When a packet is received, window W3 slides down the list of valid entries, so the possible valid entries change over time. Two packets that arrive in the wrong order but nevertheless match the entry in window W3 are accepted. Packets that do not fit in window W3 are rejected as invalid packets. The length of window W3 can be adjusted as needed to reflect network delay or other factors. [0078]

Node 1202 maintains a similar outbound table 1221 to create IP packets and frames destined for node 1201 using a different hopping algorithm 1221X, and node 1201 uses the same algorithm 1209X. And maintain a matching receive table 1209. When node 1202 sends a packet to node 1201 using an apparently random IP destination, IP destination, and / or discriminator field, node 1201 puts the incoming packet value into node 1201's receive table. Match the value that fits within the maintained window W1. In practice, the transmit table 1208 on node 1201 and the receive table 1222 on the receiving node 1202 are synchronized (ie, the entries are selected in the same order). Similarly, the transmit table 1221 on node 1202 and the receive table 1209 on node 1201 are synchronized. Figure 12A shows a common algorithm for the source, destination, and discriminator fields (for example, using different seeds for each of the three fields), but in reality it uses a completely different algorithm. It will be understood that the values of each of these fields can be established. It will also be appreciated that one or two fields can be "hopped" instead of all three fields as shown. [0079]

According to another aspect of the invention, in order to improve security within a local area network or broadcast network, a hardware address or "instead of or with the IP address and / or discriminator field". The "MAC" address is hopped. For this purpose, node 1201 has a source hardware address and a source hardware address that is inserted into the frame header (for example, fields 1101A and 1101B in Figure 11) that is synchronized with the corresponding receive table 1224 at node 1202. Further maintains the outbound table 1210, which generates the destination hardware address using the outbound algorithm 1210X. Similarly, node 1202 maintains a different outbound table 1223 containing source and destination hardware addresses that are synchronized with the corresponding inbound table 1211 on node 1201. In this way, outgoing hardware frames originate from completely random nodes on the network, even though each receiver can determine if a given packet is destined for the receiver. And it looks like it will be sent to such a node. It will be appreciated that the hardware hopping feature can be performed at a different communication protocol level than the IP hopping feature (for example, with the card driver or the hardware card itself to improve performance). [0080] [0080]

FIG. 12B shows three different aspects or modes that can be used using the principles described above. In the first mode, called "promise cure" mode, there is no hardware address common to all nodes on the network (for example, a fixed address for the source and another fixed address for the destination) or completely none. An artificial hardware address is used, thus making it impossible to attribute a particular packet to a single node. Each node initially accepts all packets containing a common (or random) hardware address and examines the IP address or discriminator field to determine if the packet is destined for that node. There must be. Note that the IP address and / or discriminator field can be changed according to the algorithm described above. As mentioned earlier, this increases the overhead of each node by requiring additional processing to determine if a given packet has a valid source and destination hardware address. there's a possibility that. [0081]

A second mode, called "Promise Cures Per VPN" mode, uses a small set of fixed hardware addresses and is fixed to all nodes communicating over the virtual private network Source / Destination hardware. The address is used. For example, if you have 6 nodes on Ethernet and the network is split into two dedicated virtual networks so that each node on one VPN can only communicate with the other two nodes on that VPN, the first You can use two sets of hardware addresses, one for the VPN and the second for the second VPN. This reduces the amount of overhead required to inspect for valid frames, as it only needs to inspect packets arriving from the specified VPN. Again, you can hop the IP address and one or more discriminator fields as described above for secure communication within the VPN. Of course, this solution disables VPN anonymity (ie, it's easy for outsiders to know which VPN the traffic belongs to, but outsiders identify it. Cannot be correlated with machines / people). There is also a need to reduce the likelihood of some sort of DoS attack using the discriminator field. (For example, the absence of a discriminator field allows an attacker on the LAN to create a stream of frames containing the MAC address used by the VPN. Excessive to reject such frames. The discriminator field, which may require processing overhead, provides a low overhead means of rejecting pseudo-packets.) [0082]

In a third mode, called "hardware hopping" mode, the hardware address is changed, as shown in Figure 12A, which constantly changes the hardware source address and the hardware destination address, and the address is It becomes unattributable. Of course, variations of these aspects are possible and the invention is not limited in any way by these examples. [0083]

B. Address space expansion Address hopping ensures security and privacy. However, the level of protection is limited by the number of addresses in the hopped block. The hop block indicates a field that is adjusted for each packet to realize VPN. For example, if two nodes communicate using IP address hopping, where each block uses a hop block consisting of four addresses (2 bits), there are 16 possible address pair combinations. For size 16 windows, most address pairs are accepted as valid pairs most of the time. This limitation can be lifted by using the discriminator field in addition to or instead of the hop address field. Discriminator fields are hopped just like address fields and are used to determine if a packet should be processed by the receiver. [0084]

Suppose two clients, each using a 4-bit hop block, want the same level of protection given to clients communicating via IP hopping between two A blocks (effective for hopping). 24 bits). This level of protection is achieved when a 20-bit discriminator field is used with a 4-address bit that is useful for hopping in the IP address field. The 24-bit discriminator field achieves a similar level of protection if the address field is not hopped or ignored. The discriminator field has two advantages: (1) any high level of protection can be achieved, and (2) protection is achieved without address hopping. This is important in environments where address hopping causes routing problems. [0085]

C. Synchronization technique Subsequent communication between the two nodes after the sender and receiver nodes have exchanged algorithms and seeds (or similar information sufficient to generate a quasi-random source table and a quasi-random destination table). Is generally assumed to proceed smoothly. However, in reality, the two nodes can lose synchronization due to network delays or failures, or other problems. Therefore, it is desirable to provide a means of reestablishing synchronization between nodes in the network that have lost synchronization. [0086]

One possible technique is to have each node supply an acknowledgment when each packet is successfully received and retransmit the unacknowledged packet if the acknowledgment is not received within a period of time. However, this approach increases overhead costs and can become unusable in high throughput environments such as streaming video and streaming audio. [0087]

Another technique uses an automatic synchronization technique referred to herein as "self-synchronization." With this technique, synchronization information is embedded in each packet, which allows the receiver to regain its own synchronization when a single packet is received if it determines that it has lost synchronization with the sender. it can. (If communication is already in progress and the receiver determines that it is still in sync with the sender, there is no need to resynchronize.) The receiver expires, for example, after a period of time, and each Out of sync can be detected by using a "dead man" timer that is reset by a valid packet in. Hashing can time stamp public sync fields (see below) to prevent packet retry attacks. [0088]

In one aspect, a "synchronization field" is added to the header of each packet transmitted by the sender. This synchronization field may be in clear text or may be part of an encrypted portion of the packet. Assuming that the sender and receiver have selected a random number generator (RNG) and a seed value, this combination of RNG and seed can be used to generate a random number array (RNS). The RNS is then used to generate the source / destination IP pair (and optionally the discriminator field and the hardware source and hardware destination addresses) as described above. However, it is possible to generate the Nth random number in a sequence without generating the entire sequence (or the first N-1 values). If the sequence index N is known, a random value corresponding to this index can be generated directly (see below). Various RNGs (and seeds), each with a different base period, can be used to generate source and destination IP sequences, but the basic concept still applies. For simplicity, the discussion below assumes that IP source-destination address pairs (only) are hopped using a single RNG sequencing mechanism. [0089]

The synchronization fields in each packet header are indexed (ie, sequence numbered) by the "self-synchronization" feature to the RNS used to generate the IP pair. Indexing the RNG used to generate the RNS in this way produces a specific random number value, which in turn produces a specific IP pair. That is, the IP pair can be generated directly from the RNG, seed, and index number, and this method does not need to generate the entire sequence of random numbers that precedes the sequence value associated with the given index number. .. [0090]

Since it is assumed that the communicator has already exchanged RNG and seeds, the only new information that must be given to generate an IP pair is the sequence number. If this number is given in the packet header by the sender, the receiver can simply enter this number into the RNG to generate an IP pair, so the IP pair shown in the packet header is valid. It can be verified that there is. In this method, if the sender and receiver lose synchronization, the receiver compares the IP pair in the packet header with the IP pair generated from the index number when a single packet is received. You can get back in sync immediately with. Therefore, when a single packet is received, synchronized communication can be resumed, which makes this method ideal for multicast communication. In extreme cases, the synchronization table is completely unnecessary. That is, the sender and receiver can just use the index number in the synchronization field to validate the IP pair on each packet, thereby eliminating the table altogether. [0091]

The aforementioned method has certain inherent security issues associated with it. That is, it is a matter of arrangement of synchronization fields. If this field is placed in the outer header, an intruder can see the value of this field and the relationship between that value and the IP stream. This, in some cases, affects the algorithm used to generate the IP address sequence, thus affecting the security of the communication. However, if this value is placed in the inner header, the sender cannot extract the synchronization value and check the validity of the IP pair unless the inner header is decrypted. In this case, the receiver is exposed to some sort of denial of service (DoS) attack, such as packet playback. That is, if the receiver cannot validate the IP pair without decrypting the packet, and the attacker simply retransmits the previously valid packet, a significant amount of decryption must be performed. There is a risk of having to do it. [0092]

A possible trade-off between algorithm security and processing speed is to split the sync value between the inner header (encrypted) and the outer header (unencrypted). That is, if the sync value is long enough, it can be divided into a rapidly changing part that can be displayed in plaintext and a fixed (or very slowly changing) part that must be protected. The part that can be displayed in plain text is called the "public synchronization" part, and the part that must be protected is called the "private synchronization" part. [0093]

Both public and private syncs are required to generate full sync values. However, the private part can be chosen to be fixed or change only from time to time. Therefore, the private sync value can be stored by the receiver and can be retrieved without decoding the header. If the sender and receiver have already agreed on how often the private part of the synchronization changes, the receiver chooses if the communication gap that caused the loss of synchronization exceeds the lifetime of the previous private synchronization. A single header can be decrypted to extract a new private sync. In this case, the amount of decryption is not annoying and therefore the receiver is not exposed to a denial of service attack simply because it sometimes needs to decrypt a single header. [0094]

In this one implementation, a hash function is used with a one-to-one mapping to generate a private sync and a public sync from the sync values. This implementation is shown in Figure 13, where (for example) the first ISP1302 is the sender and the second ISP1303 is the receiver. (Other alternatives are possible in Figure 13.) The packet being sent is an unencrypted public header or "outer" header 1305 and a private header encrypted using, for example, a link key. Or with an "inner" header 1306. The outer header 1305 contains a public sync section, whereas the inner header 1306 contains a private sync section. The receiving node uses the decoding function 1307 to decode the inner header and extract the private sync. This step is only necessary when the currently buffered private sync has expired. (If the currently buffered private sync is still in effect, this private sync is simply extracted from memory and "added" (or reverse hashed) to the public sync as shown in step 1308.) Public Sync And the decrypted private synchronization part are combined by the function 1308, and the combination synchronization 1309 is generated. Combination synchronization (1309) is then sent to RNG (1310) and compared with the IP address pair (1311) to validate the packet or reject the packet. [0095]

An important point of this architecture is the concept of "future" and "past" in which public synchronization values are involved. The sync value itself should be a random value to prevent spoofing attacks, but the receiver does this sync even if the packet containing the sync value already sent is not actually received by the receiver. It is important to be able to identify the value quickly. One solution is that hashing adds a timestamp or sequence number to the public sync, so it quickly extracts, inspects, and discards this public sync, thereby validating the public sync itself. You can check. [0096]

In one aspect, the packet can be inspected by comparing the source / destination IP pair generated by the synchronization field with the pair indicated in the packet header. If (1) the pair matches, (2) the timestamp is valid, and (3) the deadman timer has expired, the synchronization will be re-synchronized. Otherwise, the packet will be rejected, if sufficient processing power is available, the deadman timer and synchronization table can be circumvented, and the receiver will simply resynchronize for every packet (eg, validate). ). [0097]

The above method may require large integer (for example, 160 bits) computations that affect its implementation. The absence of such large integer registers affects throughput and, in some cases, security in terms of denial of service. Nevertheless, as the large integer calculation processing function becomes widespread, the cost of implementing such a function will be reduced. [0098]

D. Other synchronization methods As mentioned above, if more than W consecutive packets are lost between the communication side and the receiving side in the VPN (W is the window size), the receiving side window is not updated and the sending side is , Do not send packets that are not in the receiving window. The sender and receiver will probably not regain synchronization until a random pair in the window is accidentally repeated. Therefore, it is necessary to synchronize the sender and receiver whenever possible and reestablish it whenever synchronization is lost. [0099]

The synchronization between the sender and the receiver that lost synchronization can be restored using a "checkpoint" method. This method uses checkpoint messages with random IP address pairs to convey synchronization information. In one aspect, two messages are used to convey the following synchronization information between the sender and receiver: 1.SYNC_REQ is a message used by the sender to indicate that it needs to be synchronized. 2.SYNC_ACK is a message used by the receiver to inform the sender that the receiver has been synchronized. According to a variant of this technique, both the sender and receiver maintain the following three checkpoints (see Figure 14): 1. On the sending side, ckpt_o (checkpoint old) is the IP pair used to resend the last SYNC_REQ packet to the receiving side. On the receiving side, ckpt_o (checkpoint old) is an IP pair that repeatedly receives SYNC_REQ packets from the transmitting side. 2. On the sending side, ckpt_n (checkpoint new) is the IP pair used to send the next SYNC_REQ packet to the receiving side. On the receiving side, ckpt_n ("checkpoint new") receives a new SYNC_REQ packet from the sending side, rearranges the receiving window, sets ckpt_o to ckpt_n, generates a new ckpt_n, and sets a new ckpt_r. It is an IP pair to be generated. 3. On the sending side, ckpt_r is the IP pair used to send the next SYNC_ACK packet to the receiving side. On the receiving side, ckpt_r is an IP pair that receives a new SYNC_ACK packet from the transmitting side and generates a new ckpt_n. Since SYNC_ACK is transmitted from the receiving ISP to the sending ISP, the sending ckpt_r points to the receiving ckpt_r and the receiving ckpt_r points to the sending ckpt_r (see Figure 14). When the sender starts synchronization, the IP pair used by the sender to send the next data packet is set to a predetermined value, and when the receiver first receives SYNC_REQ, the receiver window displays the next IP pair on the sender. Is updated to be central. [0100]

Synchronization can be started by a packet counter (for example, every N packets sent), by a timer (starting synchronization every S seconds), or theirs. It can also be started by a combination. See Figure 15. From the sender's point of view, this technique works as follows. (1) Each sender periodically sends a "synchronization request" message to the receiver to confirm that the receiver is in sync. (2) The receiver sends back a "synchronization confirmation" message if it is still in sync. (If this works, no further action is required). (3) If the "synchronization confirmation" is not received within a certain period, the sender sends the synchronization request again. If the sender reaches the next checkpoint without receiving a "sync confirmation" response, synchronization is lost and the sender must stop sending. The sender continues to send sync_reqs until it receives sync_ack, at which point the transmission is reestablished. [0101]

From the receiving side, this method works as follows. (1) When the receiving side receives the "synchronization request" request from the sending side, it advances the window to the next checkpoint position (in some cases, skips the pair if necessary) and sends the "synchronization response" message to the sending side. Send to. If synchronization is not lost, "jump ahead" advances to the next available address pair in the table (ie, normal forward). [0102]

If an intruder captures a "sync request" message and attempts to interfere with the communication by sending a new "sync request" message, either synchronization has been established or this message actually helps to reestablish synchronization. If, this message is ignored. [0103]

The windows are realigned whenever a resync occurs. With this realignment, the receiving window is updated to span the address pair used by the packet sent immediately after the SYNC_REQ packet was sent. Usually, the sender and the receiver are synchronized with each other. However, if a network event occurs, the receiving window may have to be advanced by a number of steps during the resynchronization. In this case, it is desirable to advance the window without having to sequentially advance between the intervening random numbers. (This feature is also desirable for the automatic synchronization techniques described above). [0104]

E. Random number generator with jump ahead function An attractive way to generate randomly hopped addresses is to use the same random number generator on the sender and receiver and proceed with this program when a packet is sent and received. There are a number of random number generation algorithms that can be used. Each algorithm has advantages and disadvantages over address hopping applications. [0105]

The Linear Random Number Generator (LCR) is a fast and simple random number generator with distinctive features that can efficiently jump n steps ahead. LCR uses the following iteration to seed X₀Random number X starting with₁, X₂, X₃, ..., X_KTo generate. X_i= (aX_i-1+ b) mod c (1) In the above equation, a, b, and c are the codes that define a particular LCR. X_iAnother formula for, i.e. X_i= ((aⁱ(X₀+ b) -b) / (a-1)) mod c (2) Enables the jump ahead function. Coefficient a_iCan be very large, even if i is small, if not constrained. Therefore, some special characteristics of modulo arithmetic can be used to adjust the size and processing time required to calculate (2). (2) can be written as the following equation. X_i= (aⁱ(X₀(a-1) + b) -b / (a-1) mod c (3) The following can be shown. (aⁱ(X₀(a-1) + b) -b) / (a-1) mod c = ((aⁱmod ((a-1) c) (X₀(a-1) + b) -b) / (a-1)) mod c (4) (X₀(a-1) + b) to (X₀(a-1) + b) Store as mod c, store b as b mod c, aⁱmod ((a-1) c) can be calculated (this requires 0 (log (i)) steps). [0106]

A practical implementation of this algorithm jumps a certain distance n between each synchronization. This corresponds to synchronization every n packets. The window starts after n IP pairs start after the previous window started. Node is X_j^wThat is, the random number at the Jth checkpoint is X₀1 degree per LCR, using n as iⁿMemorize mod ((a-1) c) and X_{j + 1}^w= X_{n (j + 1)}= ((aⁿmod ((a-1) c) (X_j^w(a-1) + b) -b) / (a-1)) mod c (5) Can be set to generate a random number for j + 1th synchronization. Nodes can use this configuration to jump any (but constant) distance ahead during each synchronization within a fixed amount of time (independent of n). [0107]

Therefore, pseudo-random number generators, especially LCRs, generally repeat the cycle. This repetition can be a weakness of the IP hopping method. That is, the intruder can predict the future sequence simply by waiting for the repetition. One way to address this weakness is to write a random number generator with a known long cycle. This sequence can be replaced with a new random number generator before the random sequence is repeated. LCRs with known long cycles can be constructed. This is not currently the case with many random number generators. [0108]

Random number generators are not cryptographically secure. An intruder can derive RNG parameters by examining the output or part of it. This applies to LCG. This weakness can be mitigated by incorporating an encryption program configured to make the output part of a random number generator. Random number generators prevent an intruder from launching an attack on a cryptographic program, such as a known plaintext attack. [0109]

F. Example of random number generator Consider RNG with a = 31, b = 4, and c = 15. In this case, formula (1) is X_i= (31X_i-1+4) mod 15 (6) become. [0110]

X₀When = 1 is set, formula (6) produces sequences 1, 5, 9, 13, 2, 6, 10, 14, 3, 7, 11, 0, 4, 8, 12. This sequence repeats infinitely. If you want to jump three numbers ahead in this sequence, aⁿ=31³= 29791, c^*(a-1) = 15 * 30 = 450, and aⁿ mod ((a-1) c) = 31³mod (15 * 30) = 29791 mod (450) = 91. Formula (5) is ((91 (X)_i30 + 4) -4) / 30) mod 15 (7) Table 1 shows the jump-ahead calculation in (7). This calculation starts at 5 and jumps 3 ahead.

[table 1]

<img file="JP2002529965A_D0001.tif" /> 【0111】

G. Fast packet filter The address hopping VPN quickly determines if a packet has a reasonable head and therefore requires further processing or has an unreasonable header (harmful packet) and should be rejected immediately. Must. Such high-speed determination is called "high-speed packet filtering". This feature protects the VPN from intruder attacks (so-called "denial of service" attacks) that quickly create a stream of harmful packets on the receiving side to saturate the receiving processor. High-speed packet filtering is an important function for implementing VPN on shared media such as Ethernet. [0112]

Assuming that all participants in the VPN share an unassigned "A" address block, one possibility is an experimental "A" that will not be assigned to a machine that is not address hopping on the shared medium. The "A" block is used. The "A" block has a 24-bit address that can be hopped as opposed to the 8-bit in the "C" block. In this case, the hop block becomes an "A" block. Experimental "A" blocks are likely to be used on Ethernet for the following reasons: 1. The address is invalid outside of Ethernet and is not routed by the gateway to a valid external destination. 2. You can hop within each "A" block 2²⁴There are (~ 16 million) addresses. This creates> 280 trillion possible address pairs, making it very unlikely that an intruder will be able to guess a valid address. Also, the likelihood of collisions between different VPNs is low enough to tolerate (all VPNs on the shared medium independently generate a random address pair from the "A" block). 3. Packets (unless the machine is in Promise Cures mode) are not received by users on Ethernet and not on VPN, minimizing impact on non-VPN computers. .. [0113]

This Ethernet example is used to illustrate one implementation of fast packet filtering. An ideal algorithm would quickly examine the packet headers to determine if the packet is harmful and either reject any harmful packets or determine which active IP pair the packet headers match. To do. The problem in this case is that of traditional associate memory. Various techniques have been developed to solve this problem (hashing, B-trees, etc.). Each of these methods has advantages and disadvantages. For example, a hash table can run very fast in a statistical sense, but in some cases it can degenerate into a much slower algorithm. This slowness may persist over a period of time. Hashing is unacceptable because malicious packets must always be dropped at high speed. [0114]

H. Existence vector algorithm The existence vector is an n-bit number (0 to 2 respectively).ⁿA 2n long bit vector that can be indexed by (range up to -1). The existence of k n-bit numbers (not necessarily unique) can be indicated by setting the bits in the existence vector indexed by each number to 1. The n-bit number x is one of the k numbers only if the xth bit of the existence vector is 1. A fast packet filter can be performed by indexing the existence vector and looking for 1. This method is called "testing". [0115]

For example, suppose you need to use an existence vector to represent number 135. The 135th bit of the vector is set. Therefore, by inspecting one bit, the 135th bit, it is possible to quickly determine whether the address 135 is valid. Existence vectors can be pre-created to correspond to table entries for IP addresses. In practice, the incoming address can be used as an index for long vectors to make comparisons very fast. As each RNG generates a new address, the existence vector is updated to reflect this information. As the window moves, the existence vector is updated to zero addresses that are no longer valid. [0116]

There is a trade-off between test efficiency and the amount of memory needed to store the existence vector. For example, if a 48-bit hopping address needs to be used as an index, the existence vector must have 35 terabytes. It is clear that this is practically too large. Instead, you can split the 48 bits into several smaller fields. For example, 48 bits can be subdivided into four 12-bit fields. This reduces the storage requirement to 2048 bytes and instead requires processing malicious packets from time to time. In reality, further processing is not allowed unless each decomposed address part, rather than one long existence vector, matches all four short existence vectors. (If the first part of the address part does not match the first existence vector, then there is no need to check the remaining three existence vectors). [0117]

The y-th bit of the existence vector is 1 only if one or more addresses whose corresponding fields are y are active. An address is active only if each existence vector indexed by the appropriate subfield of that address is 1. [0118]

Consider a window consisting of 32 active addresses and 3 checkpoints. Harmful packets are rejected by indexing one presence vector over a period of more than 99%. Harmful packets are rejected by indexing all four presence vectors over a period of time greater than 99.9999995%. On average, harmful packets are rejected with less than 1.02 presence vector indexing operations. [0119]

A small number of harmful packets that pass the fast packet filter are rejected when the matching pair is not found in the active window or is an active checkpoint. Harmful packets that unexpectedly match a header are rejected when VPN software attempts to decrypt this header. However, these cases are extremely rare. There are many other means of constructing this method so as to strike a balance between space and velocity. [0120]

I. Other synchronous extensions A slightly modified form of the synchronization technique described above can be used. The basic principle of the checkpoint synchronization method described above is the same. However, the treatment of receiving a checkpoint is slightly different. In this variant, the receiver maintains OoO ("out of order") or 2xWINDOW_SIZE + OoO active addresses. (1 OoO WINDOW_SIZE and WINDOW_SIZE 1). OoO and WINDOW_SIZE are tunable parameters, OoO is the minimum number of addresses needed to deal with lost packets due to events or out-of-order arrivals in the network, and WINDOW_SIZE is issued by SYNC_REQ. The number of packets sent before being done. FIG. 17 shows a storage array of receiving active addresses. [0121]

The receiver starts with the first 2xWINDOW_SIZE addresses that are loaded and active (ready to receive data). When the packet is received, the corresponding entry is marked "used" and the packet can no longer be received. The sender maintains a packet counter that is initially set to 0 and contains the number of data packets transmitted since the last initial transmission of the SYNC_REQ received. When the packet counter on the transmitting side becomes equal to WINDOW_SIZE, the transmitting side generates SYNC_REQ and performs the initial transmission thereof. When the receiver receives the SYNC_REQ corresponding to its current CKPT_N, it generates the next WINDOW_S address, starting at the first position after the last active address and after reaching the end of the array. Start loading these addresses in order to return to the beginning of. The array on the receiving side is as shown in FIG. 18 when SYNC_REQ is received. In this case, when SYNC_REQ is received, a few packets are lost or received in the wrong order. [0122]

Figure 19 shows the receiving array after the new address has been generated. If the sender does not receive SYNC_ACK, it reissues SYNC_REQ at regular intervals. When the sender receives SYNC_ACK, the packet counter is decremented by WINDOW_SIZE. When the packet counter reaches 2xWINDOW_SIZE-OoO, the sender stops sending data packets until it finally receives the appropriate SYNC_ACK. The sender then resumes sending the data packet. Future behavior is primarily the repetition of this initial cycle. The advantages of this method are as follows. 1. Efficient jump ahead is not required in random number generators. 2. Packets that do not have a corresponding entry on the receiving side will not be sent. 3. No timer-based resynchronization required. This is the result of 2. 4. The receiver is always capable of accepting no more than OoO sent data messages from the last sent message. [0123]

J. Distributed transmission path variant Other embodiments incorporating the various principles of the present invention are shown in FIG. In this embodiment, the message transmitting system includes a first computer 2001 that communicates with a second computer 2002 via a network of intermediate computers 2011. In one variant of this aspect, the network comprises two edge routers, each linked to multiple Internet Service Providers (ISPs) 2005-2010. Each ISP is combined with a plurality of other ISPs in the configuration shown in FIG. 20, which is only a typical configuration and is not restrictive. Each connection between ISPs is coded in Figure 20 to indicate a particular physical transmission path (for example, AD is the physical linking ISP A (element 2005) to ISP D (element 2008). Path). Packets arriving at each edge router are selectively sent to one of the ISPs to which the router is connected based on a random or semi-random selection criterion. [0124]

As shown in Figure 21, computer 2001 or Edge Router 2003 identifies a valid set of IP addresses that can be used to send a packet for each potential transmission path in the network, multiple link transmissions. Incorporates table 2100. For example, AD table 2101 contains multiple randomly or semi-randomly generated IP source / destination pairs. When sending a packet from the first computer 2001 to the second computer 2002, one link table is randomly selected (or semi-randomly) and the next valid destination / destination address in this table. Packets are sent over the network using pairs. For example, if you randomly select Path AD, then (ISP A (Element 2005) and ISP Packets are sent using the following source / destination IP address pairs (predetermined to be sent to and from B (element)): If one of the outbound paths deteriorates or becomes inoperable, the link table is set to the "down" state as shown in table 2105, and therefore an address is selected from this table. It can be prevented from being done. Other transmission paths are not affected by this corrupted link.

[Simple explanation of drawings]

[Figure 1]

It is a figure of the secure communication via the Internet by the aspect of the prior art. [Figure 2]

It is a figure of the secure communication via the Internet by the aspect of this invention. [Fig. 3a]

It is a figure of the process which forms the tunneled IP packet by the aspect of this invention. [Fig. 3b]

FIG. 5 is a diagram of a process of forming a tunneled IP packet according to another aspect of the present invention. [Fig. 4]

It is a figure of the OSI layer position of the process which can be used to carry out this invention. [Fig. 5]

It is a flowchart which shows the process of routing a tunneled packet by this invention. [Fig. 6]

It is a flowchart which shows the process of forming a tunneled packet according to the aspect of this invention. [Fig. 7]

It is a flowchart which shows the process of receiving a tunneled packet according to the aspect of this invention. [Fig. 8]

It is a diagram showing how to establish and synchronize a secure session between a client and a TARP router. [Fig. 9]

It is a figure which shows the IP address hopping method between a client computer and a TARP router using a send table and a receive table in each computer. [Fig. 10]

FIG. 5 shows physical link redundancy between three Internet Service Providers (ISPs) and client computers. [Fig. 11]

A diagram showing how to embed multiple IP packets in a single "frame", such as an Ethernet frame, and further showing how to use the discriminator field to hide the true packet receiver. Is. [Fig. 12A]

FIG. 5 shows a system that uses hopped hardware addresses, hopped IP addresses, and hopped discriminator fields. [Fig. 12B]

It is a diagram showing several different methods for hopping a combination of hardware address, IP address, and discriminator field. [Fig. 13]

FIG. 5 illustrates a technique for automatically reestablishing synchronization between a sender and a receiver by using a partially exposed sync value. [Fig. 14]

It is a figure which shows the "checkpoint" method which restores the synchronization between a transmitting side and a receiving side. [Fig. 15]

It is a figure which shows the detail of the checkpoint method of FIG. [Fig. 16]

It is a figure which shows how to decompose two addresses into a plurality of segments and compare them with existence vectors. [Fig. 17]

It is a figure which shows the storage array of the active address of the receiving side. [Fig. 18]

It is a figure which shows the storage array of the receiving side after receiving the synchronization request. [Fig. 19]

It is a figure which shows the storage array of the receiving side after a new address is generated. [Fig. 20]

It is a figure which shows the system which uses the distributed transmission path. [Fig. 21]

FIG. 5 shows a plurality of link transmission tables that can be used to route packets within the system of FIG.