text:
|Publication number
|Publication type
|Application number
|Publication date
|Nov 7, 2006
|Filing date
|Mar 31, 2003
|Priority date
|Oct 30, 1998
|Fee status
|Also published as
|Publication number
|Edmund Colby Munger, Vincent J. Sabio, Robert Dunham Short, Virgil D. Gligor, Douglas Charles Schmidt
|Original Assignee
|Science Applications International Corporation
|Export Citation
|BiBTeX, EndNote, RefMan
|Patent Citations (56), Non-Patent Citations (27), Referenced by (82), Classifications (38), Legal Events (5)
|External Links: USPTO, USPTO Assignment, Espacenet
This application is a divisional application of application Ser. No. 09/429,643, filed Oct. 29, 1999, now U.S. Pat No. 7,010,604 which claims priority from and bodily incorporates the subject matter of two previously filed provisional patent applications: Ser. No. 60/106,261, filed Oct. 30, 1998, and Ser. No. 60/137,704, filed Jun. 7, 1999.
A tremendous variety of methods have been proposed and implemented to provide security and anonymity for communications over the Internet. The variety stems, in part, from the different needs of different Internet users. A basic heuristic framework to aid in discussing these different security techniques is illustrated in
Data security is usually tackled using some form of data encryption. An encryption key 48 is known at both the originating and terminating terminals 100 and 110. The keys may be private and public at the originating and destination terminals 100 and 110, respectively or they may be symmetrical keys (the same key is used by both parties to encrypt and decrypt). Many encryption methods are known and usable in this context.
To hide traffic from a local administrator or ISP, a user can employ a local proxy server in communicating over an encrypted channel with an outside proxy such that the local administrator or ISP only sees the encrypted traffic. Proxy servers prevent destination servers from determining the identities of the originating clients. This system employs an intermediate server interposed between client and destination server. The destination server sees only the Internet Protocol (IP) address of the proxy server and not the originating client. The target server only sees the address of the outside proxy. This scheme relies on a trusted outside proxy server. Also, proxy schemes are vulnerable to traffic analysis methods of determining identities of transmitters and receivers. Another important limitation of proxy servers is that the server knows the identities of both calling and called parties. In many instances, an originating terminal, such as terminal A, would prefer to keep its identity concealed from the proxy, for example, if the proxy server is provided by an Internet service provider (ISP).
To defeat traffic analysis, a scheme called Chaum's mixes employs a proxy server that transmits and receives fixed length messages, including dummy messages. Multiple originating terminals are connected through a mix (a server) to multiple target servers. It is difficult to tell which of the originating terminals are communicating to which of the connected target servers, and the dummy messages confuse eavesdroppers' efforts to detect communicating pairs by analyzing traffic. A drawback is that there is a risk that the mix server could be compromised. One way to deal with this risk is to spread the trust among multiple mixes. If one mix is compromised, the identities of the originating and target terminals may remain concealed. This strategy requires a number of alternative mixes so that the intermediate servers interposed between the originating and target terminals are not determinable except by compromising more than one mix. The strategy wraps the message with multiple layers of encrypted addresses. The first mix in a sequence can decrypt only the outer layer of the message to reveal the next destination mix in sequence. The second mix can decrypt the message to reveal the next mix and so on. The target server receives the message and, optionally, a multi-layer encrypted payload containing return information to send data back in the same fashion. The only way to defeat such a mix scheme is to collude among mixes. If the packets are all fixed-length and intermixed with dummy packets, there is no way to do any kind of traffic analysis.
Still another anonymity technique, called 'crowds,' protects the identity of the originating terminal from the intermediate proxies by providing that originating terminals belong to groups of proxies called crowds. The crowd proxies are interposed between originating and target terminals. Each proxy through which the message is sent is randomly chosen by an upstream proxy. Each intermediate proxy can send the message either to another randomly chosen proxy in the "crowd" or to the destination. Thus, even crowd members cannot determine if a preceding proxy is the originator of the message or if it was simply passed from another proxy.
ZKS (Zero-Knowledge Systems) Anonymous IP Protocol allows users to select up to any of five different pseudonyms, while desktop software encrypts outgoing traffic and wraps it in User Datagram Protocol (UDP) packets. The first server in a 2+-hop system gets the UDP packets, strips off one layer of encryption to add another, then sends the traffic to the next server, which strips off yet another layer of encryption and adds a new one. The user is permitted to control the number of hops. At the final server, traffic is decrypted with an untraceable IP address. The technique is called onion-routing. This method can be defeated using traffic analysis. For a simple example, bursts of packets from a user during low-duty periods can reveal the identities of sender and receiver.
Firewalls attempt to protect LANs from unauthorized access and hostile exploitation or damage to computers connected to the LAN. Firewalls provide a server through which all access to the LAN must pass. Firewalls are centralized systems that require administrative overhead to maintain. They can be compromised by virtual-machine applications ("applets"). They instill a false sense of security that leads to security breaches for example by users sending sensitive information to servers outside the firewall or encouraging use of modems to sidestep the firewall security. Firewalls are not useful for distributed systems such as business travelers, extranets, small teams, etc.
A secure mechanism for communicating over the internet, including a protocol referred to as the Tunneled Agile Routing Protocol (TARP), uses a unique two-layer encryption format and special TARP routers. TARP routers are similar in function to regular IP routers. Each TARP router has one or more IP addresses and uses normal IP protocol to send IP packet messages ("packets" or "datagrams"). The IP packets exchanged between TARP terminals via TARP routers are actually encrypted packets whose true destination address is concealed except to TARP routers and servers. The normal or "clear" or "outside" IP header attached to TARP IP packets contains only the address of a next hop router or destination server. That is, instead of indicating a final destination in the destination field of the IP header, the TARP packet's IP header always points to a next-hop in a series of TARP router hops, or to the final destination. This means there is no overt indication from an intercepted TARP packet of the true destination of the TARP packet since the destination could always be next-hop TARP router as well as the final destination.
Each TARP packet's true destination is concealed behind a layer of encryption generated using a link key. The link key is the encryption key used for encrypted communication between the hops intervening between an originating TARP terminal and a destination TARP terminal. Each TARP router can remove the outer layer of encryption to reveal the destination router for each TARP packet. To identify the link key needed to decrypt the outer layer of encryption of a TARP packet, a receiving TARP or routing terminal may identify the transmitting terminal by the sender/receiver IP numbers in the cleartext IP header.
Once the outer layer of encryption is removed, the TARP router determines the final destination. Each TARP packet 140 undergoes a minimum number of hops to help foil traffic analysis. The hops may be chosen at random or by a fixed value. As a result, each TARP packet may make random trips among a number of geographically disparate routers before reaching its destination. Each trip is highly likely to be different for each packet composing a given message because each trip is independently randomly determined. This feature is called agile routing. The fact that different packets take different routes provides distinct advantages by making it difficult for an interloper to obtain all the packets forming an entire multi-packet message. The associated advantages have to do with the inner layer of encryption discussed below. Agile routing is combined with another feature that furthers this purpose; a feature that ensures that any message is broken into multiple packets.
The IP address of a TARP router may not remain constant; a feature called IP agility. Each TARP router, independently or under direction from another TARP terminal or router, may change its IP address. A separate, unchangeable identifier or address is also defined. This address, called the TARP address, is known only to TARP routers and terminals and may be correlated at any time by a TARP router or a TARP terminal using a Lookup Table (LUT). When a TARP router or terminal changes its IP address, it updates the other TARP routers and terminals which in turn update their respective LUTs.
The message payload is hidden behind an inner layer of encryption in the TARP packet that can only be unlocked using a session key. The session key is not available to any of the intervening TARP routers. The session key is used to decrypt the payloads of the TARP packets permitting the data stream to be reconstructed.
Communication may be made private using link and session keys, which in turn may be shared and used according any desired method. For example, public/private keys or symmetric keys may be used.
To transmit a data stream, a TARP originating terminal constructs a series of TARP packets from a series of IP packets generated by a network (IP) layer process. (Note that the terms "network layer," "data link layer," "application layer," etc. used in this specification correspond to the Open Systems Interconnection (OSI) network terminology.) The payloads of these packets are assembled into a block and chain-block encrypted using the session key. This assumes, of course, that all the IP packets are destined for the same TARP terminal. The block is then interleaved and the interleaved encrypted block is broken into a series of payloads, one for each TARP packet to be generated. Special TARP headers IPT are then added to each payload using the IP headers from the data stream packets. The TARP headers can be identical to normal IP headers or customized in some way. They should contain a formula or data for deinterleaving the data at the destination TARP terminal, a time-to-live (TTL) parameter to indicate the number of hops still to be executed, a data type identifier which indicates whether the payload contains, for example, TCP or UDP data, the sender's TARP address, the destination TARP address, and an indicator as to whether the packet contains real or decoy data or a formula for filtering out decoy data if decoy data is spread in some way through the TARP payload data.
Note that although chain-block encryption is discussed here with reference to the session key, any encryption method may be used. Preferably, as in chain block encryption, a method should be used that makes unauthorized decryption difficult without an entire result of the encryption process. Thus, by separating the encrypted block among multiple packets and making it difficult for an interloper to obtain access to all of such packets, the contents of the communications are provided an extra layer of security.
Decoy or dummy data can be added to a stream to help foil traffic analysis by reducing the peak-to-average network load. It may be desirable to provide the TARP process with an ability to respond to the time of day or other criteria to generate more decoy data during low traffic periods so that communication bursts at one point in the Internet cannot be tied to communication bursts at another point to reveal the communicating endpoints.
Dummy data also helps to break the data into a larger number of inconspicuously-sized packets permitting the interleave window size to be increased while maintaining a reasonable size for each packet. (The packet size can be a single standard size or selected from a fixed range of sizes.) One primary reason for desiring for each message to be broken into multiple packets is apparent if a chain block encryption scheme is used to form the first encryption layer prior to interleaving. A single block encryption may be applied to portion, or entirety, of a message, and that portion or entirety then interleaved into a number of separate packets. Considering the agile IP routing of the packets, and the attendant difficulty of reconstructing an entire sequence of packets to form a single block-encrypted message element, decoy packets can significantly increase the difficulty of reconstructing an entire data stream.
The above scheme may be implemented entirely by processes operating between the data link layer and the network layer of each server or terminal participating in the TARP system. Because the encryption system described above is insertable between the data link and network layers, the processes involved in supporting the encrypted communication may be completely transparent to processes at the IP (network) layer and above. The TARP processes may also be completely transparent to the data link layer processes as well. Thus, no operations at or above the Network layer, or at or below the data link layer, are affected by the insertion of the TARP stack. This provides additional security to all processes at or above the network layer, since the difficulty of unauthorized penetration of the network layer (by, for example, a hacker) is increased substantially. Even newly developed servers running at the session layer leave all processes below the session layer vulnerable to attack. Note that in this architecture, security is distributed. That is, notebook computers used by executives on the road, for example, can communicate over the Internet without any compromise in security.
IP address changes made by TARP terminals and routers can be done at regular intervals, at random intervals, or upon detection of "attacks." The variation of IP addresses hinders traffic analysis that might reveal which computers are communicating, and also provides a degree of immunity from attack. The level of immunity from attack is roughly proportional to the rate at which the IP address of the host is changing.
As mentioned, IP addresses may be changed in response to attacks. An attack may be revealed, for example, by a regular series of messages indicating that a router is being probed in some way. Upon detection of an attack, the TARP layer process may respond to this event by changing its IP address. In addition, it may create a subprocess that maintains the original IP address and continues interacting with the attacker in some manner.
Decoy packets may be generated by each TARP terminal on some basis determined by an algorithm. For example, the algorithm may be a random one which calls for the generation of a packet on a random basis when the terminal is idle. Alternatively, the algorithm may be responsive to time of day or detection of low traffic to generate more decoy packets during low traffic times. Note that packets are preferably generated in groups, rather than one by one, the groups being sized to simulate real messages. In addition, so that decoy packets may be inserted in normal TARP message streams, the background loop may have a latch that makes it more likely to insert decoy packets when a message stream is being received. Alternatively, if a large number of decoy packets is received along with regular TARP packets, the algorithm may increase the rate of dropping of decoy packets rather than forwarding them. The result of dropping and generating decoy packets in this way is to make the apparent incoming message size different from the apparent outgoing message size to help foil traffic analysis.
In various other embodiments of the invention, a scalable version of the system may be constructed in which a plurality of IP addresses are preassigned to each pair of communicating nodes in the network. Each pair of nodes agrees upon an algorithm for "hopping" between IP addresses (both sending and receiving), such that an eavesdropper sees apparently continuously random IP address pairs (source and destination) for packets transmitted between the pair. Overlapping or "reusable" IP addresses may be allocated to different users on the same subnet, since each node merely verifies that a particular packet includes a valid source/destination pair from the agreed-upon algorithm. Source/destination pairs are preferably not reused between any two nodes during any given end-to-end session, though limited IP block sizes or lengthy sessions might require it.
Referring to
Each TARP packet's true destination is concealed behind an outer layer of encryption generated using a link key 146. The link key 146 is the encryption key used for encrypted communication between the end points (TARP terminals or TARP routers) of a single link in the chain of hops connecting the originating TARP terminal 100 and the destination TARP terminal 110. Each TARP router 122–127, using the link key 146 it uses to communicate with the previous hop in a chain, can use the link key to reveal the true destination of a TARP packet. To identify the link key needed to decrypt the outer layer of encryption of a TARP packet, a receiving TARP or routing terminal may identify the transmitting terminal (which may indicate the link key used) by the sender field of the clear IP header. Alternatively, this identity may be hidden behind another layer of encryption in available bits in the clear IP header. Each TARP router, upon receiving a TARP message, determines if the message is a TARP message by using authentication data in the TARP packet. This could be recorded in available bytes in the TARP packet's IP header. Alternatively, TARP packets could be authenticated by attempting to decrypt using the link key 146 and determining if the results are as expected. The former may have computational advantages because it does not involve a decryption process.
Once the outer layer of decryption is completed by a TARP router 122–127, the TARP router determines the final destination. The system is preferably designed to cause each TARP packet 140 to undergo a minimum number of hops to help foil traffic analysis. The time to live counter in the IP header of the TARP message may be used to indicate a number of TARP router hops yet to be completed. Each TARP router then would decrement the counter and determine from that whether it should forward the TARP packet 140 to another TARP router 122–127 or to the destination TARP terminal 110. If the time to live counter is zero or below zero after decrementing, for an example of usage, the TARP router receiving the TARP packet 140 may forward the TARP packet 140 to the destination TARP terminal 110. If the time to live counter is above zero after decrementing, for an example of usage, the TARP router receiving the TARP packet 140 may forward the TARP packet 140 to a TARP router 122–127 that the current TARP terminal chooses at random. As a result, each TARP packet 140 is routed through some minimum number of hops of TARP routers 122–127 which are chosen at random.
Thus, each TARP packet, irrespective of the traditional factors determining traffic in the Internet, makes random trips among a number of geographically disparate routers before reaching its destination and each trip is highly likely to be different for each packet composing a given message because each trip is independently randomly determined as described above. This feature is called agile routing. For reasons that will become clear shortly, the fact that different packets take different routes provides distinct advantages by making it difficult for an interloper to obtain all the packets forming an entire multi-packet message. Agile routing is combined with another feature that furthers this purpose, a feature that ensures that any message is broken into multiple packets.
A TARP router receives a TARP packet when an IP address used by the TARP router coincides with the IP address in the TARP packet's IP header IPC. The IP address of a TARP router, however, may not remain constant. To avoid and manage attacks, each TARP router, independently or under direction from another TARP terminal or router, may change its IP address. A separate, unchangeable identifier or address is also defined. This address, called the TARP address, is known only to TARP routers and terminals and may be correlated at any time by a TARP router or a TARP terminal using a Lookup Table (LUT). When a TARP router or terminal changes its IP address, it updates the other TARP routers and terminals which in turn update their respective LUTs. In reality, whenever a TARP router looks up the address of a destination in the encrypted header, it must convert a TARP address to a real IP address using its LUT.
While every TARP router receiving a TARP packet has the ability to determine the packet's final destination, the message payload is embedded behind an inner layer of encryption in the TARP packet that can only be unlocked using a session key. The session key is not available to any of the TARP routers 122–127 intervening between the originating 100 and destination 110 TARP terminals. The session key is used to decrypt the payloads of the TARP packets 140 permitting an entire message to be reconstructed.
In one embodiment, communication may be made private using link and session keys, which in turn may be shared and used according any desired method. For example, a public key or symmetric keys may be communicated between link or session endpoints using a public key method. Any of a variety of other mechanisms for securing data to ensure that only authorized computers can have access to the private information in the TARP packets 140 may be used as desired.
Referring to
To create a packet, the transmitting software interleaves the normal IP packets 207 a et. seq. to form a new set of interleaved payload data 320. This payload data 320 is then encrypted using a session key to form a set of session-key-encrypted payload data 330, each of which, A, B, and C, will form the payload of a TARP packet. Using the IP header data, from the original packets 207 a–207 c, new TARP headers IPT are formed. The TARP headers IPT can be identical to normal IP headers or customized in some way. In a preferred embodiment, the TARP headers IPT are IP headers with added data providing the following information required for routing and reconstruction of messages, some of which data is ordinarily, or capable of being, contained in normal IP headers:
Obviously, the packets going into a single interleave window must include only packets with a common destination. Thus, it is assumed in the depicted example that the IP headers of IP packets 207 a–207 c all contain the same destination address or at least will be received by the same terminal so that they can be deinterleaved. Note that dummy or decoy data or packets can be added to form a larger interleave window than would otherwise be required by the size of a given message. Decoy or dummy data can be added to a stream to help foil traffic analysis by leveling the load on the network. Thus, it may be desirable to provide the TARP process with an ability to respond to the time of day or other criteria to generate more decoy data during low traffic periods so that communication bursts at one point in the Internet cannot be tied to communication bursts at another point to reveal the communicating endpoints.
Dummy data also helps to break the data into a larger number of inconspicuously-sized packets permitting the interleave window size to be increased while maintaining a reasonable size for each packet. (The packet size can be a single standard size or selected from a fixed range of sizes.) One primary reason for desiring for each message to be broken into multiple packets is apparent if a chain block encryption scheme is used to form the first encryption layer prior to interleaving. A single block encryption may be applied to portion, or entirety, of a message, and that portion or entirety then interleaved into a number of separate packets.
Referring to
Once the TARP packets 340 are formed, each entire TARP packet 340, including the TARP header IPT, is encrypted using the link key for communication with the first-hop-TARP router. The first hop TARP router is randomly chosen. A final unencrypted IP header IPC is added to each encrypted TARP packet 340 to form a normal IP packet 360 that can be transmitted to a TARP router. Note that the process of constructing the TARP packet 360 does not have to be done in stages as described. The above description is just a useful heuristic for describing the final product, namely, the TARP packet.
Note that, TARP header IPT could be a completely custom header configuration with no similarity to a normal IP header except that it contain the information identified above. This is so since this header is interpreted by only TARP routers.
The above scheme may be implemented entirely by processes operating between the data link layer and the network layer of each server or terminal participating in the TARP system. Referring to
Because the encryption system described above can be inserted between the data link and network layers, the processes involved in supporting the encrypted communication may be completely transparent to processes at the IP (network) layer and above. The TARP processes may also be completely transparent to the data link layer processes as well. Thus, no operations at or above the network layer, or at or below the data link layer, are affected by the insertion of the TARP stack. This provides additional security to all processes at or above the network layer, since the difficulty of unauthorized penetration of the network layer (by, for example, a hacker) is increased substantially. Even newly developed servers running at the session layer leave all processes below the session layer vulnerable to attack. Note that in this architecture, security is distributed. That is, notebook computers used by executives on the road, for example, can communicate over the Internet without any compromise in security.
Note that IP address changes made by TARP terminals and routers can be done at regular intervals, at random intervals, or upon detection of "attacks." The variation of IP addresses hinders traffic analysis that might reveal which computers are communicating, and also provides a degree of immunity from attack. The level of immunity from attack is roughly proportional to the rate at which the IP address of the host is changing.
As mentioned, IP addresses may be changed in response to attacks. An attack may be revealed, for example, by a regular series of messages indicates that a router is being probed in some way. Upon detection of an attack, the TARP layer process may respond to this event by changing its IP address. To accomplish this, the TARP process will construct a TARP-formatted message, in the style of Internet Control Message Protocol (ICMP) datagrams as an example; this message will contain the machine's TARP address, its previous IP address, and its new IP address. The TARP layer will transmit this packet to at least one known TARP router; then upon receipt and validation of the message, the TARP router will update its LUT with the new IP address for the stated TARP address. The TARP router will then format a similar message, and broadcast it to the other TARP routers so that they may update their LUTs. Since the total number of TARP routers on any given subnet is expected to be relatively small, this process of updating the LUTs should be relatively fast. It may not, however, work as well when there is a relatively large number of TARP routers and/or a relatively large number of clients; this has motivated a refinement of this architecture to provide scalability; this refinement has led to a second embodiment, which is discussed below.
Upon detection of an attack, the TARP process may also create a subprocess that maintains the original IP address and continues interacting with the attacker. The latter may provide an opportunity to trace the attacker or study the attacker's methods (called "fishbowling" drawing upon the analogy of a small fish in a fish bowl that "thinks" it is in the ocean but is actually under captive observation). A history of the communication between the attacker and the abandoned (fishbowled) IP address can be recorded or transmitted for human analysis or further synthesized for purposes of responding in some way.
As mentioned above, decoy or dummy data or packets can be added to outgoing data streams by TARP terminals or routers. In addition to making it convenient to spread data over a larger number of separate packets, such decoy packets can also help to level the load on inactive portions of the Internet to help foil traffic analysis efforts.
Decoy packets may be generated by each TARP terminal 100, 110 or each router 122–127 on some basis determined by an algorithm. For example, the algorithm may be a random one which calls for the generation of a packet on a random basis when the terminal is idle. Alternatively, the algorithm may be responsive to time of day or detection of low traffic to generate more decoy packets during low traffic times. Note that packets are preferably generated in groups, rather than one by one, the groups being sized to simulate real messages. In addition, so that decoy packets may be inserted in normal TARP message streams, the background loop may have a latch that makes it more likely to insert decoy packets when a message stream is being received. That is, when a series of messages are received, the decoy packet generation rate may be increased. Alternatively, if a large number of decoy packets is received along with regular TARP packets, the algorithm may increase the rate of dropping of decoy packets rather than forwarding them. The result of dropping and generating decoy packets in this way is to make the apparent incoming message size different from the apparent outgoing message size to help foil traffic analysis. The rate of reception of packets, decoy or otherwise, may be indicated to the decoy packet dropping and generating processes through perishable decoy and regular packet counters. (A perishable counter is one that resets or decrements its value in response to time so that it contains a high value when it is incremented in rapid succession and a small value when incremented either slowly or a small number of times in rapid succession.) Note that destination TARP terminal 110 may generate decoy packets equal in number and size to those TARP packets received to make it appear it is merely routing packets and is therefore not the destination terminal.
Referring to
Referring to
Referring to
The IP agility feature described above relies on the ability to transmit IP address changes to all TARP routers. The embodiments including this feature will be referred to as "boutique" embodiments due to potential limitations in scaling these features up for a large network, such as the Internet. (The "boutique" embodiments would, however, be robust for use in smaller networks, such as small virtual private networks, for example). One problem with the boutique embodiments is that if IP address changes are to occur frequently, the message traffic required to update all routers sufficiently quickly creates a serious burden on the Internet when the TARP router and/or client population gets large. The bandwidth burden added to the networks, for example in ICMP packets, that would be used to update all the TARP routers could overwhelm the Internet for a large scale implementation, that approached the scale of the Internet. In other words, the boutique system's scalability is limited.
A system can be constructed which trades some of the features of the above embodiments to provide the benefits of IP agility without the additional messaging burden. This is accomplished by IP address-hopping according to shared algorithms that govern IP addresses used between links participating in communications sessions between nodes such as TARP nodes. (Note that the IP hopping technique is also applicable to the boutique embodiment.) The IP agility feature discussed with respect to the boutique system can be modified so that it becomes decentralized under this scalable regime and governed by the above-described shared algorithm. Other features of the boutique system may be combined with this new type of IP-agility.
The new embodiment has the advantage of providing IP agility governed by a local algorithm and set of IP addresses exchanged by each communicating pair of nodes. This local governance is session-independent in that it may govern communications between a pair of nodes, irrespective of the session or end points being transferred between the directly communicating pair of nodes.
In the scalable embodiments, blocks of IP addresses are allocated to each node in the network. (This scalability will increase in the future, when Internet Protocol addresses are increased to 128-bit fields, vastly increasing the number of distinctly addressable nodes). Each node can thus use any of the IP addresses assigned to that node to communicate with other nodes in the network. Indeed, each pair of communicating nodes can use a plurality of source IP addresses and destination IP addresses for communicating with each other.
Each communicating pair of nodes in a chain participating in any session stores two blocks of IP addresses, called netblocks, and an algorithm and randomization seed for selecting, from each netblock, the next pair of source/destination IP addresses that will be used to transmit the next message. In other words, the algorithm governs the sequential selection of IP-address pairs, one sender and one receiver IP address, from each netblock. The combination of algorithm, seed, and netblock (IP address block) will be called a "hopblock." A router issues separate transmit and receive hopblocks to its clients. The send address and the receive address of the IP header of each outgoing packet sent by the client are filled with the send and receive IP addresses generated by the algorithm. The algorithm is "clocked" (indexed) by a counter so that each time a pair is used, the algorithm turns out a new transmit pair for the next packet to be sent.
The router's receive hopblock is identical to the client's transmit hopblock. The router uses the receive hopblock to predict what the send and receive IP address pair for the next expected packet from that client will be. Since packets can be received out of order, it is not possible for the router to predict with certainty what IP address pair will be on the next sequential packet. To account for this problem, the router generates a range of predictions encompassing the number of possible transmitted packet send/receive addresses, of which the next packet received could leap ahead. Thus, if there is a vanishingly small probability that a given packet will arrive at the router ahead of 5 packets transmitted by the client before the given packet, then the router can generate a series of 6 send/receive IP address pairs (or "hop window") to compare with the next received packet. When a packet is received, it is marked in the hop window as such, so that a second packet with the same IP address pair will be discarded. If an out-of-sequence packet does not arrive within a predetermined timeout period, it can be requested for retransmission or simply discarded from the receive table, depending upon the protocol in use for that communications session, or possibly by convention.
When the router receives the client's packet, it compares the send and receive IP addresses of the packet with the next N predicted send and receive IP address pairs and rejects the packet if it is not a member of this set. Received packets that do not have the predicted source/destination IP addresses falling with the window are rejected, thus thwarting possible hackers. (With the number of possible combinations, even a fairly large window would be hard to fall into at random.) If it is a member of this set, the router accepts the packet and processes it further. This link-based IP-hopping strategy, referred to as "IHOP," is a network element that stands on its own and is not necessarily accompanied by elements of the boutique system described above. If the routing agility feature described in connection with the boutique embodiment is combined with this link-based IP-hopping strategy, the router's next step would be to decrypt the TARP header to determine the destination TARP router for the packet and determine what should be the next hop for the packet. The TARP router would then forward the packet to a random TARP router or the destination TARP router with which the source TARP router has a link-based IP hopping communication established.
While the secure session is active, both the client 901 and TARP router 911 (
Since packets can arrive out of order, however, the router 911 can maintain a "look ahead" buffer in its receive table, and will mark previously-received IP pairs as invalid for future packets; any future packet containing an IP pair that is in the look-ahead buffer but is marked as previously received will be discarded. Communications from the TARP router 911 to the client 901 are maintained in an identical manner; in particular, the router 911 will select the next IP address pair from its transmit table 923 when constructing a packet to send to the client 901, and the client 901 will maintain a look-ahead buffer of expected IP pairs on packets that it is receiving. Each TARP router will maintain separate pairs of transmit and receive tables for each client that is currently engaged in a secure session with or through that TARP router.
While clients receive their hopblocks from the first server linking them to the Internet, routers exchange hopblocks. When a router establishes a link-based IP-hopping communication regime with another router, each router of the pair exchanges its transmit hopblock. The transmit hopblock of each router becomes the receive hopblock of the other router. The communication between routers is governed as described by the example of a client sending a packet to the first router.
While the above strategy works fine in the IP milieu, many local networks that are connected to the Internet are ethernet systems. In ethernet, the IP addresses of the destination devices must be translated into hardware addresses, and vice versa, using known processes ("address resolution protocol," and "reverse address resolution protocol"). However, if the link-based IP-hopping strategy is employed, the correlation process would become explosive and burdensome. An alternative to the link-based IP hopping strategy may be employed within an ethernet network. The solution is to provide that the node linking the Internet to the ethernet (call it the border node) use the link-based IP-hopping communication regime to communicate with nodes outside the ethernet LAN. Within the ethernet LAN, each TARP node would have a single IP address which would be addressed in the conventional way. Instead of comparing the {sender, receiver} IP address pairs to authenticate a packet, the intra-LAN TARP node would use one of the IP header extension fields to do so. Thus, the border node uses an algorithm shared by the intra-LAN TARP node to generate a symbol that is stored in the free field in the IP header, and the intra-LAN TARP node generates a range of symbols based on its prediction of the next expected packet to be received from that particular source IP address. The packet is rejected if it does not fall into the set of predicted symbols (for example, numerical values) or is accepted if it does. Communications from the intra-LAN TARP node to the border node are accomplished in the same manner, though the algorithm will necessarily be different for security reasons. Thus, each of the communicating nodes will generate transmit and receive tables in a similar manner to that of
The algorithm used for IP address-hopping can be any desired algorithm. For example, the algorithm can be a given pseudo-random number generator that generates numbers of the range covering the allowed IP addresses with a given seed. Alternatively, the session participants can assume a certain type of algorithm and specify simply a parameter for applying the algorithm. For example the assumed algorithm could be a particular pseudo-random number generator and the session participants could simply exchange seed values.
Note that there is no permanent physical distinction between the originating and destination terminal nodes. Either device at either end point can initiate a synchronization of the pair. Note also that the authentication/synchronization-request (and acknowledgment) and hopblock-exchange may all be served by a single message so that separate message exchanges may not be required.
As another extension to the stated architecture, multiple physical paths can be used by a client, in order to provide link redundancy and further thwart attempts at denial of service and traffic monitoring. As shown in
Further Extensions
The following describes various extensions to the techniques, systems, and methods described above. As described above, the security of communications occurring between computers in a computer network (such as the Internet, an Ethernet, or others) can be enhanced by using seemingly random source and destination Internet Protocol (IP) addresses for data packets transmitted over the network. This feature prevents eavesdroppers from determining which computers in the network are communicating with each other while permitting the two communicating computers to easily recognize whether a given received data packet is legitimate or not. In one embodiment of the above-described systems, an IP header extension field is used to authenticate incoming packets on an Ethernet.
Various extensions to the previously described techniques described herein include: (1) use of hopped hardware or "MAC" addresses in broadcast type network; (2) a self-synchronization technique that permits a computer to automatically regain synchronization with a sender; (3) synchronization algorithms that allow transmitting and receiving computers to quickly re-establish synchronization in the event of lost packets or other events; and (4) a fast-packet rejection mechanism for rejecting invalid packets. Any or all of these extensions can be combined with the features described above in any of various ways.
A. Hardware Address Hopping
Internet protocol-based communications techniques on a LAN-or across any dedicated physical medium-typically embed the IP packets within lower-level packets, often referred to as "frames." As shown in
It may be possible for a nefarious listener to acquire information about the contents of a frame and/or its communicants by examining frames on a local network rather than (or in addition to) the IP packets themselves. This is especially true in broadcast media, such as Ethernet, where it is necessary to insert into the frame header the hardware address of the machine that generated the frame and the hardware address of the machine to which frame is being sent. All nodes on the network can potentially "see" all packets transmitted across the network. This can be a problem for secure communications, especially in cases where the communicants do not want for any third party to be able to identify who is engaging in the information exchange. One way to address this problem is to push the address-hopping scheme down to the hardware layer. In accordance with various embodiments of the invention, hardware addresses are "hopped" in a manner similar to that used to change IP addresses, such that a listener cannot determine which hardware node generated a particular message nor which node is the intended recipient.
As shown in
The lowest levels of communication software 1204 and 1217 communicate with hardware components 1206 and 1214 respectively, each of which can include one or more registers 1207 and 1215 that allow the hardware to be reconfigured or controlled in accordance with various communication protocols. The hardware components (an Ethernet network interface card, for example) communicate with each other over the communication medium. Each hardware component is typically pre-assigned a fixed hardware address or MAC number that identifies the hardware component to other nodes on the network. One or more interface drivers control the operation of each card and can, for example, be configured to accept or reject packets from certain hardware addresses. As will be described in more detail below, various embodiments of the inventive principles provide for "hopping" different addresses using one or more algorithms and one or more moving windows that track a range of valid addresses to validate received packets. Packets transmitted according to one or more of the inventive principles will be generally referred to as "secure" packets or "secure communications" to differentiate them from ordinary data packets that are transmitted in the clear using ordinary, machine-correlated addresses.
One straightforward method of generating non-attributable MAC addresses is an extension of the IP hopping scheme. In this scenario, two machines on the same LAN that desire to communicate in a secure fashion exchange random-number generators and seeds, and create sequences of quasi-random MAC addresses for synchronized hopping. The implementation and synchronization issues are then similar to that of IP hopping.
This approach, however, runs the risk of using MAC addresses that are currently active on the LAN-which, in turn, could interrupt communications for those machines. Since an Ethernet MAC address is at present 48 bits in length, the chance of randomly misusing an active MAC address is actually quite small. However, if that figure is multiplied by a large number of nodes (as would be found on an extensive LAN), by a large number of frames (as might be the case with packet voice or streaming video), and by a large number of concurrent Virtual Private Networks (VPNs), then the chance that a non-secure machine's MAC address could be used in an address-hopped frame can become non-trivial. In short, any scheme that runs even a small risk of interrupting communications for other machines on the LAN is bound to receive resistance from prospective system administrators. Nevertheless, it is technically feasible, and can be implemented without risk on a LAN on which there is a small number of machines, or if all of the machines on the LAN are engaging in MAC-hopped communications.
Synchronized MAC address hopping may incur some overhead in the course of session establishment, especially if there are multiple sessions or multiple nodes involved in the communications. A simpler method of randomizing MAC addresses is to allow each node to receive and process every incident frame on the network. Typically, each network interface driver will check the destination MAC address in the header of every incident frame to see if it matches that machine's MAC address; if there is no match, then the frame is discarded. In one embodiment, however, these checks can be disabled, and every incident packet is passed to the TARP stack for processing. This will be referred to as "promiscuous" mode, since every incident frame is processed. Promiscuous mode allows the sender to use completely random, unsynchronized MAC addresses, since the destination machine is guaranteed to process the frame. The decision as to whether the packet was truly intended for that machine is handled by the TARP stack, which checks the source and destination IP addresses for a match in its IP synchronization tables. If no match is found, the packet is discarded; if there is a match, the packet is unwrapped, the inner header is evaluated, and if the inner header indicates that the packet is destined for that machine then the packet is forwarded to the IP stack—otherwise it is discarded.
One disadvantage of purely-random MAC address hopping is its impact on processing overhead; that is, since every incident frame must be processed, the machine's CPU is engaged considerably more often than if the network interface driver is discriminating and rejecting packets unilaterally. A compromise approach is to select either a single fixed MAC address or a small number of MAC addresses (e.g., one for each virtual private network on an Ethernet) to use for MAC-hopped communications, regardless of the actual recipient for which the message is intended. In this mode, the network interface driver can check each incident frame against one (or a few) pre-established MAC addresses, thereby freeing the CPU from the task of physical-layer packet discrimination. This scheme does not betray any useful information to an interloper on the LAN; in particular, every secure packet can already be identified by a unique packet type in the outer header. However, since all machines engaged in secure communications would either be using the same MAC address, or be selecting from a small pool of predetermined MAC addresses, the association between a specific machine and a specific MAC address is effectively broken.
In this scheme, the CPU will be engaged more often than it would be in non-secure communications (or in synchronized MAC address hopping), since the network interface driver cannot always unilaterally discriminate between secure packets that are destined for that machine, and secure packets from other VPNs. However, the non-secure traffic is easily eliminated at the network interface, thereby reducing the amount of processing required of the CPU. There are boundary conditions where these statements would not hold, of course—e.g., if all of the traffic on the LAN is secure traffic, then the CPU would be engaged to the same degree as it is in the purely-random address hopping case; alternatively, if each VPN on the LAN uses a different MAC address, then the network interface can perfectly discriminate secure frames destined for the local machine from those constituting other VPNs. These are engineering tradeoffs that might be best handled by providing administrative options for the users when installing the software and/or establishing VPNs.
Even in this scenario, however, there still remains a slight risk of selecting MAC addresses that are being used by one or more nodes on the LAN. One solution to this problem is to formally assign one address or a range of addresses for use in MAC-hopped communications. This is typically done via an assigned numbers registration authority; e.g., in the case of Ethernet, MAC address ranges are assigned to vendors by the Institute of Electrical and Electronics Engineers (IEEE). A formally-assigned range of addresses would ensure that secure frames do not conflict with any properly-configured and properly-functioning machines on the LAN.
Reference will now be made to
At the receiving node 1202, the same IP hop algorithm 1222X is maintained and used to generate a receive table 1222 that lists valid triplets of source IP address, destination IP address, and discriminator field. This is shown by virtue of the first five entries of transmit table 1208 matching the second five entries of receive table 1222. (The tables may be slightly offset at any particular time due to lost packets, misordered packets, or transmission delays). Additionally, node 1202 maintains a receive window W3 that represents a list of valid IP source, IP destination, and discriminator fields that will be accepted when received as part of an incoming IP packet. As packets are received, window W3 slides down the list of valid entries, such that the possible valid entries change over time. Two packets that arrive out of order but are nevertheless matched to entries within window W3 will be accepted; those falling outside of window W3 will be rejected as invalid. The length of window W3 can be adjusted as necessary to reflect network delays or other factors.
Node 1202 maintains a similar transmit table 1221 for creating IP packets and frames destined for node 1201 using a potentially different hopping algorithm 1221X, and node 1201 maintains a matching receive table 1209 using the same algorithm 1209X. As node 1202 transmits packets to node 1201 using seemingly random IP source, IP destination, and/or discriminator fields, node 1201 matches the incoming packet values to those falling within window W1 maintained in its receive table. In effect, transmit table 1208 of node 1201 is synchronized (i.e., entries are selected in the same order) to receive table 1222 of receiving node 1202. Similarly, transmit table 1221 of node 1202 is synchronized to receive table 1209 of node 1201. It will be appreciated that although a common algorithm is shown for the source, destination and discriminator fields in
In accordance with another aspect of the invention, hardware or "MAC" addresses are hopped instead of or in addition to IP addresses and/or the discriminator field in order to improve security in a local area or broadcast-type network. To that end, node 1201 further maintains a transmit table 1210 using a transmit algorithm 1210X to generate source and destination hardware addresses that are inserted into frame headers (e.g., fields 1101A and 1101B in
In a second mode referred to as "promiscuous per VPN" mode, a small set of fixed hardware addresses are used, with a fixed source/destination hardware address used for all nodes communicating over a virtual private network. For example, if there are six nodes on an Ethernet, and the network is to be split up into two private virtual networks such that nodes on one VPN can communicate with only the other two nodes on its own VPN, then two sets of hardware addresses could be used: one set for the first VPN and a second set for the second VPN. This would reduce the amount of overhead involved in checking for valid frames since only packets arriving from the designated VPN would need to be checked. IP addresses and one or more discriminator fields could still be hopped as before for secure communication within the VPN. Of course, this solution compromises the anonymity of the VPNs (i.e., an outsider can easily tell what traffic belongs in which VPN, though he cannot correlate it to a specific machine/person). It also requires the use of a discriminator field to mitigate the vulnerability to certain types of DoS attacks. (For example, without the discriminator field, an attacker on the LAN could stream frames containing the MAC addresses being used by the VPN; rejecting those frames could lead to excessive processing overhead. The discriminator field would provide a low-overhead means of rejecting the false packets.)
In a third mode referred to as "hardware hopping" mode, hardware addresses are varied as illustrated in
B. Extending the Address Space
Address hopping provides security and privacy. However, the level of protection is limited by the number of addresses in the blocks being hopped. A hopblock denotes a field or fields modulated on a packet-wise basis for the purpose of providing a VPN. For instance, if two nodes communicate with IP address hopping using hopblocks of 4 addresses (2 bits) each, there would be 16 possible address-pair combinations. A window of size 16 would result in most address pairs being accepted as valid most of the time. This limitation can be overcome by using a discriminator field in addition to or instead of the hopped address fields. The discriminator field would be hopped in exactly the same fashion as the address fields and it would be used to determine whether a packet should be processed by a receiver.
Suppose that two clients, each using four-bit hopblocks, would like the same level of protection afforded to clients communicating via IP hopping between two A blocks (24 address bits eligible for hopping). A discriminator field of 20 bits, used in conjunction with the 4 address bits eligible for hopping in the IP address field, provides this level of protection. A 24-bit discriminator field would provide a similar level of protection if the address fields were not hopped or ignored. Using a discriminator field offers the following advantages: (1) an arbitrarily high level of protection can be provided, and (2) address hopping is unnecessary to provide protection. This may be important in environments where address hopping would cause routing problems.
C. Synchronization Techniques
It is generally assumed that once a sending node and receiving node have exchanged algorithms and seeds (or similar information sufficient to generate quasi-random source and destination tables), subsequent communication between the two nodes will proceed smoothly. Realistically, however, two nodes may lose synchronization due to network delays or outages, or other problems. Consequently, it is desirable to provide means for re-establishing synchronization between nodes in a network that have lost synchronization.
One possible technique is to require that each node provide an acknowledgment upon successful receipt of each packet and, if no acknowledgment is received within a certain period of time, to re-send the unacknowledged packet. This approach, however, drives up overhead costs and may be prohibitive in high-throughput environments such as streaming video or audio, for example.
A different approach is to employ an automatic synchronizing technique that will be referred to herein as "self-synchronization." In this approach, synchronization information is embedded into each packet, thereby enabling the receiver to re-synchronize itself upon receipt of a single packet if it determines that is has lost synchronization with the sender. (If communications are already in progress, and the receiver determines that it is still in sync with the sender, then there is no need to re-synchronize.) A receiver could detect that it was out of synchronization by, for example, employing a "dead-man" timer that expires after a certain period of time, wherein the timer is reset with each valid packet. A time stamp could be hashed into the public sync field (see below) to preclude packet-retry attacks.
In one embodiment, a "sync field" is added to the header of each packet sent out by the sender. This sync field could appear in the clear or as part of an encrypted portion of the packet. Assuming that a sender and receiver have selected a random-number generator (RNG) and seed value, this combination of RNG and seed can be used to generate a random-number sequence (RNS). The RNS is then used to generate a sequence of source/destination IP pairs (and, if desired, discriminator fields and hardware source and destination addresses), as described above. It is not necessary, however, to generate the entire sequence (or the first N-1 values) in order to generate the Nth random number in the sequence; if the sequence index N is known, the random value corresponding to that index can be directly generated (see below). Different RNGs (and seeds) with different fundamental periods could be used to generate the source and destination IP sequences, but the basic concepts would still apply. For the sake of simplicity, the following discussion will assume that IP source and destination address pairs (only) are hopped using a single RNG sequencing mechanism.
In accordance with a "self-synchronization" feature, a sync field in each packet header provides an index (i.e., a sequence number) into the RNS that is being used to generate IP pairs. Plugging this index into the RNG that is being used to generate the RNS yields a specific random number value, which in turn yields a specific IP pair. That is, an IP pair can be generated directly from knowledge of the RNG, seed, and index number; it is not necessary, in this scheme, to generate the entire sequence of random numbers that precede the sequence value associated with the index number provided.
Since the communicants have presumably previously exchanged RNGs and seeds, the only new information that must be provided in order to generate an IP pair is the sequence number. If this number is provided by the sender in the packet header, then the receiver need only plug this number into the RNG in order to generate an IP pair-and thus verify that the IP pair appearing in the header of the packet is valid. In this scheme, if the sender and receiver lose synchronization, the receiver can immediately re-synchronize upon receipt of a single packet by simply comparing the IP pair in the packet header to the IP pair generated from the index number. Thus, synchronized communications can be resumed upon receipt of a single packet, making this scheme ideal for multicast communications. Taken to the extreme, it could obviate the need for synchronization tables entirely; that is, the sender and receiver could simply rely on the index number in the sync field to validate the IP pair on each packet, and thereby eliminate the tables entirely.
The aforementioned scheme may have some inherent security issues associated with it—namely, the placement of the sync field. If the field is placed in the outer header, then an interloper could observe the values of the field and their relationship to the IP stream. This could potentially compromise the algorithm that is being used to generate the IP-address sequence, which would compromise the security of the communications. If, however, the value is placed in the inner header, then the sender must decrypt the inner header before it can extract the sync value and validate the IP pair; this opens up the receiver to certain types of denial-of-service (DoS) attacks, such as packet replay. That is, if the receiver must decrypt a packet before it can validate the IP pair, then it could potentially be forced to expend a significant amount of processing on decryption if an attacker simply retransmits previously valid packets. Other attack methodologies are possible in this scenario.
A possible compromise between algorithm security and processing speed is to split up the sync value between an inner (encrypted) and outer (unencrypted) header. That is, if the sync value is sufficiently long, it could potentially be split into a rapidly-changing part that can be viewed in the clear, and a fixed (or very slowly changing) part that must be protected. The part that can be viewed in the clear will be called the "public sync" portion and the part that must be protected will be called the "private sync" portion.
Both the public sync and private sync portions are needed to generate the complete sync value. The private portion, however, can be selected such that it is fixed or will change only occasionally. Thus, the private sync value can be stored by the recipient, thereby obviating the need to decrypt the header in order to retrieve it. If the sender and receiver have previously agreed upon the frequency with which the private part of the sync will change, then the receiver can selectively decrypt a single header in order to extract the new private sync if the communications gap that has led to lost synchronization has exceeded the lifetime of the previous private sync. This should not represent a burdensome amount of decryption, and thus should not open up the receiver to denial-of-service attack simply based on the need to occasionally decrypt a single header.
One implementation of this is to use a hashing function with a one-to-one mapping to generate the private and public sync portions from the sync value. This implementation is shown in
An important consideration in this architecture is the concept of "future" and "past" where the public sync values are concerned. Though the sync values, themselves, should be random to prevent spoofing attacks, it may be important that the receiver be able to quickly identify a sync value that has already been sent—even if the packet containing that sync value was never actually received by the receiver. One solution is to hash a time stamp or sequence number into the public sync portion, which could be quickly extracted, checked, and discarded, thereby validating the public sync portion itself.
In one embodiment, packets can be checked by comparing the source/destination IP pair generated by the sync field with the pair appearing in the packet header. If (1) they match, (2) the time stamp is valid, and (3) the dead-man timer has expired, then re-synchronization occurs; otherwise, the packet is rejected. If enough processing power is available, the dead-man timer and synchronization tables can be avoided altogether, and the receiver would simply resynchronize (e.g., validate) on every packet.
The foregoing scheme may require large-integer (e.g., 160-bit) math, which may affect its implementation. Without such large-integer registers, processing throughput would be affected, thus potentially affecting security from a denial-of-service standpoint. Nevertheless, as large-integer math processing features become more prevalent, the costs of implementing such a feature will be reduced.
D. Other Synchronization Schemes
As explained above, if W or more consecutive packets are lost between a transmitter and receiver in a VPN (where W is the window size), the receiver's window will not have been updated and the transmitter will be transmitting packets not in the receiver's window. The sender and receiver will not recover synchronization until perhaps the random pairs in the window are repeated by chance. Therefore, there is a need to keep a transmitter and receiver in synchronization whenever possible and to re-establish synchronization whenever it is lost.
A "checkpoint" scheme can be used to regain synchronization between a sender and a receiver that have fallen out of synchronization. In this scheme, a checkpoint message comprising a random IP address pair is used for communicating synchronization information. In one embodiment, two messages are used to communicate synchronization information between a sender and a recipient:
According to one variation of this approach, both the transmitter and receiver maintain three checkpoints (see
When a transmitter initiates synchronization, the IP pair it will use to transmit the next data packet is set to a predetermined value and when a receiver first receives a SYNC_REQ, the receiver window is updated to be centered on the transmitter's next IP pair. This is the primary mechanism for checkpoint synchronization.
Synchronization can be initiated by a packet counter (e.g., after every N packets transmitted, initiate a synchronization) or by a timer (every S seconds, initiate a synchronization) or a combination of both. See
From the receiver's perspective, the scheme operates as follows: (1) when it receives a "sync request" request from the transmitter, it advances its window to the next checkpoint position (even skipping pairs if necessary), and sends a "sync ack" message to the transmitter. If sync was never lost, then the "jump ahead" really just advances to the next available pair of addresses in the table (i.e., normal advancement).
If an interloper intercepts the "sync request" messages and tries to interfere with communication by sending new ones, it will be ignored if the synchronization has been established or it will actually help to re-establish synchronization.
A window is realigned whenever a re-synchronization occurs. This realignment entails updating the receiver's window to straddle the address pairs used by the packet transmitted immediately after the transmission of the SYNC_REQ packet. Normally, the transmitter and receiver are in synchronization with one another. However, when network events occur, the receiver's window may have to be advanced by many steps during resynchronization. In this case, it is desirable to move the window ahead without having to step through the intervening random numbers sequentially. (This feature is also desirable for the auto-sync approach discussed above).
E. Random Number generator with a Jump-Ahead Capability
An attractive method for generating randomly hopped addresses is to use identical random number generators in the transmitter and receiver and advance them as packets are transmitted and received. There are many random number generation algorithms that could be used. Each one has strengths and weaknesses for address hopping applications.
Linear congruential random number generators (LCRs) are fast, simple and well characterized random number generators that can be made to jump ahead n steps efficiently. An LCR generates random numbers X1, X2, X3 . . . Xk starting with seed X0 using a recurrence
X i=(a X i−1 +b)mod c, (1)
where a, b and c define a particular LCR. Another expression for Xi,
X i=((a i(X 0 +b)−b)/(a−1))mod c (2)
enables the jump-ahead capability. The factor ai can grow very large even for modest i if left unfettered. Therefore some special properties of the modulo operation can be used to control the size and processing time required to compute (2). (2) can be rewritten as:
X i=(a i(X 0(a−1)+b)−b)/(a−1)mod c. (3)
It can be shown that:
(a i(X 0(a−1)+b)−b)/(a−1) mod c=((a i mod((a−1)c)(X 0(a−1)+b)−b)/(a−1))mod c (4).
(X0(a−1)+b) can be stored as (X0(a−1)+b) mod c, b as b mod c and compute ai mod ((a−1)c) (this requires O(log(i)) steps).
A practical implementation of this algorithm would jump a fixed distance, n, between synchronizations; this is tantamount to synchronizing every n packets. The window would commence n IP pairs from the start of the previous window. Using Xj w, the random number at the jth checkpoint, as X0 and n as i, a node can store an mod((a−1)c) once per LCR and set
X j+1 w =X n(j+1)=((a n mod((a−1)c)(X j w(a−1)+b)/(a−1))mod c, (5)
to generate the random number for the j+1th synchronization. Using this construction, a node could jump ahead an arbitrary (but fixed) distance between synchronizations in a constant amount of time (independent of n).
Pseudo-random number generators, in general, and LCRs, in particular, will eventually repeat their cycles. This repetition may present vulnerability in the IP hopping scheme. An adversary would simply have to wait for a repeat to predict future sequences. One way of coping with this vulnerability is to create a random number generator with a known long cycle. A random sequence can be replaced by a new random number generator before it repeats. LCRs can be constructed with known long cycles. This is not currently true of many random number generators.
Random number generators can be cryptographically insecure. An adversary can derive the RNG parameters by examining the output or part of the output. This is true of LCGs. This vulnerability can be mitigated by incorporating an encryptor, designed to scramble the output as part of the random number generator. The random number generator prevents an adversary from mounting an attack—e.g., a known plaintext attack—against the encryptor.
F. Random Number Generator Example
Consider a RNG where a=31, b=4 and c=15. For this case equation (1) becomes:
X i=(31 X i−1+4)mod 15. (6)
If one sets X0=1, equation (6) will produce the sequence 1, 5, 9, 13, 2, 6, 10, 14, 3, 7, 11, 0, 4, 8, 12. This sequence will repeat indefinitely. For a jump ahead of 3 numbers in this sequence an=313=29791, c*(a−1)=15*30=450 and anmod((a−1)c)=313mod(15*30)=29791mod(450)=91. Equation (5) becomes:
((91(X i30+4)−4)/30)mod 15 (7).
Table 1 shows the jump ahead calculations from (7). The calculations start at 5 and jump ahead 3.
TABLE 1 I Xi (Xi30 + 4) 91 (Xi30 + 4) − 4 ((91 (Xi30 + 4) − 4)/30 Xi+3 1 5 154 14010 467 2 4 2 64 5820 194 14 7 14 424 38580 1286 11 10 11 334 30390 1013 8 13 8 244 22200 740 5
G. Fast Packet Filter
Address hopping VPNs must rapidly determine whether a packet has a valid header and thus requires further processing, or has an invalid header (a hostile packet) and should be immediately rejected. Such rapid determinations will be referred to as "fast packet filtering." This capability protects the VPN from attacks by an adversary who streams hostile packets at the receiver-at a high rate of speed in the hope of saturating the receiver's processor (a so-called "denial of service" attack). Fast packet filtering is an important feature for implementing VPNs on shared media such as Ethernet.
Assuming that all participants in a VPN share an unassigned "A" block of addresses, one possibility is to use an experimental "A" block that will never be assigned to any machine that is not address hopping on the shared medium. "A" blocks have a 24 bits of address that can be hopped as opposed to the 8 bits in "C" blocks. In this case a hopblock will be the "A" block. The use of the experimental "A" block is a likely option on an Ethernet because:
The Ethernet example will be used to describe one implementation of fast packet filtering. The ideal algorithm would quickly examine a packet header, determine whether the packet is hostile, and reject any hostile packets or determine which active IP pair the packet header matches. The problem is a classical associative memory problem. A variety of techniques have been developed to solve this problem (hashing, B-trees etc). Each of these approaches has its strengths and weaknesses. For instance, hash tables can be made to operate quite fast in a statistical sense, but can occasionally degenerate into a much slower algorithm. This slowness can persist for a period of time. Since there is a need to discard hostile packets quickly at all times, hashing would be unacceptable.
H. Presence Vector Algorithm
A presence vector is a bit vector of length 2n that can be indexed by n-bit numbers (each ranging from 0 to 2n−1). One can indicate the presence of k n-bit numbers (not necessarily unique), by setting the bits in the presence vector indexed by each number to 1. Otherwise, the bits in the presence vector are 0. An n-bit number, x, is one of the k numbers if and only if the xth bit of the presence vector is 1. A fast packet filter can be implemented by indexing the presence vector and looking for a 1, which will be referred to as the "test".
For example, suppose one wanted to represent the number 135 using a presence vector. The 135th bit of the vector would be set. Consequently, one could very quickly determine whether an address of 135 was valid by checking only one bit: the 135th bit. The presence vectors could be created in advance corresponding to the table entries for the IP addresses. In effect, the incoming addresses can be used as indices into a long vector, making comparisons very fast. As each RNG generates a new address, the presence vector is updated to reflect the information. As the window moves, the presence vector is updated to zero out addresses that are no longer valid.
There is a trade-off between efficiency of the test and the amount of memory required for storing the presence vector(s). For instance, if one were to use the 48 bits of hopping addresses as an index, the presence vector would have to be 35 terabytes. Clearly, this is too large for practical purposes. Instead, the 48 bits can be divided into several smaller fields. For instance, one could subdivide the 48 bits into four 12-bit fields (see
A presence vector will have a 1 in the yth bit if and only if one or more addresses with a corresponding field of y are active. An address is active only if each presence vector indexed by the appropriate sub-field of the address is 1.
Consider a window of 32 active addresses and 3 checkpoints. A hostile packet will be rejected by the indexing of one presence vector more than 99% of the time. A hostile packet will be rejected by the indexing of all 4 presence vectors more than 99.9999995% of the time. On average, hostile packets will be rejected in less than 1.02 presence vector index operations.
The small percentage of hostile packets that pass the fast packet filter will be rejected when matching pairs are not found in the active window or are active checkpoints. Hostile packets that serendipitously match a header will be rejected when the VPN software attempts to decrypt the header. However, these cases will be extremely rare. There are many other ways this method can be configured to arbitrate the space/speed tradeoffs.
I. Further Synchronization Enhancements
A slightly modified form of the synchronization techniques described above can be employed. The basic principles of the previously described checkpoint synchronization scheme remain unchanged. The actions resulting from the reception of the checkpoints are, however, slightly different. In this variation, the receiver will maintain between OoO ("Out of Order") and 2�WINDOW_SIZE+OoO active addresses (1≦OoO≦WINDOW_SIZE and WINDOW_SIZE≧1). OoO and WINDOW_SIZE are engineerable parameters, where OoO is the minimum number of addresses needed to accommodate lost packets due to events in the network or out of order arrivals and WINDOW_SIZE is the number of packets transmitted before a SYNC_REQ is issued.
The receiver starts with the first 2�WINDOW_SIZE addresses loaded and active (ready to receive data). As packets are received, the corresponding entries are marked as "used" and are no longer eligible to receive packets. The transmitter maintains a packet counter, initially set to 0, containing the number of data packets transmitted since the last initial transmission of a SYNC_REQ for which SYNC_ACK has been received. When the transmitter packet counter equals WINDOW_SIZE, the transmitter generates a SYNC_REQ and does its initial transmission. When the receiver receives a SYNC_REQ corresponding to its current CKPT_N, it generates the next WINDOW_SIZE addresses and starts loading them in order starting at the first location after the last active address wrapping around to the beginning of the array after the end of the array has been reached. The receiver's array might look like
Another embodiment incorporating various inventive principles is shown in
As shown in
|Cited Patent
|Filing date
|Publication date
|Oct 5, 1988
|Apr 24, 1990
|Yale University
|Multiprocessor/memory interconnection network wherein messages sent through the network to the same memory are combined
|Apr 24, 1987
|Jun 12, 1990
|Network Systems Corporation
|Network communications adapter with dual interleaved memory banks servicing multiple processors
|May 13, 1992
|May 10, 1994
|Chipcom Corporation
|Security system for a network concentrator
|Nov 12, 1992
|Jul 12, 1994
|Walsh Jeffrey R
|Method and apparatus for redundant local area network systems
|Aug 19, 1993
|Sep 24, 1996
|Chipcom Corporation
|Method and apparatus for secure data packet bus communication
|Jun 10, 1994
|Dec 24, 1996
|Sun Microsystems, Inc.
|Method and apparatus for a key-management scheme for internet protocols
|Feb 23, 1996
|Aug 5, 1997
|International Business Machines Corporation
|Multi-function network
|Oct 24, 1995
|Nov 18, 1997
|Nguyen; Minhtam C.
|Network with secure communications sessions
|Feb 15, 1996
|Apr 14, 1998
|Bay Networks, Inc.
|Forwarding internetwork packets by replacing the destination address
|Nov 21, 1996
|Aug 18, 1998
|Computer Associates International, Inc.
|Method and apparatus for automated network-wide surveillance and security breach intervention
|Jan 9, 1997
|Sep 8, 1998
|International Business Machines Corporation
|System and method for detecting and preventing security
|Jun 18, 1996
|Nov 24, 1998
|Storage Technology Corporation
|Policy caching method and apparatus for use in a communication device based on contents of one data unit in a subset of related data units
|Feb 15, 1996
|Dec 1, 1998
|Bay Networks, Inc.
|Forwarding of internetwork packets to a destination network via a selected one of a plurality of paths
|Jul 10, 1996
|Feb 2, 1999
|Microsoft Corporation
|Out-of-band data transmission
|Feb 4, 1997
|Mar 2, 1999
|Sun Microsystems, Inc.
|System for packet filtering of data packets at a computer network interface
|Sep 12, 1996
|Apr 6, 1999
|Internet Security Systems, Inc.
|Method and apparatus for detecting and identifying security vulnerabilities in an open network computer communication system
|Oct 17, 1996
|Apr 27, 1999
|Network Engineering Software
|Firewall providing enhanced network security and user transparency
|Jan 9, 1997
|May 18, 1999
|International Business Machines Corporation
|Managed network device security method and apparatus
|Apr 15, 1997
|Nov 30, 1999
|International Business Machines Corporation
|Reinitiation of bind calls for IP applications concurrently executing with alternate address
|Nov 20, 1998
|Dec 21, 1999
|Network Alchemy, Inc.
|Method and apparatus for an internet protocol (IP) network clustering system
|Jul 14, 1997
|Jan 18, 2000
|Nec Corporation
|Virtual private network system over public mobile data network and virtual LAN
|Apr 26, 1999
|Apr 18, 2000
|Network Engineering Software, Inc.
|Firewall providing enhanced network security and user transparency
|Mar 10, 1998
|Apr 25, 2000
|Unisys Corporation
|Method of providing a service through a server with a virtual single network address
|Jan 27, 1998
|Jun 20, 2000
|Vpnet Technologies, Inc.
|Method and apparatus for managing a virtual private network
|Jan 29, 1998
|Sep 12, 2000
|Ip Dynamics, Inc.
|Domain name routing
|Jun 24, 1996
|Nov 14, 2000
|Cabletron Systems, Inc.
|Fast network layer packet filter
|Mar 4, 1998
|Jan 23, 2001
|Internet Dynamics, Inc.
|Secure delivery of information in a network
|Sep 30, 1997
|Apr 24, 2001
|Hewlett-Packard Company
|System providing for multiple virtual circuits between two network entities
|Apr 17, 1998
|May 1, 2001
|Vpnet Technologies, Inc.
|Method and apparatus for configuring a virtual private network
|Sep 21, 1998
|Jun 5, 2001
|International Business Machines Corporation
|Network server having dynamic load balancing of messages in both inbound and outbound directions
|Oct 8, 1998
|Jun 5, 2001
|Cisco Technology, Inc.
|Dynamic network address updating
|Sep 10, 1998
|Sep 4, 2001
|Hewlett-Packard Company
|Method and system for automatic discovery of network services
|Apr 30, 1998
|Nov 27, 2001
|Alcatel Usa Sourcing, L.P.
|Multiple network configuration with local and remote network redundancy by dual media redirect
|Jan 29, 1999
|Dec 11, 2001
|International Business Machines Corporation
|System and method for managing security objects
|Dec 9, 1998
|Dec 18, 2001
|Chris Risley
|Domain name system lookup allowing intelligent correction of searches and presentation of auxiliary information
|Mar 5, 1998
|Mar 5, 2002
|3Com Corporation
|Method and protocol for distributed network address translation
|Feb 16, 1999
|May 27, 2003
|Hughes Electronics Corporation
|Apparatus and method for hybrid network access
|Dec 20, 1995
|May 27, 2003
|Sun Microsystems Inc.
|Maintaining packet security in a computer network
|Mar 1, 2000
|Jun 17, 2003
|The Foxboro Company
|Network fault detection and recovery
|Jan 28, 1998
|Feb 3, 2004
|Siemens Aktiengesellschaft
|Audio-active communication stations, communication method and communication system with audio-active communication stations
|Oct 26, 2000
|Mar 30, 2004
|International Business Machines Corporation
|Protecting open world wide web sites from known malicious users by diverting requests from malicious users to alias addresses for the protected sites
|Aug 31, 1998
|Apr 6, 2004
|International Business Machines Corporation
|System and method for IP network address translation using selective masquerade
|Aug 16, 1999
|Jul 6, 2004
|Per Sahlqvist
|Data transmission method and device
|May 28, 1999
|Dec 2, 1999
|Sun Microsystems Inc
|Communication system using the internet
|Jun 16, 1997
|Dec 29, 1997
|AT&T Corp.
|System and method for automated network reconfiguration
|Oct 10, 1996
|Apr 15, 1998
|Hewlett-Packard Company
|System providing for multiple virtual circuits between two network entities
|Oct 24, 1997
|Apr 29, 1998
|Digital Equipment Corporation
|Pseudo network adapter for frame capture, encapsulation and encryption
|Jan 26, 1998
|Aug 12, 1998
|Hitachi, Ltd.
|Networking method
|Title not available
|Dec 12, 1997
|Jun 25, 1998
|Nortel Networks Corporation
|Virtual private network service provider for asynchronous transfer mode network
|Apr 20, 1998
|Dec 10, 1998
|Koninklijke Philips Electronics N.V.
|Authentication system
|Jun 23, 1998
|Dec 30, 1998
|Telefonaktiebolaget Lm Ericsson (Publ)
|Method and apparatus to enable a first subscriber in a larger network to retrieve the address of a second subscriber in a virtual private network
|Jan 26, 1999
|Jul 29, 1999
|Ascend Communications, Inc.
|Virtual private network system and method
|Mar 18, 1999
|Sep 23, 1999
|Cisco Technology, Inc.
|Method for blocking denial of service and address spoofing attacks on a private network
|May 15, 2000
|Nov 23, 2000
|Comsec Corporation
|Method of communications and communication network intrusion protection methods and intrusion attempt detection system
|Dec 18, 2000
|Jul 12, 2001
|Telefonaktiebolaget Lm Ericsson (Publ.)
|Method and system for communication
|Alan O. Frier et al., "The SSL Protocol Version 3.0", Nov. 18, 1996, printed from http://www.netscape.com/eng/ss13/draft302.txt on Feb. 4, 2002, 56 pages.
|August Bequai, "Balancing Legal Concerns Over Crime and Security in Cyberspace", Computer & Security, vol. 17, No. 4, 1998, pp. 293-298.
|D. B. Chapman et al., "Building Internet Firewalls", Nov. 1995, pp. 278-297 and pp. 351-375.
|D. Clark, "US Calls for Private Domain-Name System", Computer, IEEE Computer Society, Aug. 1, 1998, pp. 22-25.
|Dolev, Shlomi and Ostrovsky, Rafil, "Efficient Anonymous Multicast and Reception" (Extended Abstract), 16 pages.
|Donald E. Eastlake, "Domain Name System Security Extensions", DNS Security Working Group, Apr. 1998, 51 pages.
|F. Halsall, "Data Communications, Computer Networks And Open Systems", Chapter 4, Protocol Basics, 1996, pp. 198-203.
|Fasbender, Kesdogan, and Kubitz: "Variable and Scalable Security" Protection of Location Information in Mobile IP, IEEE publication, 1996, pp. 963-967.
|Fasbender, Kesdogan, and Kubitz: "Variable and Scalable Security: Protection of Location Information in Mobile IP", IEEE publication, 1996, pp. 963-967.
|Glossary for the Linux FreeS/WAN project, printed from http://liberty.freeswan.org/freeswan<SUB>-</SUB>trees/freeswan-1.3/doc/glossary.html on Feb. 21, 2002, 25 pages.
|J. Gilmore, "Swan: Securing the Internet against Wiretapping", printed from http://liberty.freeswan.org/freeswan<SUB>-</SUB>trees/freeswan-1.3/doc/rationale.html on Feb. 21, 2002, 4 pages.
|James E. Bellaire, "New Statement of Rules-Naming Internet Domains", Internet Newsgroup, Jul. 30, 1995, 1 page.
|Jim Jones et al., "Distributed Denial of Service Attacks: Defenses", Global Integrity Corporation, 2000, pp. 1-14.
|Laurie Wells, "Security Icon", Oct. 19, 1998, 1 page.
|Linux FreeS/WAN Index File, printed from http://liberty.freeswan.org/freeswan<SUB>-</SUB>trees/freeswan-1.3/doc/ on Feb. 21, 2002, 3 Pages.
|P. Srisuresh et al., "DNS extensions to Network Address Translators", Jul. 1998, 27 pages.
|Reiter, Michael K. and Rubin, Aviel D. (AT&T Labs-Research), "Crowds: Anonymity for Web Transmissions", pp. 1-23.
|Rich Winkel, "CAQ: Networking With Spooks: The NET & The Control Of Information", Internet Newsgroup, Jun. 21, 1997, 4 pages.
|Rubin, Aviel D., Greer, Daniel, and Ranum, Marcus J. (Wiley Computer Publishing), "Web Security Sourcebook", pp. 82-94.
|Search Report (dated Aug. 20, 2002), International Application No. PCT/US01/04340.
|Search Report (dated Aug. 23, 2002), International Application No. PCT/US01/13260.
|Search Report (dated Jun. 18, 2002), International Application No. PCT/US01/13260.
|Search Report (dated Jun. 28, 2002), International Application No. PCT/US01/13261.
|Search Report (dated Oct. 7, 2002), International Application No. PCT/US01/13261.
|Shree Murthy et al., "Congestion-Oriented Shortest Multipath Routing", Proceedings of IEEE INFOCOM, 1996, pp. 1028-1036.
|W. Stallings, "Cryptography And Network Security", 2<SUP>nd </SUP>Edition, Chapter 13, IP Security, Jun. 8, 1998, pp. 399-440.
|W. Stallings, "New Cryptography and Network Security Book", Jun. 8, 1998, 3 pages.
|Citing Patent
|Filing date
|Publication date
|Nov 18, 2003
|Aug 26, 2008
|Virnetx, Inc.
|Agile network protocol for secure communications using secure domain names
|Sep 30, 2002
|Feb 10, 2009
|Virnetx Inc.
|Establishment of a secure communication link based on a domain name service (DNS) request
|Apr 23, 2004
|Sep 8, 2009
|Koninklijke Philips Electronics N.V.
|Overhead reduction and address and protection in communication stack
|Aug 16, 2007
|Apr 26, 2011
|Virnetx, Inc.
|Agile network protocol for secure communications with assured system availability
|Aug 17, 2007
|May 17, 2011
|Virnetx, Inc.
|Agile network protocol for secure communications using secure domain names
|Aug 16, 2007
|Jul 26, 2011
|Virnetx, Incorporated
|Method for establishing secure communication link between computers of virtual private network
|Dec 13, 2005
|Aug 9, 2011
|Virnetx, Inc.
|Agile network protocol for secure communications with assured system availability
|Feb 27, 2007
|Nov 1, 2011
|Virnetx, Inc.
|Method for establishing secure communication link between computers of virtual private network
|Apr 16, 2009
|Jul 10, 2012
|Koninklijke Philips Electronics N.V.
|Overhead reduction and address protection in communication stack
|Dec 23, 2011
|Jun 4, 2013
|Virnetx, Inc.
|System and method employing an agile network protocol for secure communications using secure domain names
|Dec 27, 2011
|Aug 6, 2013
|Virnetx, Inc.
|System and method employing an agile network protocol for secure communications using secure domain names
|Dec 28, 2011
|Aug 6, 2013
|Virnetx, Inc.
|System and method employing an agile network protocol for secure communications using secure domain names
|Apr 25, 2011
|Aug 20, 2013
|Virnetx, Inc.
|Agile network protocol for secure communications with assured system availability
|Dec 23, 2011
|Aug 20, 2013
|Virnetx, Inc.
|System and method employing an agile network protocol for secure communications using secure domain names
|Jan 4, 2012
|Aug 27, 2013
|Virnetx, Inc.
|System and method employing an agile network protocol for secure communications using secure domain names
|May 17, 2012
|Oct 8, 2013
|Virnetx, Inc.
|Agile network protocol for secure communications using secure domain names
|Jan 3, 2012
|Oct 15, 2013
|Virnetx, Inc.
|System and method employing an agile network protocol for secure communications using secure domain names
|Mar 16, 2011
|Oct 29, 2013
|Virnetx, Inc.
|Agile network protocol for secure communications using secure domain names
|Mar 18, 2004
|Jul 15, 2014
|International Business Machines Corporation
|Providing transaction-level security
|Feb 9, 2012
|Aug 26, 2014
|Harris Corporation
|Dynamic computer network with variable identity parameters
|Jul 25, 2013
|Sep 23, 2014
|Virnetx, Inc.
|System and method employing an agile network protocol for secure communications using secure domain names
|Jun 6, 2013
|Sep 30, 2014
|Virnetx, Inc.
|System and method employing an agile network protocol for secure communications using secure domain names
|Sep 13, 2012
|Oct 21, 2014
|Virnetx, Inc.
|Agile network protocol for secure communications using secure domain names
|Aug 16, 2007
|Oct 28, 2014
|Virnetx, Inc.
|Agile network protocol for secure communications with assured system availability
|May 1, 2012
|Nov 25, 2014
|Harris Corporation
|Systems and methods for spontaneously configuring a computer network
|Feb 9, 2012
|Nov 25, 2014
|Harris Corporation
|Bridge for communicating with a dynamic computer network
|Jun 6, 2013
|Dec 2, 2014
|Virnetx, Inc.
|System and method employing an agile network protocol for secure communications using secure domain names
|Feb 9, 2012
|Jan 13, 2015
|Harris Corporation
|Mission management for dynamic computer networks
|May 1, 2012
|Jan 13, 2015
|Harris Corporation
|Systems and methods for dynamically changing network states
|Oct 31, 2011
|Jan 27, 2015
|Virnetx, Inc.
|Method for establishing encrypted channel
|May 1, 2012
|Feb 17, 2015
|Harris Corporation
|Noise, encryption, and decoys for communications in a dynamic computer network
|May 1, 2012
|Feb 24, 2015
|Harris Corporation
|Router for communicating data in a dynamic computer network
|Sep 10, 2014
|May 5, 2015
|Virnetx, Inc.
|System and method for using a registered name to connect network devices with a link that uses encryption
|Apr 6, 2011
|May 19, 2015
|Virnetx, Inc.
|Agile network protocol for secure communications using secure domain names
|Jul 25, 2013
|May 19, 2015
|Virnetx, Inc.
|Systems and methods for connecting network devices over communication network
|May 1, 2012
|Jul 7, 2015
|Harris Corporation
|Systems and methods for identifying, deterring and/or delaying attacks to a network using shadow networking techniques
|Sep 13, 2012
|Jul 7, 2015
|Virnetx, Inc.
|Agile network protocol for secure communications using secure domain names
|May 28, 2013
|Jul 7, 2015
|Virnetx, Inc.
|System and method for establishing an encrypted communication link based on IP address lookup requests
|Jul 12, 2011
|Jul 28, 2015
|Virnetx, Inc.
|Method for establishing secure communication link between computers of virtual private network
|Sep 14, 2012
|Aug 4, 2015
|Virnetx, Inc.
|System and method employing an agile network protocol for secure communications using secure domain names
|May 9, 2014
|Aug 25, 2015
|At&T Intellectual Property I, Lp
|Backhaul link for distributed antenna system
|May 1, 2012
|Sep 8, 2015
|Harris Corporation
|Switch for communicating data in a dynamic computer network
|May 1, 2012
|Oct 6, 2015
|Harris Corporation
|Systems and methods for implementing moving target technology in legacy hardware
|Apr 17, 2015
|Oct 6, 2015
|At&T Intellectual Property I, Lp
|Surface-wave communications and methods thereof
|Dec 10, 2013
|Dec 8, 2015
|At&T Intellectual Property I, L.P.
|Quasi-optical coupler
|Jan 13, 2014
|Feb 16, 2016
|Harris Corporation
|Session hopping
|Oct 21, 2014
|Apr 12, 2016
|At&T Intellectual Property I, Lp
|Transmission device with impairment compensation and methods for use therewith
|Nov 18, 2013
|May 10, 2016
|Harris Corporation
|Session hopping
|Sep 13, 2012
|Jun 21, 2016
|Virnetx, Inc.
|Agile network protocol for secure communications using secure domain names
|Sep 14, 2012
|Jul 5, 2016
|Virnetx, Inc.
|System and method for establishing a communication link
|Oct 29, 2014
|Aug 9, 2016
|Virnetx, Inc.
|Method for establishing connection between devices
|Jul 31, 2015
|Oct 4, 2016
|At&T Intellectual Property I, Lp
|Method and apparatus for exchanging communication signals
|Aug 28, 2015
|Oct 11, 2016
|At&T Intellectual Property I, L.P.
|Surface-wave communications and methods thereof
|Oct 30, 2015
|Oct 25, 2016
|At&T Intellectual Property I, L.P.
|Quasi-optical coupler
|May 18, 2012
|Oct 25, 2016
|Virnetz, Inc.
|Agile network protocol for secure communications with assured system availability
|Jul 16, 2015
|Nov 8, 2016
|At&T Intellectual Property I, L.P.
|Transmission medium having multiple cores and methods for use therewith
|Oct 10, 2014
|Nov 22, 2016
|At&T Intellectual Property I, L.P.
|Method and apparatus for arranging communication sessions in a communication system
|Nov 5, 2013
|Nov 22, 2016
|Harris Corporation
|Systems and methods for enterprise mission management of a computer network
|Jun 25, 2015
|Nov 29, 2016
|At&T Intellectual Property I, L.P.
|Methods and apparatus for inducing a fundamental wave mode on a transmission medium
|Oct 21, 2014
|Dec 13, 2016
|At&T Intellectual Property I, L.P.
|Apparatus for providing communication services and methods thereof
|Mar 15, 2016
|Dec 20, 2016
|At&T Intellectual Property I, L.P.
|Guided-wave transmission device with non-fundamental mode propagation and methods for use therewith
|May 31, 2013
|Dec 20, 2016
|At&T Intellectual Property I, L.P.
|Remote distributed antenna system
|Mar 15, 2016
|Dec 27, 2016
|At&T Intellectual Property I, L.P.
|Transmission device with mode division multiplexing and methods for use therewith
|Nov 20, 2014
|Jan 10, 2017
|At&T Intellectual Property I, L.P.
|Transmission device with mode division multiplexing and methods for use therewith
|Oct 21, 2014
|Feb 7, 2017
|At&T Intellectual Property I, L.P.
|Guided-wave transmission device with diversity and methods for use therewith
|Mar 1, 2016
|Feb 14, 2017
|At&T Intellectual Property I, L.P.
|Transmission device with impairment compensation and methods for use therewith
|Oct 21, 2014
|Feb 21, 2017
|At&T Intellectual Property I, L.P.
|Guided-wave transmission device and methods for use therewith
|Mar 15, 2016
|Feb 21, 2017
|At&T Intellectual Property I, L.P.
|Guided-wave transmission device and methods for use therewith
|Jun 8, 2016
|Mar 14, 2017
|At&T Intellectual Property I, L.P.
|Apparatus for providing communication services and methods thereof
|Jun 11, 2015
|Mar 28, 2017
|At&T Intellectual Property I, L.P.
|Repeater and methods for use therewith
|Jul 15, 2015
|Mar 28, 2017
|At&T Intellectual Property I, L.P.
|Method and apparatus for launching a wave mode that mitigates interference
|Oct 2, 2014
|Apr 4, 2017
|At&T Intellectual Property I, L.P.
|Method and apparatus that provides fault tolerance in a communication network
|Oct 21, 2014
|Apr 18, 2017
|At&T Intellectual Property I, L.P.
|Guided-wave transmission device with non-fundamental mode propagation and methods for use therewith
|Jul 14, 2015
|Apr 18, 2017
|At&T Intellectual Property I, L.P.
|Apparatus and methods for transmitting wireless signals
|Sep 29, 2014
|Apr 18, 2017
|At&T Intellectual Property I, L.P.
|Method and apparatus for distributing content in a communication network
|Jun 25, 2015
|May 2, 2017
|At&T Intellectual Property I, L.P.
|Methods and apparatus for inducing a non-fundamental wave mode on a transmission medium
|Sep 30, 2002
|Feb 20, 2003
|Science Applications International Corporation
|Agile network protocol for secure communications with assured system availability
|Sep 25, 2001
|Apr 22, 2004
|Seung-Eui Yang
|Method for an internet communication
|Mar 18, 2004
|Sep 22, 2005
|International Business Machines Corporation
|Method and apparatus for providing transaction-level security
|Apr 23, 2004
|May 24, 2007
|Koninklijke Philips Electronics N.V.
|Overhead reduction and address and protection in communication stack
|May 7, 2007
|Nov 13, 2008
|International Business Machines Corporation
|Method and system of network communication privacy between network devices
|Apr 16, 2009
|Mar 31, 2011
|Koninklijke Philips Electronics, N.V.
|Overhead reduction and address protection in communication stack
|U.S. Classification
|International Classification
|Cooperative Classification
|European Classification
|Apr 24, 2003
Owner name: SCIENCE APPLICATIONS INTERNATIONAL CORPORATION, CA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MUNGER, EDMUND C.;SABIO, VENCENT J.;SHORT, ROBERT D. III;AND OTHERS;REEL/FRAME:014003/0435;SIGNING DATES FROM 19991027 TO 19991028
|Jan 10, 2007
Owner name: VIRNETX INC., CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SCIENCE APPLICATIONS INTERNATIONAL CORPORATION;REEL/FRAME:018757/0326
Effective date: 20061221
|Apr 28, 2010
|Fee payment
Year of fee payment: 4
|Jan 19, 2012
Owner name: VIRNETX INC., NEVADA
Free format text: CHANGE OF ADDRESS OF ASSIGNEE;ASSIGNOR:VIRNETX INC.;REEL/FRAME:027558/0281
Effective date: 20120119
|Apr 15, 2014
|Fee payment
Year of fee payment: 8