Abstract:
Systems ( 1900 ) and methods ( 2300, 2400 ) for use in a network node ( 1901 - 1903 ). The methods involve: receiving a Data Communication (“DC”) from Data Link Layer Software (“DLLS”); identifying an IDentity Parameter (“IDP”) contained in DC which comprises a False Value (“FV”) specifying false information about the node or DC; obtaining a True Value (“TV”) specifying true information about the node or DC; replacing the FV with the TV to generate a modified DC; and forwarding the modified DC to Network Layer Software (“NLS”). The methods also involve: receiving a Data Unit (“DU”) from NLS comprising a Transport Layer Header (“TLH”) and a Network Layer Header (“NLH”) including TVs specifying true information about the node or FDU; obtaining a FV which specifies false information about the node or FDU; replacing a TV of DU with the FV so as to form a Modified Data Unit (“MDU”); and forwarding MDU to DLLS.

Description:
BACKGROUND OF THE INVENTION 
       [0001]    1. Statement of the Technical Field 
         [0002]    The inventive arrangements relate to computer network security, and more particularly to systems for communicating between two or more logical subdivisions of a computer network where the network is dynamically maneuverable to defend against malicious attacks. 
         [0003]    2. Description of the Related Art 
         [0004]    The central weakness of current cyber infrastructure is its static nature. Assets receive permanent or infrequently-changing identifications, allowing adversaries nearly unlimited time to probe networks, map and exploit vulnerabilities. Additionally, data traveling between these fixed entities can be captured and attributed. The current approach to cyber security places technologies such as firewalls and intrusion detection systems around fixed assets, and uses encryption to protect data en route. However, this traditional approach is fundamentally flawed because it provides a fixed target for attackers. In today&#39;s globally connected communications infrastructure, static networks are vulnerable networks. 
         [0005]    The Defense Advanced Research Projects Agency (“DARPA”) Information Assurance (“IA”) Program has performed initial research in the area of dynamic network defense. A technique was developed under the IA program to dynamically reassign Internet protocol (“IP”) address space feeding into a pre-designated network enclave for the purpose of confusing any would-be adversaries observing the network. This technique is called DYnamic Network Address Transformation (“DYNAT”). An overview of the DYNAT technology was presented in a paper by DARPA entitled “Dynamic Approaches to Thwart Adversary Intelligence” which was published in 2001. 
       SUMMARY OF THE INVENTION 
       [0006]    Embodiments of the present invention concern systems and methods for use in a node of a dynamic computer network. The methods involve: disabling at least one function performed by a data link layer software component thereof; receiving a data communication from the data link layer software component; identifying at least one identity parameter contained in the data communication which comprises a first false value specifying false information about the node or the data communication; obtaining a first true value for the identity parameter specifying true information about the node or the data communication; replacing the first false value with the first true value so as to generate a modified data communication; and forwarding the modified data communication to a network layer software component of the node for further processing. The identity parameter can include, but is not limited to, a port number, a Transmission Control Part (“TCP”) sequence number, or an Internet Protocol (“IP”) address. 
         [0007]    The methods also involve receiving a formatted data unit from the network layer software component. The formatted data unit comprises a transport layer header and a network layer header. Each of these headers includes true identity parameter values specifying true information about the node or the formatted data unit. Thereafter, a false identity parameter value is obtained for at least one identity parameter of the transport layer header or the network layer header which specifies false information about the node or the formatted data unit. The true identity parameter value is then replaced with the false identity parameter value so as to form a modified data unit. The modified data unit is forwarded to the data link layer software component of the node. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0008]    Embodiments will be described with reference to the following drawing figures, in which like numerals represent like items throughout the figures, and in which: 
           [0009]      FIG. 1  is an example of a computer network that is useful for understanding the present invention. 
           [0010]      FIG. 2  is an example of a module that can be used in the present invention for performing certain manipulations of identity parameters. 
           [0011]      FIG. 3  is a drawing that is useful for understanding a tool that can be used to help characterize the network in  FIG. 1 . 
           [0012]      FIG. 4  is an example of a dialog box of a Graphical User Interface (“GUI”) that can be used to select dynamic settings for modules in  FIG. 1 . 
           [0013]      FIG. 5  is an example of a dialog box of a GUI that can be used to select a sequence of active states and bypass states associated with each module in  FIG. 1 . 
           [0014]      FIG. 6  is a diagram that is useful for understanding the way in which a mission plan can be communicated to a plurality of modules in the network in  FIG. 1 . 
           [0015]      FIG. 7  is an example of a dialog box of a GUI that can be used to select a mission plan and communicate the mission plan to the modules as shown in  FIG. 6 . 
           [0016]      FIG. 8  is a flowchart that is useful for understanding the operation of a module in  FIG. 1 . 
           [0017]      FIG. 9  is a flowchart that is useful for understanding the operation of a Network Control Software Application (“NCSA”) in relation to creating and loading mission plans. 
           [0018]      FIG. 10  is a block diagram of a computer architecture that can be used to implement the modules in  FIG. 1 . 
           [0019]      FIG. 11  is a schematic illustration of a conventional protocol stack. 
           [0020]      FIG. 12  is a schematic illustration of a conventional packet. 
           [0021]      FIG. 13  is a schematic illustration of a Moving Target Technology (“MTT”) protocol stack. 
           [0022]      FIG. 14  is a schematic illustration of an MTT packet. 
           [0023]      FIG. 15  is a schematic illustration that is useful for understanding the operations of a module configured to translate identity parameters. 
           [0024]      FIGS. 16-17  each provide a flow diagram of an exemplary process for changing at least one identity parameter of a packet. 
           [0025]      FIG. 18  is a block diagram of a computer architecture that can be used to implement a Network Administration Computer (“NAC”) shown in  FIG. 1 . 
           [0026]      FIG. 19  is a schematic illustration of an exemplary MTT enabled network in which modules are implemented as software running on end nodes thereof. 
           [0027]      FIG. 20  is a schematic illustration of an exemplary client computer shown in  FIG. 19 . 
           [0028]      FIG. 21  is a schematic illustration of a protocol stack employed by a client computer of  FIG. 19 . 
           [0029]      FIG. 22  is a schematic illustration of protocol stack software employed by a client computer shown in  FIG. 19 . 
           [0030]      FIG. 23  is a flow diagram of an exemplary method for translating identity parameters of an MTT packet which is performed by protocol stack software of a client computer shown in  FIG. 19 . 
           [0031]      FIG. 24  is a flow diagram of an exemplary method for translating identity parameters of a formatted data unit which is performed by protocol stack software of a client computer shown in  FIG. 19 . 
       
    
    
     DETAILED DESCRIPTION 
       [0032]    The invention is described with reference to the attached figures. The figures are not drawn to scale and they are provided merely to illustrate the instant invention. Several aspects of the invention are described below with reference to example applications for illustration. It should be understood that numerous specific details, relationships, and methods are set forth to provide a full understanding of the invention. One having ordinary skill in the relevant art, however, will readily recognize that the invention can be practiced without one or more of the specific details or with other methods. In other instances, well-known structures or operations are not shown in detail to avoid obscuring the invention. The invention is not limited by the illustrated ordering of acts or events, as some acts may occur in different orders and/or concurrently with other acts or events. Furthermore, not all illustrated acts or events are required to implement a methodology in accordance with the invention. 
         [0033]    It should also be appreciated that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. Furthermore, to the extent that the terms “including”, “includes”, “having”, “has”, “with”, or variants thereof are used in either the detailed description and/or the claims, such terms are intended to be inclusive in a manner similar to the term “comprising.” 
         [0034]    Further, unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein. 
       Identity Agile Computer Network 
       [0035]    Referring now to  FIG. 1 , there is shown a diagram of an exemplary computer network  100  which includes a plurality of computing devices. The computing devices can include client computers  101 - 103 , NAC  104 , servers  111 ,  112 , network layer 2 switches  108 ,  109 , layer 3 switch  110 , and a bridge  115 . The client computers  101 - 103  can be any type of computing device which might require network services, such as a conventional tablet, notebook, laptop or desktop computer. The layer 3 switch  110  can be a conventional routing device that routes data packets between computer networks. The layer 2 switches  108 ,  109  are conventional hub devices (e.g., an Ethernet hub) as are well known in the art. Servers  111 ,  112  can provide various computing services utilized by client computers  101 - 103 . For example, the servers  111 ,  112  can be file servers which provide a location for shared storage of computer files used by client computers  101 - 103 . 
         [0036]    The communication media for the computer network  100  can be wired, wireless or both, but shall be described herein as a wired network for simplicity and to avoid obscuring the invention. The network will communicate data using a communication protocol. As is well known in the art, the communication protocol defines the formats and rules used for communicating data throughout the network. The computer network  100  in  FIG. 1  can use any communication protocol or combination of protocols which is now known or known in the future. For example, the computer network  100  can use the well known Ethernet protocol suite for such communications. Alternatively, the computer network  100  can make use of other protocols, such as the protocols of an internet protocol suite (often referred to as the TCP/IP suite), Synchronous Optical NETwork/Synchronous Digital Hierarchy (“SONET/SDH”) based protocols, or Asynchronous Transfer Mode (“ATM”) communication protocols. In some embodiments, one or more of these communication protocols can be used in combination. Although one network topology is shown in  FIG. 1 , the invention is not limited in this regard. Instead, any type of suitable network topology can be used, such as a bus network, a star network, a ring network or a mesh network. 
         [0037]    The invention generally concerns a method for communicating data in a computer network (e.g., in computer network  100 ), where data is communicated from a first computing device to a second computing device. Computing devices within the network are represented with multiple identity parameters. The phrase “identity parameters”, as used herein, can include items such as an IP address, a Media Access Control (“MAC”) address, a port number and so on. However, the invention is not limited in this regard, and the identity parameters can also include a variety of other information which is useful for characterizing a network node. The various types of identity parameters contemplated herein are discussed below in further detail. 
         [0038]    The inventive arrangements involve the use of MTT to manipulate one or more of such identity parameters for one or more computing devices within the computer network  100 . This technique disguises communication patterns and network addresses of such computing devices. The manipulation of identity parameters as described herein is generally performed in conjunction with data communications in the computer network  100 , i.e., when data is to be communicated from a first computer in the network (e.g., client computer  101 ) to a second computer in the network (e.g., client computer  102 ). Accordingly, the identity parameters that are manipulated can include those of a source computing device (i.e., the device from which the data originated) and the destination computing device (i.e., the device to which the data is being sent). The set of identity parameters that is communicated is referred to herein as an IDentity Parameter (“IDP”) set. This concept is illustrated in  FIG. 1 , which shows that an IDP set  120  is transmitted by client computer  101  as part of a data packet (not shown). 
         [0039]    The process according to the inventive arrangements involves selectively modifying at a first location within the computer network  100 , values contained in a data packet or datagram which specify one or more identify parameters of a source computing device and/or a destination computing device. The identity parameters are modified in accordance with a mission plan. The location where such modification is performed will generally coincide with the location of one module  105 - 107 ,  113 ,  114  of the computer network  100 . Referring once again to  FIG. 1 , it can be observed that the modules  105 - 107 ,  113 ,  114  are interposed in the computer network  100  between the various computing devices which comprise nodes in such network. In these locations, the modules  105 - 107 ,  113 ,  114  intercept data packet communications, perform the necessary manipulations of identity parameters, and retransmit the data packets along a transmission path. In alternative embodiments, the modules  105 - 107 ,  113 ,  114  can perform a similar function, but can be integrated directly into one or more of the computing devices. For example, the modules could be integrated into client computers  101 ,  102 ,  103 , servers  111 ,  112 , layer 2 switches  108 ,  109  and/or layer 3 switch  110 . In this scenario, the modules can comprise hardware that is added to the computing and/or software that is installed on the computing device  101 - 103 ,  108 - 112 . In some software embodiments, the modules are implemented as kernel mode software (e.g., as device drivers) that modifies the identity parameters. 
         [0040]    Additionally, the computer network  100  can be divided into a number of logical subdivisions, sometimes referred to as sub-networks or subnets, connected through layer 3 switch  110 . An enterprise network can be divided into a number of subnets for a variety of administrative or technical reasons including, but not limited to, hiding the topology of the network from being visible to external hosts, connecting networks utilizing different network protocols, separately administering network addressing schemes on the subnet level, enabling management of data traffic across subnets due to constrained data connections, and the like. Subnetting is well known in the art and will not be described in further detail. 
         [0041]    Referring again to  FIG. 1 , the computer network  100  is divided into two logical networks, namely a first logical network  130  and a second logical network  132 . The phrase “logical network”, as used herein, refers to any logical subdivision of a computer network. In an embodiment, logical networks  130 ,  132  are connected through layer 3 switch  110 . Layer 3 switch  110  is responsible for directing traffic between the logical networks, i.e., from client computer  101  to client computer  103 . Layer 3 switch  110  is also responsible for directing traffic from any host connected to the computer network  100  bound for a second network  124 . In the embodiment shown in  FIG. 1 , traffic routed from the computer network  100  to the second network  124  passes through bridge  115 . As with the modules above, the functionality of the bridge  115  could be integrated within layer 3 switch  110 . 
         [0042]    An example of a functional block diagram of a module  105  is shown in  FIG. 2 . Modules  106 ,  107 ,  113 ,  114  of  FIG. 1  can have a similar functional block diagram as that shown in  FIG. 2 , but it should be understood that the invention is not limited in this regard. As shown in  FIG. 2 , the module  105  has at least two data ports  201 ,  202 , each of which can correspond to a respective network interface device  204 ,  205 . Data received at data port  201  is processed at network interface device  204  and temporarily stored at an input buffer  210 . The processor  215  accesses the input data packets contained in input buffer  210  and performs any necessary manipulation of identity parameters as described herein. The modified data packets are passed to output buffer  212  and subsequently transmitted from data port  202  using network interface device  205 . Similarly, data received at data port  202  is processed at network interface device  205  and temporarily stored at an input buffer  208 . The processor  215  accesses the input data packets contained in input buffer  208  and performs any necessary manipulation of identity parameters as described herein. The modified data packets are passed to an output buffer  206  and subsequently transmitted from data port  201  using network interface device  204 . In module  105 , manipulation of identity parameters is performed by processor  215  in accordance with a mission plan  220  stored in a memory  218 . 
         [0043]    It will be understood from  FIG. 2  that the module  105  is preferably configured so that it operates bi-directionally. In such embodiments, the module  105  can implement different modification functions, depending on a source of a particular data packet. The dynamic modification function in the module  105  can be specified in the mission plan in accordance with a source computing device of a particular data packet. The module  105  can determine a source of data packets by any suitable means. For example, a source address of a data packet can be used for this purpose. 
         [0044]    During operation, the processor  215  will determine one or more false identity parameter values that are to be used in place of the true identity parameter values. The processor  215  will transform one or more true identity parameter values to one or more false identity parameter values which are preferably specified by a pseudorandom function. Following this transformation, the module  105  will forward the modified packet or datagram to the next node of the computer network  100  along a transmission path. At subsequent points in the communication path, an adversary who is monitoring such network communications will observe false or incorrect information about the identity of computing devices communicating on the computer network  100 . 
         [0045]    In a preferred embodiment, the false identity parameters that are specified by the pseudorandom function are varied in accordance with the occurrence of at least one proactive trigger event or at least one reactive trigger event. A proactive/reactive trigger event causes the processor  215  to use the pseudorandom function to generate a new set of false identity parameter values into which the true identity parameters are transformed. Accordingly, the proactive/reactive trigger event serves as a basis for the dynamic variation of the false identity parameters described herein. Proactive and reactive trigger events are discussed in more detail below. However, it should be noted that proactive/reactive trigger events for selecting a new set of false values for identity parameters can be based on at least one pre-defined rule. The rule comprises a statement that defines at least one proactive or reactive trigger event. In this regard, the user rule may implement a proactive triggering scheme or a reactive triggering scheme. A proactive triggering scheme comprises a time based scheme. A reactive triggering scheme comprises a user activation based scheme, a packet inspection based scheme, congestion level based scheme, a heuristic algorithm based scheme and/or a Network-Based Attack (“NBA”) analysis based scheme. Each of the listed schemes will be described in detail below. 
         [0046]    The transformation of identity parameters described above provides one way to maneuver a computer network  100  for purposes of thwarting a cyber attack. In a preferred embodiment, the mission plan  220  implemented by processor  215  will also control certain other aspects of the manner in which computer network  100  can maneuver. For example, the mission plan  220  can specify that a dynamic selection of identity parameters is manipulated. The dynamic selection can include a choice of which identity parameters are selected for modification, and/or a number of such identity parameters that are selected. This variable selection process provides an added dimension of uncertainty or variation which can be used to further thwart an adversary&#39;s effort to infiltrate or learn about a computer network  100 . As an example of this technique, consider that during a first time period, the module  105  can modify a destination IP address and a destination MAC address of each data packet. During a second time period, the module  105  could manipulate the source IP address and a source host name in each data packet. During a third period of time, the module  105  could manipulate a source port number and a source user name. Changes in the selection of identity parameters can occur synchronously (i.e., all selected identity parameters are changed at the same time). Alternatively, changes in the selection of identity parameters can occur asynchronously (i.e., the group of selected identity parameters changes incrementally as individual identity parameters are added or removed from the group of selected identity parameters). 
         [0047]    A pseudorandom function is preferably used for determining the selection of identity values that are to be manipulated or transformed into false values. In other words, the module  105  will transform only the identity parameters selected by the pseudo-random function. In a preferred embodiment, the selection of identity parameters that are specified by the pseudorandom function is varied in accordance with the occurrence of a proactive/reactive trigger event. The proactive/reactive trigger event causes processor  215  to use a pseudorandom function to generate a new selection of identity parameters which are to be transformed into false identity parameters. Accordingly, the proactive/reactive trigger event serves as a basis for the dynamic variation of the selection of identity parameters described herein. Notably, the values of the identity parameters can also be varied in accordance with a pseudorandom algorithm. 
         [0048]    The module  105  is advantageously capable of also providing a third method of maneuvering the computer network for purposes of thwarting a cyber attack. Specifically, the mission plan  220  loaded in module  105  can dynamically vary the location within the network where the modification or transformation of the identity parameters takes place. Consider that modification of identity parameters in an IDP set  120  sent from client computer  101  to client computer  102  could occur in module  105 . This condition is shown in  FIG. 1 , where the identity parameters contained in IDP set  120  are manipulated in module  105  so that the IDP set  120  is transformed to a new or modified IDP set  122 . At least some of the identity parameters in the IDP set  122  are different as compared to the identity parameters in the IDP set  120 . But, the location where such transformation occurs is preferably also controlled by the mission plan. Accordingly, manipulation of the IDP set  120  could, for example, sometimes occur at module  113  or  114  of  FIG. 1 , instead of at module  105 . This ability to selectively vary the location where manipulation of identity parameters occurs adds a further important dimension to the maneuvering capability of the computer network  100 . 
         [0049]    The dynamic variation in the location where identity parameters are modified is facilitated by selectively controlling an operating state of each module  105 - 107 ,  113 ,  114  of  FIG. 1 . To that end, the operational states of each module  105 - 107 ,  113 ,  114  of  FIG. 1  preferably includes (1) an active state in which data is processed in accordance with a current mission plan, and (2) a by-pass state in which packets can flow through the module as if the module was not present. The location where the dynamic modification is performed is controlled by selectively causing certain modules of the computer network  100  to be in an active state and certain modules of the computer network  100  to be in a standby state. The location can be dynamically changed by dynamically varying the current state of the modules  105 - 107 ,  113 ,  114  of  FIG. 1  in a coordinated manner. 
         [0050]    The mission plan  220  can include a predefined sequence for determining the locations within the computer network  100  where the identity parameters are to be manipulated. Locations where identity parameters are to be manipulated will change in accordance with the predefined sequence at times indicated by a proactive/reactive trigger event. For example, the proactive/reactive trigger event can cause a transition to a new location for manipulation or transformation of identity parameters as described herein. Accordingly, the proactive/reactive trigger event serves as a basis for the occurrence of a change in the location where identity parameters are modified, and the predefined sequence determines where the new location will be. 
         [0051]    From the foregoing, it will be appreciated that a data packet is modified at a module  105 - 107 ,  113 ,  114  of  FIG. 1  to include false identity parameters. At some point within the computer network  100 , it is necessary to restore the identity parameters to their true values, so that the identity parameters can be used to properly perform their intended function in accordance with the particular network protocol. Accordingly, the inventive arrangements also includes dynamically modifying, at a second location (i.e., a second module), the assigned values for the identity parameters in accordance with the mission plan  220 . The modification at the second location essentially comprises an inverse of a process used at the first location to modify the identity parameters. The module at the second location can thus restore or transform the false value identity parameters back to their true values. In order to accomplish this action, the module at the second location must be able to determine at least (1) a selection of identity parameter value that are to be transformed, and (2) a correct transformation of the selected identity parameters from false values to true values. In effect, this process involves an inverse of the pseudorandom process or processes used to determine the identity parameter selection and the changes effected to such identity parameter values. The inverse transformation step is illustrated in  FIG. 1 , where the IDP set  122  is received at module  106 , and the identity parameter values in IDP set  122  are transformed or manipulated back to their original or true values. In this scenario, module  106  converts the identity parameters values back to those of IDP set  120 . 
         [0052]    Notably, a module must have some way of determining the proper transformation or manipulation to apply to each data communication it receives. In a preferred embodiment, this determination is performed by examining at least a source address identity parameter contained within the received data communication. For example, the source address identity parameter can include an IP address of a source computing device. Once the true identity of the source computing device is known, the module consults the mission plan (or information derived from the mission plan) to determine what actions it needs to take. For example, these actions could include converting certain true identity parameter values to false identity parameter values. Alternatively, these changes could include converting false identity parameter values back to true identity parameter values. 
         [0053]    Notably, there will be instances where the source address identity parameter information contained in a received data communication has been changed to a false value. In those circumstances, the module receiving the data communication will not immediately be able to determine the identity of the source of the data communication. However, the module which received the communication can in such instances still identify the source computing device. This is accomplished at the receiving module by comparing the false source address identity parameter value to a Look-Up-Table (“LUT”) which lists all such false source address identity parameter values in use during a particular time. The LUT also includes a list of true source address identity parameter values that correspond to the false source address values. The LUT can be provided directly by the mission plan  220  or can be generated by information contained within the mission plan  220 . In either case, the identification of a true source address identity parameter value can be easily determined from the LUT. Once the true source address identity parameter has been determined, then the module which received the data communication can use this information to determine (based on the mission plan) what manipulations to the identity parameters are needed. 
         [0054]    Notably, the mission plan  220  can also specify a variation in the second location where identity parameters are restored to their true values. For example, assume that the identity parameters are dynamically modified at a first location comprising module  105 . The mission plan can specify that the restoration of the identity parameters to their true values occurs at module  106  as described, but can alternatively specify that dynamic modification occur instead at module  113  or  114 . In some embodiments, the location where such manipulations occur is dynamically determined by the mission plan in accordance with a predefined sequence. The predefined sequence can determine the sequence of locations or modules where the manipulation of identity parameters will occur. 
         [0055]    The transition involving dynamic modification at different locations preferably occurs in accordance with a proactive/reactive trigger event. Accordingly, the predefined sequence determines the pattern or sequence of locations where data manipulations will occur, and the proactive/reactive trigger event serves as a basis for causing the transition from one location to the next. Proactive/reactive trigger events are discussed in more detail below; however, it should be noted that proactive/reactive trigger events can be based on at least one pre-defined rule. The rule comprises a statement that defines at least one proactive/reactive trigger event. In this regard, the rule may implement proactive triggering schemes or reactive triggering schemes. A proactive triggering scheme comprises a time based scheme. A reactive triggering scheme comprises a user activation based scheme, a packet inspection based scheme, a congestion level based scheme, a heuristic algorithm based scheme and/or an NBA analysis based scheme. Each of the listed schemes will be described below in detail. Control over the choice of a second location (i.e., where identity parameters are returned to their true values) can be effected in the same manner as described above with regard to the first location. Specifically, operating states of two or more modules can be toggled between an active state and a bypass state. Manipulation of identity parameters will only occur in the module which has an active operating state. The module with a bypass operating state will simply pass data packets without modification. 
         [0056]    Alternative methods can also be used for controlling the location where manipulation of identity parameters will occur. For example, a network administrator can define in a mission plan several possible modules where identity parameters can be converted from true values to false values. Upon the occurrence of a proactive/reactive trigger event, a new location can be selected from among the several modules by using a pseudorandom function, and using a trigger time as a seed value for the pseudorandom function. If each module implements the same pseudorandom function using the same initial seed values then each module will calculate the same pseudorandom value. The trigger time can be determined based on a clock time, such as a GPS time or system clock time). In this way, each module can independently determine whether it is currently an active location where manipulation of identity parameters should occur. Similarly, the network administrator can define in a mission plan several possible modules where dynamic manipulation returns the identity parameters to their correct or true values. The selection of which module is used for this purpose can also be determined in accordance with a trigger time and a pseudorandom function as described herein. Other methods are also possible for determining the location or module where identity parameter manipulations are to occur. Accordingly, the invention is not intended to be limited to the particular methods described herein. 
         [0057]    Notably, varying the position of the first and/or second locations where identity functions are manipulated will often result in varying a physical distance between the first and second location along a network communication path. The distance between the first and second locations is referred to herein as a distance vector. The distance vector can be an actual physical distance along a communication path between the first and second location. However, it is useful to think of the distance vector as representing the number of network nodes that are present in a communication path between the first and second locations. It will be appreciated that dynamically choosing different positions for the first and second locations within the network can have the effect of changing the number of nodes between the first and second locations. For example, in  FIG. 1 , the dynamic modification of identity parameters are implemented in selected ones of the modules  105 ,  106 ,  107 ,  113 ,  114 . The modules actually used to respectively implement the dynamic modification is determined as previously described. If module  105  is used for converting identity parameters to false values and module  106  is used to convert them back to true values, then there are three network nodes ( 108 ,  110 ,  109 ) between modules  105  and  106 . But if module  113  is used to convert to false values and module  114  is used to convert the identity parameters back to true values, then there is only one network node  110  between modules  113  and  114 . Accordingly, it will be appreciated that dynamically changing the position of locations where dynamic modification occurs can dynamically vary the distance vector. This variation of the distance vector provides an added dimension of variability to network maneuvering or modification as described herein. 
         [0058]    In the present invention, the manipulation of identity parameter values, the selection of identity parameters, and the locations where these identity parameters is each defined as a maneuvering parameter. Whenever a change occurs in one of these three maneuvering parameters, it can be said that a network maneuver has occurred. Any time one of these three maneuvering parameters is changed, we can say that a network maneuver has occurred. In order to most effectively thwart an adversary&#39;s efforts to infiltrate a computer network  100 , network maneuvering is preferably controlled by means of a pseudorandom process as previously described. Those skilled in the art will appreciate that a chaotic process can also be used for performing this function. Chaotic processes are technically different as compared to pseudorandom functions, but for purposes of the present invention, either can be used, and the two are considered equivalent. In some embodiments, the same pseudorandom process can be used for dynamically varying two or more of the maneuvering parameters. However, in a preferred embodiment of the invention, two or more different pseudorandom processes are used so that two or more of these maneuvering parameters are modified independently of the others. 
       Proactive and Reactive Trigger Events 
       [0059]    As noted above, the dynamic changes to each of the maneuvering parameters is controlled by at least one proactive trigger or reactive trigger. A proactive trigger is a pre-defined event that causes a change to occur in relation to the dynamic modifications described herein. In contrast, a reactive trigger is a purely spontaneous or user initiated event that causes a change to occur in relation to the dynamic modifications described herein. Stated differently, it can be said that the proactive or reactive trigger causes the network to maneuver in a new way that is different than at a previous time (i.e., before the occurrence of the proactive or reactive trigger). For example, during a first period of time, a mission plan or security model can cause an IP address to be changed from value A to value B; but after the proactive/reactive trigger event, the IP address can instead be changed from value A to value C. Similarly, during a first period of time a mission plan or security model can cause an IP address and a MAC address to be modified; but after the proactive/reactive trigger event, the mission plan or security model can instead cause a MAC address and a user name to be modified. 
         [0060]    In its simplest form a proactive trigger event can be based on a time based scheme. In a time based scheme, a clock time in each module could serve as a trigger. For example, a trigger event could be defined as occurring at the expiration of every N (e.g., sixty) second time interval. For such an arrangement, one or more of the maneuvering parameters could change every N seconds in accordance with a predetermined clock time. In some embodiments, all of the maneuvering parameters can change concurrently so that the changes are synchronized. In a slightly more complex embodiment, a time-based trigger arrangement can also be used, but a different unique trigger time interval can be selected for each maneuvering parameter. Thus, false identity parameter values could be changed at time interval X, a selection of identity parameters would change in accordance with a time interval Y, and a location where such changes are performed would occur at time interval Z, where X, Y and Z are different values. 
         [0061]    It will be appreciated that in embodiments of the invention which rely upon clock time as a trigger mechanism, it is advantageous to provide synchronization as between the clocks in various modules  105 ,  106 ,  107 ,  113 ,  114  to ensure that packets are not lost or dropped due to unrecognized identity parameters. Synchronization methods are well known and any suitable synchronization mechanism can be used for this purpose. For example, the modules could be synchronized by using a highly accurate time reference such as a GPS clock time. Alternatively, a unique wireless synchronization signal could be broadcast to each of the modules from a central control facility. 
         [0062]    In its simplest form a reactive trigger can be based on a user activation based scheme, a packet inspection based scheme, a congestion level based scheme, a heuristic algorithm based scheme and/or an NBA analysis based scheme. In the user activation based scheme, a user-software interaction defines a trigger event. For example, a trigger event occurs when a user of a computing device (e.g., computing device  101 - 103  of  FIG. 1 ) depresses a given button of a user interface. 
         [0063]    The packet inspection based scheme can involve analyzing a packet to obtain an identifier identifying an origin of the packet, a destination of the packet, a group to which the origin or destination belong, and/or a type of payload contained in the packet. The packet inspection based scheme can also involve analyzing the packet to determine whether a code word is contained therein. Techniques for achieving such a packet inspection are well known in the art. Any such technique that is now known or known in the future can be used with the present invention without limitation. In some embodiments, a reactive trigger event occurs when a value of the identifier matches a predefined value. 
         [0064]    In the packet inspection scenarios, the inclusion of a particular type of content in a packet serves as a trigger or as a parameter for selecting a timing scheme on which a trigger is based. For example, a trigger event could be defined as occurring (a) when a particular person of an entity (e.g., a commander of a military unit) communicates information to other members of the entity, and/or (b) when a particular code word is contained within the packet. Alternatively or additionally, a trigger event could be defined as occurring at the expiration of every N second time interval as defined by a timing scheme selected in accordance with a particular packet inspection application, where N is an integer. In this regard, it should be understood that in some embodiments a first timing scheme can be selected (a) when a first person of an entity (e.g., a commander of a military unit) requests a communication session with other members of the entity or (b) when a particular code word exists within a packet. A second different timing scheme can be selected (a) when a second person of an entity (e.g., a lieutenant commander of a military unit) requests a communication session with other members of the entity or (b) when a second code word exits within a packet, and so on. Embodiments of the present invention are not limited to the particularities of the above provided examples. In this regard, it should be understood that other content included in a packet can define a trigger event. For example, if the payload of a packet includes sensitive or confidential information, then a new mission plan or security model can be selected in accordance with the level of sensitivity or confidentiality of said information. 
         [0065]    For such time-based trigger arrangements, one or more of the maneuvering parameters could change every N (e.g., 60) seconds in accordance with a predetermined clock time. In some embodiments, all of the maneuvering parameters can change concurrently so that the changes are synchronized. In a slightly more complex embodiment, a time-based trigger arrangement can also be used, but a different unique trigger time interval can be selected for each maneuvering parameter. Thus, false identity parameter values could be changed at time interval X, a selection of identity parameters would change in accordance with a time interval Y, and a location where such changes are performed would occur at time interval Z, where X, Y and Z are different values. 
         [0066]    The congestion level based scheme can involve: monitoring and tracking the level of congestion within a computer network; comparing a current level of congestion with a threshold value; and selecting a mission plan or security model from a plurality of mission plans/models based on the results of the comparison. In some scenarios, a new mission plan or security model is selected when the current level of congestion is equal to, greater than or less than the threshold value. In this way, a mission plan or security model change occurs at apparently erratic time intervals based on changes in the level of congestion within a computer network. 
         [0067]    The heuristic algorithm based scheme can involve analyzing a network to determine a state thereof. Such a network analysis can involve monitoring traffic patterns (e.g., the number of users), protocol patterns, and/or entropy patterns (i.e., who is communicating with who) of a network at particular times of a day. A traffic pattern can be determined by collecting information about network equipment usage (e.g., a processor&#39;s usage) and a number of connections that exist from a network device (e.g., a network server). The collected information can be compared against the contents of a pre-defined table or matrix to identify which of a plurality of possible traffic patterns currently exists within a computer network. Based at least on the results of this comparison operation, a new mission plan or security model can be selected from a plurality of mission plans and/or security models for utilization in the computer network. 
         [0068]    In some heuristic scenarios, the mission plans and/or security models can be configured such that a constant high level of traffic is maintained within a computer network despite changes in the amount of actual traffic therein. The constant high level of traffic is maintained by adjusting (i.e., increasing or decreasing) a noise level of a network in accordance with the amount of actual traffic therein. Consequently, the amount of actual traffic and the type of traffic pattern at any given time is masked. 
         [0069]    A protocol pattern can be determined by collecting information about user activities related to network resources. Such information can include, but is not limited to, a history of user activities for at least one user of a computer network, times that user activities start, times that user activities stop, times that user activities have elapsed, and information identifying concurrent user activities being performed by at least one user of a computer network. The collected information can be analyzed to determine if a certain protocol pattern currently exists. If it is determined that a particular protocol pattern currently exists, then a new mission plan or security model can be selected from a plurality of mission plans/models for utilization in the computer network. In this way, a mission plan or security model change occurs at apparently erratic time intervals based on changes in protocol patterns (more particularly, changes in user activities). 
         [0070]    The entropy pattern can be determined by collecting information about who is communicating with each other over the computer network. Based on the collected information, a new mission plan or security model is selected from a plurality of mission plans/models for utilization in the computer network. In this scenario, a mission plan or security model change occurs at apparently erratic time intervals based on changes of the parties participating in communication sessions. 
         [0071]    The NBA analysis is performed for purposes of determining a potential security threat, the level of an NBA, a type of an NBA, and/or the number of NBA attacks currently being waged on a computer network. Such NBA analyses are well known in the art, and therefore will not be described herein. Still, it should be understood that such NBA analyses can involve: monitoring and tracking attack events within a computer network; and performing LUT operations for purposes of: determining if there is a potential security threat; and/or determining the level of an NBA attack and/or the type of an NBA attack. Any NBA analysis technique that is now known or known in the future can be used with the present invention without limitation. Once the NBA analysis is completed, a new mission plan or security model can be selected from a plurality of mission plans/models for utilization in the computer network based on the results of the NBA analysis. For example, if it has been determined that an NBA is a low level NBA and/or is of a first type, then a first mission plan or security model is selected from a plurality of mission plans or security models. In contrast, if it has been determined that the NBA is a high level NBA and/or is of a second type, then a second different mission plan or security model is selected from the plurality of mission plans or security models. In this scenario, a mission plan or security model change occurs at apparently erratic time intervals based on changes in the level of NBA attacks and/or the types of NBA attacks. Additionally or alternatively, a new mission plan or security model can be selected when two or more NBA attacks of the same or different levels and/or types are currently being waged on the computer network. In this scenario, a mission plan or security model change occurs at apparently erratic time intervals based on changes in the number of attacks currently being performed. 
         [0072]    In embodiments of the present invention, an NBA can be identified by a network security software suite. Alternatively, the NBA can be identified upon the receipt of a data packet at a module  105 ,  106 ,  107 ,  113 ,  114  where the packet contains one or more identity parameters that are inconsistent with the present state of network maneuvering. Regardless of the basis for identifying an NBA, the existence of such NBA can serve as a reactive trigger event as described above. 
         [0073]    Proactive/reactive trigger events based on the above described schemes can cause the same types of network maneuvers. For example, false identity parameters, the selection of identity parameters and the locations of identity parameter transformations could remain stable (i.e., unchanged) except in the case where one or more of the following is detected: a clock time; a packet having a particular origin or destination; a code word contained in a packet; secret or confidential information contained in a packet; a particular level of congestion; a particular traffic pattern; a particular protocol pattern; a particular entropy pattern; a security threat; an NBA of a particular level and/or type; and a particular number of NBAs currently being waged on a computer network. Such an arrangement might be chosen, for example, in computer networks where frequent network maneuvering is desirable so as to increase the security thereof. 
         [0074]    Alternatively, proactive/reactive trigger events based on the above described schemes can cause different types of network maneuvers. In such embodiments, a trigger event based on the results of an NBA analysis can have a different effect on the network maneuvering as compared to a trigger event based on the results of a packet inspection and/or a heuristic algorithm. For example, an NBA-based trigger event can cause strategic or defensive changes in the network maneuvering so as to more aggressively counter such NBAs. The precise nature of such measures can depend on the nature of the threat, but can include a variety of responses. For example, different pseudorandom algorithms can be selected, and/or the number of identity parameters selected for manipulation in each IDP set  120  can be increased. Also, the response can include increasing a frequency of network maneuvering. Thus, more frequent changes can be made with respect to (1) the false identity parameter values, (2) the selection of identity parameters to be changed in each IDP set, and/or (3) the position of the first and second locations where identity parameters are changed. Accordingly, the network maneuvering described herein provides a method for changing a mission plan or security model in a purely spontaneous manner based on a variety of factors, thereby increasing the security thereof. 
       Mission Plans 
       [0075]    According to a preferred embodiment of the invention, the network maneuvering described herein is controlled in accordance with a mission plan. A mission plan is a schema that defines and controls maneuverability within the context of a network and at least one security model. As such, the mission plan can be represented as a data file that is communicated from the NAC  104  to each module  105 - 107 ,  113 - 114  of  FIG. 1 . The mission plan is thereafter used by each module to control the manipulation of identity parameters and coordinate its activities with the actions of the other modules in the network. 
         [0076]    According to a preferred embodiment, the mission plan can be modified from time to time by a network administrator to update or change the way in which the network maneuvers to thwart potential adversaries. As such, the mission plan provides a network administrator with a tool that facilitates complete control over the time, place and manner in which network maneuvering will occur within the network. Such update ability allows the network administrator to tailor the behavior of the computer network to the current operating conditions and more effectively thwart adversary efforts to infiltrate the network. Multiple mission plans can be defined by a user and stored so that they are accessible to modules within the network. For example, the multiple mission plans can be stored at NAC  104  and communicated to modules as needed. Alternatively, a plurality of mission plans can be stored on each module and can be activated as necessary or desirable to maintain security of the network. For example, if the network administrator determines or suspects that an adversary has discovered a current mission plan for a network, the administrator may wish to change the mission plan. Effective security procedures can also dictate that the mission plan be periodically changed. 
         [0077]    The process of creating a mission plan can begin by modeling the computer network  100 . The creation of the model is facilitated by an NCSA executing on a computer or server at the network command center. For example, in the embodiment shown in  FIG. 1 , the NCSA can execute on NAC  104 . The network model preferably includes information which defines data connections and/or relationships between various computing devices included in the computer network  100 . The NCSA will provide a suitable interface which facilitates entry of such relationship data. According to one embodiment, the NCSA can facilitate entry of data into tables which can be used to define the mission plan. However, in a preferred embodiment, a GUI is used to facilitate this process. 
         [0078]    Referring now to  FIG. 3 , the NCSA can include a network topography model generator tool. The tool is used to assist the network administrator in defining the relationship between each of the various components of the networks. The network topography tool provides a workspace  300  in which an administrator can drag and drop network components  302 , by using a cursor  304 . The network administrator can also create data connections  306  between various network components  302 . As part of this modeling process, the network administrator can provide network address information for the various network components, including the modules  105 - 107 ,  113 ,  114  of  FIG. 1 . 
         [0079]    Once the network has been modeled, it can be saved and used by the network administrator to define the manner in which the various modules  105 - 107 ,  113 ,  114  behave and interact with one another. Referring now to  FIG. 4 , the NCSA can generate a dialog box  400  of which can be used to further develop a mission plan. A drop-down menu  432  can be used to select the particular module (e.g., module  105  of  FIG. 1 ) to which the settings in dialog box  400  are to be applied. Alternatively, the network administrator can use drop-down menu  432  to indicate that the settings in dialog box  400  are intended to be applied to all modules within the network (e.g., by selecting the command “All” in the drop-down menu  432 ). The process can continue by specifying whether a fixed set of identity parameters will always be modified in each of the modules, or whether the set of identity parameters that are manipulated shall be dynamically varied. If the selection or set of identity parameters that are to be manipulated in the modules is intended to be dynamically varied, the network administrator can mark check-box  401  to indicate that preference. If the check-box  401  is not marked, then the set of identity parameters to be varied is a fixed set that does not vary over time. 
         [0080]    The dialog box  400  includes tabs  402 ,  404 ,  406  which allow a user to select the particular identity parameter that he/she wants to work with for purposes of creating a mission plan. For purposes of this disclosure, the dialog box  400  facilitates dynamic variation of only three identity parameters. Specifically, these include the IP address, MAC address and port address. More or fewer identity parameters can be dynamically varied by providing additional tabs, but the three identity parameters noted are sufficient to explain the inventive concepts. In  FIG. 4 , the user has selected the tab  402  to work with the IP address type of identity parameter. Within tab  402 , a variety of user interface controls  408 - 420  are provided for specifying the details relating to the dynamic variation of IP addresses within the selected module. More or fewer controls can be provided to facilitate the dynamic manipulation of the IP address type, and the controls shown are merely provided to assist the reader in understanding the concept. In the example shown, the network administrator can enable dynamic variation of IP addresses by selecting (e.g., with a pointing device such as a mouse) the check-box  408  marked: “Enable IP Address Hopping”. Similarly, the network administrator can indicate whether the source address, destination address or both are to be varied. In this example, the source and destination address boxes  410 ,  412  are both marked, indicating that both types of addresses are to be changed. The range of allowed values for the source and destination addresses can be specified by the administrator in list boxes  422 ,  424 . 
         [0081]    The particular pseudorandom process used to select false IP address values is specified by selecting a pseudorandom process. This selection is specified in boxes  414 ,  415 . Different pseudorandom processes can have different levels of complexity for variable degrees of true randomness, and the administrator can choose the process that best suits the needs of the computer network  100 . 
         [0082]    Dialog box  400  also allows a network administrator to set the trigger type to be used for the dynamic variation of the IP address identity parameter. In this example, the user has selected box  416 , indicating that a time based trigger is to be used for determining when to transition to new false IP address values. Moreover, checkbox  418  has been selected to indicate that the time based trigger is to occur on a periodic basis. Slider  420  can be adjusted by the user to determine the frequency of the periodic time based trigger. In the example shown, the trigger frequency can be adjusted between six trigger occurrences per hour (trigger every ten minutes) and one hundred twenty trigger occurrences per hour (trigger every thirty seconds). In this example, selections are available for other types of triggers as well. For example, dialog box  402  includes check boxes  428 ,  430  by which the network administrator can select an event-based trigger. Several different specific event types can be selected to form the basis for such event-based triggers (e.g., Event type 1, Event type 2, etc.). These event types can include the detection of: a packet having a particular origin or destination; a code word contained in a packet; secret or confidential information contained in a packet; a particular level of congestion; a particular traffic pattern; a particular protocol pattern; a particular entropy pattern; a security threat; an NBA of a particular level and/or type; and a particular number of NBAs currently being waged on a computer network. In  FIG. 4 , tabs  404  and  406  are similar to tab  402 , but the controls therein are tailored to the dynamic variation of the MAC address and port value rather than the IP address. Additional tabs could be provided for controlling the dynamic variation of other types of identity parameters. 
         [0083]    The mission plan can also specify a plan for dynamically varying the location where identity parameters are modified. In some embodiments, this variable location feature is facilitated by controlling a sequence that defines when each module is in an active state or a bypass state. Accordingly, the mission plan advantageously includes some means of specifying this sequence. In some embodiments of the invention, this can involve the use of defined time intervals or time slots, which are separated by the occurrence of a trigger event. 
         [0084]    Referring now to  FIG. 5 , a dialog box  500  can be provided by the NCSA to facilitate coordination and entry of location sequence and timing information. Dialog box  500  can include a control  502  for selecting a number of time slots  504   1 - 504   n  which are to be included within a time epoch  506 . In the example illustrated, the network administrator has defined four time slots per timing epoch. The dialog box  500  can also include a table  503  which includes all modules in the computer network  100 . For each module listed, the table includes a graphical representation of available time slots  504   1 - 504   4  for one timing epoch  506 . Recall that dynamic control over the location where identity parameters are manipulated is determined by whether each module is in an active or bypass operating states. Accordingly, within the graphical user interface, the user can move a cursor  508  and make selections to specify whether a particular module is in an active or bypass mode during each time slot. In the example shown, module  105  is active during time slot  504   1  and  504   3 , but is in a bypass mode during time slots  504   2 ,  504   4 . Conversely, module  113  is active during time slots  504   2 ,  504   4 , but is in bypass mode during time slots  504   1  and  504   3 . With reference to  FIG. 1 , this means that manipulation of identity parameters occurs at a location associated with module  105  during time slots  504   1  and  504   3 , but occurs instead at module  113  during time slots  504   2 ,  504   4 . 
         [0085]    In the example shown in  FIG. 5 , the network administrator has elected to have module  114  always operate in an active mode (i.e., module  114  is active during all time slots). Accordingly, for data communications transmitted from client computer  101  to client computer  103 , data packets will alternately be manipulated in modules  105 ,  113 , but will always be manipulated at module  114 . Finally, in this example, the network administrator has elected to maintain modules  106  and  107  in a bypass mode during time slots  504   1 - 504   4 . Accordingly, no manipulation of identity parameters will be performed at these modules during any of the defined time slots. Once the module timing has been defined in dialog box  500 , the network administrator can select the button  510  to store the changes as part of an updated mission plan. The mission plan can be saved in various formats. In some embodiments, the mission plan can be saved as a simple table or other type of defined data structure that can be used by each module for controlling the behavior of the module. 
       Distribution and Loading of Mission Plans 
       [0086]    The distribution and loading of mission plans as disclosed herein will now be described in further detail. Referring once again to  FIG. 1 , it can be observed that the modules  105 - 107 ,  113 ,  114  are distributed throughout the computer network  100  at one or more locations. 
         [0087]    The modules are integrated within the communications pathways to intercept communications at such locations, perform the necessary manipulations, and forward data to other computing devices within the network. With the foregoing arrangement, any necessary maintenance of the modules described herein (e.g., maintenance to update a mission plan) will have the potential to disrupt network communications while the modules are replaced or reprogrammed. Such disruptions are undesirable in many situations where reliability and availability of network services is essential. For example, uninterrupted network operation can be essential for computer networks used by military, emergency services and businesses. 
         [0088]    In order to ensure uninterrupted network operations, each module preferably has several operating states. These operating states include (1) an off state in which the module is powered down and does not process any packets, (2) an initialization state in which the module installs software scripts in accordance with the mission plan, (3) an active state in which data is processed in accordance with a current mission plan, and (4) a by-pass state in which packets can flow through the module as if the module was not present. The module is configured so that, when it is in the active state or the by-pass state, the module can receive and load an updated mission plan provided by a network administrator. The module operating states can be manually controlled by the network administrator by means of the NCSA executing, for example, on NAC  104 . For example, the user can select operating states for various modules through the use of a graphical user interface control panel. Commands for controlling the operating states of the network are communicated over the computer network  100 , or can be communicated by any other suitable means. For example, a separate wired or wireless network (not shown) can be used for that purpose. 
         [0089]    The mission plan can be loaded directly at the physical location of each module, or it can be communicated to the module from the NCSA. This concept is illustrated in  FIG. 6 , which shows mission plans  604  being communicated from NCSA  602  to each of the modules  105 - 107 ,  113 ,  114  over a communication medium  606 . In the example shown, the NCSA software application is executing on NAC  104  operated by a network administrator. The communication medium can in some embodiments include in-band signaling using computer network  100 . Alternatively, an out-of-band network (e.g., a separate wireless network) can be used as the communication medium  606  to communicate the updated mission plan from the NCSA to each module. As shown in  FIG. 7 , the NCSA can provide a dialog box  700  to facilitate selection of one of several mission plans  702 . Each of these mission plans  702  can be stored on NAC  104 . The network administrator can select from one of the several mission plans  702 , after which they can activate a “Send Mission Plan” button  704 . Alternatively, a plurality of mission plans can be communicated to each module and stored there. In either scenario, the user can choose one of the defined mission plans to activate. 
         [0090]    In response to the command to send the mission plan, the selected mission plan is communicated to the modules while they are in an active state in which they are configured for actively performing dynamic modification of identity parameters as described herein. Such an arrangement minimizes the time during which the network operates in the clear and without manipulating identity parameters. However, the updated mission plan can also be communicated to the modules while they are in the by-pass mode, and this approach may be desirable in certain cases. 
         [0091]    Once the mission plan is received by a module, it is automatically stored in a memory location within the module. Thereafter, the module can be caused to enter the by-pass state and, while still in that state, the module can load the data associated with the new mission plan. This process of entering into the by-pass state and loading the new mission plan data can occur automatically in response to receipt of the mission plan, or can occur in response to a command from the NCSA software controlled by the network administrator. The new mission plan preferably includes changes in the way that identity parameter values are varied. Once the new mission plan has been loaded, the modules  105 - 107 ,  113 , and  114  can be transitioned from the by-pass mode to the active mode in a synchronized way to ensure that data communication errors do not occur. The mission plan can specify a time when the modules are to return to the active mode, or the network administrator can use the NCSA to communicate a command to the various modules, directing them to enter into the active mode. The foregoing process of updating a mission plan advantageously allows changes in network security procedures to occur without disrupting communication among the various computing devices attached to the computer network  100 . 
         [0092]    The dynamic manipulation of various identity parameters at each module  105 ,  106 ,  107 ,  113 , and  114  is preferably controlled by the application software executing on each module  105 - 107 ,  113 ,  114 . However, the behavior of the application software is advantageously controlled by the mission plan. 
         [0093]    Referring now to  FIG. 8 , there is provided a flowchart which summarizes the operation of each module  105 - 107 ,  113 ,  114 . To avoid confusion, the process  800  is described with respect to communications in a single direction. For example, in the case of module  105 , the single direction could involve data transmitted from client computer  101  to hub  108 . In practice however, it is preferred that modules  105 - 107 ,  113 ,  114  operate bi-directionally. The process begins at step  802  when the module is powered up and continues to step  804  where module application software is initialized for executing the methods described herein. In step  806 , a mission plan is loaded from a memory location within the module. At this point, the module is ready to begin processing data and proceeds to do so at step  808 , where it accesses a data packet from an input data buffer of the module. In step  810 , the module checks to determine if it is in a bypass mode of operation. If so, the data packet accessed in step  808  is retransmitted in step  812  without any modification of the data packet. If the module is not in bypass mode, then it must be in its active mode of operation and continues on to step  814 . In step  814 , the module reads the data packet to determine the identity of a source node from which the data packet originated. In step  816 , it examines the packet to determine if the source node is valid. The specified source node can be compared to a list of valid nodes to determine if the specified source node is currently valid. If it is not a valid node then the packet is discarded in step  818 . In step  820 , the process checks to determine if a trigger event occurred. The occurrence of a trigger event will influence the selection of false identify values to use. Accordingly, in step  822 , the module determines the false identify values to use based on one or more of the trigger information, clock time and mission plan. The module then continues to step  826  where it manipulates identity parameters of the data packet. Once manipulations are complete, the data packet is re-transmitted to an adjacent node from the output port of the module. In step  830 , a determination is made as to whether the module has been commanded to power down. If so, the process ends at step  832 . In step  808 , the process continues and the next data packet is accessed from the module&#39;s input data buffer. 
         [0094]    Referring now to  FIG. 9 , there is provided a flowchart which summarizes the methods described herein for managing a dynamic computer network. The process begins in step  902  and continues to step  904 , where a network model is created (e.g., as shown and described in relation to  FIG. 3 ). In step  906 , a determination is made as to whether a new mission plan is to be created. If so, a new mission plan is created in step  908  and the process continues to step  910 , where the new mission plan is selected. Alternatively, if in step  906  a desired mission plan has already been created, then the method can continue directly to step  910  where an existing mission plan is selected. In step  912 , the mission plan is communicated to the modules (e.g., modules  105 - 107 ,  113 ,  114  of  FIG. 1 ), where the mission plan is stored in a memory location. When the network administrator is ready to implement the new mission model, a command is sent in step  914  which causes the modules to enter a standby mode as described herein. While the modules are in this standby mode, the mission plan is loaded at step  916 . Loading of the mission plan occurs at each module so that the mission plan can be used to control the operations of an application software executing on the module. In particular, the mission plan is used to control the way in which the application software performs dynamic manipulations of identity parameters. In step  918 , the mission modules are again caused to enter into an active operational mode in which each mission module performs manipulations of identity parameters in accordance with the mission plan. Steps  914 ,  916  and  918  can occur in response to specific commands sent from a network administrator, or can occur automatically at each module in response to receiving the mission plan in step  912 . After step  918 , the modules continue performing processing in accordance with the mission plan which has been loaded. In step  920 , the process continues by checking to determine if the user has indicated a desired to change the mission plan; if so, the process returns to step  906 , where it continues as described above. If there is no indication that the user or network administrator wishes to change an existing mission plan, then the process determines in step  922  whether it has been instructed to terminate. If so, the process terminates in step  924 . If no termination instruction is received, the process returns to step  920  and continues. 
         [0095]    Referring now to  FIG. 10 , there is provided a block diagram which shows a computer architecture of an exemplary module  1000  which can be used for performing the manipulation of identity parameters described herein. The module  1000  includes a processor  1012  (such as a Central Processing Unit (“CPU”)), a main memory  1020  and a static memory  1018 , which communicate with each other via a bus  1022 . The module  1000  can further include a display unit  1002 , such as a Liquid Crystal Display (“LCD”) to indicate the status of the module. The module  1000  can also include one or more network interface devices  1016 ,  1017  which allow the module to receive and transmit data concurrently on two separate data lines. The two network interface ports facilitate the arrangement shown in  FIG. 1 , where each module is configured to concurrently intercept and re-transmit data packets received from two separate computing devices on the network. 
         [0096]    The main memory  1020  includes a computer-readable storage medium  1010  on which is stored one or more sets of instructions  1008  (e.g., software code) configured to implement one or more of the methodologies, procedures, or functions described herein. The instructions  1008  can also reside, completely or at least partially, within the static memory  1018 , and/or within the processor  1012  during execution thereof by the module. The static memory  1018  and the processor  1012  also can constitute machine-readable media. In the various embodiments of the present invention a network interface device  1016  connected to a network environment communicates over the network using the instructions  1008 . 
         [0097]    The instructions  1008  cause the module  1000  to act as a translator of identity parameters between those of a packet-based static network and those of a packet-based MTT enabled network. A conventional protocol stack for the packet-based static network is provided in  FIG. 11 . According to the embodiment shown in  FIG. 11 , the protocol stack  1100  includes five layers  1102 ,  1104 ,  1106 ,  1108 ,  1110  specifying particular functions of nodes within the packet-based static network. Still, the invention is not limited in this regard. The protocol stack  1100  can include any number of layers in accordance with a particular packet-based static network application. For example, if an Open System Interconnection (“OSI”) protocol stack is employed by the static network then the protocol stack  1100  can further include a session layer and a presentation layer. 
         [0098]    Referring again to  FIG. 11 , the protocol stack  1100  provides a framework illustrating how information is passed from a software application installed in a first node of the static network (e.g., a client computer) to a software application installed in a second node of the static network (e.g., a client computer). The protocol stack  1100  is well known to persons skilled in the art. Thus, the protocol stack  1100  will not be described in detail herein. However, a brief discussion is provided below to assist a reader in understanding the identity parameter translation which is performed at least by the modules  105 - 108 ,  114  of  FIG. 1 . 
         [0099]    As shown in  FIG. 11 , the protocol stack  1100  is comprised of a physical layer  1102 , a data link layer  1104 , a network layer  1106 , a transport layer  1108 , and an application layer  1110 . The physical layer  1102  is comprised of firmware and/or hardware configured to send and receive data through a network. The data link layer  1104  provides transmission protocols for transferring data between network nodes. Such transmission protocols can include an Ethernet protocol (or an IEEE 802.3 protocol), a point-to-point protocol, an IEEE 802.11 protocol, an IEEE 802.15 protocol, an IEEE 802.16 protocol, and other such protocols. 
         [0100]    The data link layer  1104  can be comprised of two (2) sub-layers, namely a Logic Link Control (“LLC”) layer  1114  and a Media Access Control (“MAC”) layer  1112 . The LLC layer  1114  is comprised of firmware and/or hardware configured to multiplex protocols prior to being transmitted over the MAC layer  1112  and to demultiplex protocols subsequent to being transmitted and upon receipt. The LLC layer  1114  is also comprised of firmware and/or hardware configured to provide flow control of packets, detection of packets, and retransmission of dropped packets. 
         [0101]    The MAC layer  1112  is comprised of firmware and/or hardware configured to determine when to transmit communications and when to receive communications. In this regard, the MAC layer  1112  performs actions involving coordinating access to a shared radio channel and utilizing protocols that enhance communications over a wireless link. The term “protocol” as used herein refers to a set of rules defining how information is exchanged between network nodes. Such network nodes include, but are not limited to, the client computers, servers, routers, switches and bridges. The MAC layer  1112  provides transmission protocols for transferring data between network nodes. Such transmission protocols include MAC protocols. MAC protocols ensure that signals sent from different nodes across the same channel do not collide. 
         [0102]    The network layer  1106  is comprised of firmware configured to transfer data from one node to another node. In this regard, the network layer  1106  provides protocols for transferring data from one node to another node. The transmission protocols include routing protocols and forwarding protocols. Such transmission protocols include internet protocols, such as a version four of the internet protocol (“IPv4”), a version six of the internet protocol (“IPv6”), and internet security protocols (“IP Layer Security”). 
         [0103]    The transport layer  1108  is comprised of firmware configured to communicate data between end systems. In this regard, the transport layer  1108  provides transport protocols for transmission of data between end systems. Such transport protocols include a Transmission Control Protocol (“TCP’) and a User Datagram Protocol (“UDP”). The application layer  1110  is generally implemented only in firmware. The application layer  1110  provides signaling protocols for end-user applications, such as authentication applications, data syntax applications, quality of service applications, and end-user applications. 
         [0104]    Referring now to  FIG. 12 , there is provided a block diagram of a conventional packet  1200  of a static network. The packet  1200  is comprised of a preamble  1202 , a physical layer protocol header  1204 , a MAC layer protocol header  1206 , an LLC layer protocol header  1208 , a network layer protocol header  1210 , and a transport layer protocol header  1212 . The packet  1200  is also comprised of an application layer header  1214 , an application data  1216 , and a Frame Check Sequence (“FCS”)  1218 . The phrase “frame check sequence”, as used herein, refers to extra checksum characters added to a packet or a frame in a communication protocol for error detection and correction. Each of the listed components of the packet  1200  are well known to persons skilled in the art and are well defined in open industry standards of the Institute of Electrical and Electronics Engineers (“IEEE”) standard for local and metropolitan area networks and Internet Engineering Task Force (“IEFT”). Thus, such components will not be described in detail herein. 
         [0105]    However, it should be appreciated that the application data  1216  can be signaling protocol data, user data, or management data. The user data can include voice data, video data, or the like. It should also be appreciated that the application data  1216  is encapsulated between the application layer header  1214  and the FCS  1218 . The application layer header  1214  is encapsulated between the transport layer protocol header  1212  and the application data  1216 . Similarly, the transport layer protocol header  1212  is encapsulated between the network layer protocol header  1210  and the application layer header  1214 . Likewise, the network layer protocol header  1210  is encapsulated between the LLC layer protocol header  1208  and transport layer protocol header  1212 . The LLC layer protocol header  1208  is encapsulated between the MAC layer protocol header  1206  and the network layer protocol header  1210 . The MAC layer protocol header  1206  is encapsulated between the physical layer protocol header  1204  and the LLC layer protocol header  1208 . The physical layer protocol header  1204  is encapsulated between the preamble  1202  and the MAC layer protocol header  1206 . 
         [0106]    The transport layer protocol header  1212  comprises source and destination port numbers  1220 . A port is an application-specific software construct serving as a communications endpoint in a computer&#39;s operating system. A port is identified for each IP address and protocol by a sixteen bit number (i.e., a port number  1220 ). 
         [0107]    The transport layer protocol header  1212  also comprises a TCP sequence number  1222 . Two client computers communicating with each other on opposite sides of a TCP session will each maintain a TCP sequence number  1222 . The TCP sequence number  1222  allows each computer to track how much data it has communicated. The TCP sequence number is included in the TCP header portion of each packet which is communicated during the session. At the initiation of a TCP session, the initial sequence number value is randomly selected. 
         [0108]    The network layer protocol header  1210  comprises source and destination IP addresses  1224 . An IP address  1224  is a numerical identifier assigned to a computing device participating in a computer network where the network uses the well known internet protocol for communication. The IP address  1224  can be a thirty two bit number in an IPv4 system or one hundred twenty eight bit number in an IPv6 system. The IP address  1224  is a binary number, but is usually stored in a text file and displayed in a human-readable notation (e.g., 175.18.252.1. for IPv4 systems and 2003:db6:0:1234:0:469:6:1 for IPv6). 
         [0109]    In some embodiments, each IP address  1224  can be thought of as a single identity parameter. However, an IP address  1224  is generally defined as including at least two parts which include a network prefix  1228  and a host number  1230 . The network prefix  1228  identifies a network to which a data packet  1200  is to be communicated. The host number  1230  identifies the particular node within a Local Area Network (“LAN”). A sub-network (sometimes referred to as a subnet) is a logical portion of an IP network. Where a network is divided into two or more sub-networks, a portion of the host number  1230  of the IP address  1224  is used to specify a subnet number  1232 . For purposes of the present invention, the network prefix  1228 , the subnet number  1232  and the host number  1230  can each be considered to be a separate identity parameter. Since a source IP address and a destination IP address is contained in the network layer protocol header  1210 , there are a total of six different identity parameters in the header  1210 . 
         [0110]    The MAC layer protocol header  1206  comprises a MAC Address  1226 . A MAC address  1226  is a unique value assigned to a network interface device by a manufacturer and stored in an onboard ROM. The MAC address  1226  can include a forty-eight bit number or a sixty-four bit number depending on the protocol employed by the MAC layer  1112  of the protocol stack  1100 . 
         [0111]    The MTT enabled network employs protocols of an MTT protocol stack. A schematic illustration of an exemplary MTT protocol stack  1300  is provided in  FIG. 13 . As shown in  FIG. 13 , the MTT protocol stack  1300  comprises five layers  1302 - 1314  specifying particular functions of nodes within the MTT enable network. Notably, some of the layers  1302 ,  1310 ,  1314  are the same as those  1102 ,  1110 ,  1114  of the protocol stack  1100 . As such, the description provided above in relation to these layers  1102 ,  1110 ,  1114  is sufficient for understanding layers  1302 ,  1310 ,  1314  of  FIG. 13 . However, the MTT protocol stack  1300  comprises layers  1304 - 1308  which are different than those  1104 - 1108  of protocol stack  1100 . As such, a brief discussion of these layers will be provided below. 
         [0112]    The MTT data link layer  1304  can be comprised of two (2) sub-layers, namely an LLC layer  1314  and an MTT MAC layer  1312 . The LLC layer  1314  is the same as or substantially similar to the LLC layer  1114  of  FIG. 11 . As such, the description provided above in relation to layer  1114  is sufficient for understanding layer  1314 . The MTT MAC layer  1312  is different than the MAC layer  1112  of  FIG. 11 . In this regard, it should be understood that the MAC layer  1112  employs a static MAC address  1226  for each network interface device. In contrast, the MTT MAC layer  1312  employs a non-static MAC address (e.g., MTT MAC address  1426  of  FIG. 14 ) for each network interface device. The non-static MAC address is dynamically variable. For example, the non-static MAC address can be randomly or pseudo-randomly changed during operation of the MTT enabled network. 
         [0113]    The MTT network layer  1306  is different than the network layer  1106  of  FIG. 11 . In this regard, it should be understood that the network layer  1106  employs static IP addresses  1224 . In contrast, the IP addresses (e.g., MTT IP addresses  1424  of  FIG. 14 ) of the MTT network layer  1306  are non-static, i.e., they can be dynamically varied during operations of the MTT enabled network. For example, an IP address number can be changed in accordance with a pseudo-random process. 
         [0114]    The MTT transport layer  1308  is different than the transport layer  1108  of  FIG. 11 . The transport layer employs static port numbers  1220  and static TCP sequence numbers  1222 . In contrast, the port numbers (e.g., numbers  1420  of  FIG. 14 ) and TCP sequence numbers (e.g., numbers  1422  of  FIG. 14 ) employed by the MTT transport layer  1308  are non-static. In this regard, it should be understood that each of the non-static port numbers and sequence numbers can be changed in accordance with a random or pseudo-random process. 
         [0115]    Referring now to  FIG. 14 , there is provided a schematic illustration of an exemplary MTT packet  1400  of the MTT enabled network. The MTT packet  1400  is comprised of a preamble  1402 , a physical layer protocol header  1404 , an MTT MAC layer protocol header  1406 , an LLC layer protocol header  1408 , an MTT network layer protocol header  1410 , an MTT transport layer protocol header  1412 , an application layer header  1414 , application data  1416  and an FCS  1418 . Portions  1402 ,  1404 ,  1408 ,  1414 ,  1416 ,  1418  of the MTT packet  1400  are the same as or substantially similar to portions  1202 ,  1204 ,  1208 ,  1214 ,  1216 ,  1218  of  FIG. 12 . As such, the description provided above in relation to portions  1202 ,  1204 ,  1208 ,  1214 ,  1216 ,  1218  is sufficient for understanding portions  1402 ,  1404 ,  1408 ,  1414 ,  1416 ,  1418  of the MTT packet  1400 . However, portions  1406 ,  1410 ,  1412  are different than portions  1206 ,  1210 ,  1212  of  FIG. 12 . As such, each of the portions  1406 ,  1410 ,  1412  will be described herein. 
         [0116]    The MTT transport layer protocol header  1412  comprises MTT source and destination port numbers  1420 . A port is an application-specific software construct serving as a communications endpoint in a computer&#39;s operating system. A port is identified for each IP address and protocol by a sixteen bit number. The sixteen bit number is referred to in relation to an MTT enabled network as an MTT port number  1420 . Notably, each MTT port number  1420  is a non-static number (i.e., it can be changed by a module in accordance with a random or pseudo-random process). The MTT transport layer protocol header  1412  also comprises an MTT TCP sequence number  1422 . The MTT TCP sequence number  1422  is a non-static number. Manipulation of the MTT port number  1420  and the MTT TCP sequence number  1422  can be accomplished by simply modifying the TCP header information to change values thereof. 
         [0117]    The MTT network layer protocol header  1410  comprises source and destination MTT IP addresses  1424 . A value of each MTT IP address  1424  can be dynamically varied in accordance with a random or pseudo-random process. Each MTT IP address  1424  comprises an MTT prefix  1428  and an MTT host number  1430 . Each of these components  1428 ,  1430  can also be dynamically varied during operation of an MTT enabled network. Manipulation of the MTT IP addresses  1424 , the MTT prefix  1428  and the MTT host number  1430  can be achieved by simply modifying the IP header information of the MTT network layer protocol header  1410 . 
         [0118]    The MTT MAC layer protocol header  1406  comprises an MTT MAC Address  1426 . The MTT MAC address  1426  can be dynamically varied during operation of the MTT enabled network. Manipulation of the MTT MAC address  1426  can be achieved by simply modifying an Ethernet header information of the MTT MAC layer protocol header  1406 . 
         [0119]    Referring now to  FIG. 15 , there is provided a schematic illustration that is useful for understanding operations of the module  1000  when it is implemented as hardware. As shown in  FIG. 15 , the module  1000  performs operations in accordance with both protocol stacks  1200 ,  1400 . In this regard, the module  1000  is configured to communicate MTT packets  1400  to and from an MTT enabled network node  1502  (e.g., a node  104 - 109 ,  111  or  112  of  FIG. 1 ). The module  1000  is also configured to communicate conventional packets  1200  to and from a static enabled network node  1506  (e.g., a node  101 - 103 ,  110  or  115  of  FIG. 1 ). The module  1000  is further configured to convert conventional packets  1200  into MTT enabled packets  1400 , and vice versa. This packet conversion is achieved via an Identity Parameter Translation (“IPT”)  1504 . A process for achieving an IPT generally involves: de-encapsulating and re-encapsulating application layer portions  1214 ,  1216 ,  1414 ,  1416  of the packets  1200 ,  1400 ; or simply modifying header and/or trailer values of the packets  1200 ,  1400 . Methods for encapsulating/decapsulating packets and modifying packet content are well known in the art, and therefore are not be described herein. Any known method or to be known method for encapsulating/de-encapsulating packets and/or modifying packet content can be used with the present invention without limitation. Examples of such processes for achieving an IPT are illustrated in  FIGS. 16 and 17 . 
         [0120]    As shown in  FIG. 16 , an exemplary process  1600  begins at step  1602  and continues with step  1604 . In step  1604 , the application layer portions  1214 ,  1216  of the conventional packet  1200  are de-encapsulated by removing the preamble  1202  and headers  1204 - 1212  from the packet. In a next step  1606 , the packet components  1402 - 1414  are generated in accordance with the protocols of the MTT protocol stack  1300 . Thereafter, step  1608  is performed where the application layer portions  1214 ,  1216  are re-encapsulated so as to form an MTT packet  1400 . The re-encapsulation is achieved by appending the packet components  1402 - 1414  thereto. Upon completing step  1608 , the process  1600  ends or other processing is performed. 
         [0121]    As shown in  FIG. 17 , an exemplary process  1700  begins at step  1702  and continues with step  1704 . In step  1704 , the application layer portions  1414 ,  1416  of an MTT packet  1400  are de-encapsulated by removing the preamble  1402  and headers  1404 - 1412  from the packet  1400 . Next in step  1706 , the packet components  1204 - 1214  are generated in accordance with the protocols of the conventional protocol stack  1200 . In a next step  1708 , the application layer portions  1414 ,  1416  are re-encapsulated by appending the preamble  1202  and headers  1204 - 1214  thereto so as to form a conventional packet  1200 . 
         [0122]    Referring now to  FIG. 18 , there is shown an exemplary NAC  104  in accordance with the inventive arrangements. The NAC  104  can comprise various types of computing systems and devices, including a server computer, a client user computer, a Personal Computer (“PC”), a tablet PC, a laptop computer, a desktop computer, a control system or any other device capable of executing a set of instructions (sequential or otherwise) that specifies actions to be taken by that device. Further, while a single computer is illustrated in  FIG. 18 , the phrase “NAC” shall be understood to include any collection of computing devices that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein. 
         [0123]    Referring now to  FIG. 18 , the NAC  104  includes a processor  1812  (such as a CPU), a disk drive unit  1806 , a main memory  1820  and a static memory  1818 , which communicate with each other via a bus  1822 . The NAC  104  can further include a display unit  1802 , such as a video display (e.g., an LCD), a flat panel, a solid state display, or a Cathode Ray Tube (“CRT”). The NAC  104  can include a user input device  1804  (e.g., a keyboard), a cursor control device  1814  (e.g., a mouse) and a network interface device  1816 . 
         [0124]    The disk drive unit  1806  includes a computer-readable storage medium  1810  on which is stored one or more sets of instructions  1808  (e.g., software code) configured to implement one or more of the methodologies, procedures, or functions described herein. The instructions  1808  can also reside, completely or at least partially, within the main memory  1820 , the static memory  1818 , and/or within the processor  1812  during execution thereof. The main memory  1820  and the processor  1812  also can constitute machine-readable media. 
         [0125]    Those skilled in the art will appreciate that the module architecture illustrated in  FIGS. 10-17  and the NAC architecture in  FIG. 18 , each represent merely one possible example of a computing device that can be used respectively for performing the methods described herein. However, the invention is not limited in this regard and any other suitable computing device architecture can also be used without limitation. Dedicated hardware implementations including, but not limited to, application-specific integrated circuits, programmable logic arrays, and other hardware devices can likewise be constructed to implement the methods described herein. Applications that can include the apparatus and systems of various embodiments broadly include a variety of electronic and computer systems. Some embodiments may implement functions in two or more specific interconnected hardware devices with related control and data signals communicated between and through the modules, or as portions of an application-specific integrated circuit. Thus, the exemplary system is applicable to software, firmware, and hardware implementations. 
         [0126]    In accordance with various embodiments of the present invention, the methods described herein are stored as software programs in a computer-readable storage medium and are configured for running on a computer processor. Furthermore, software implementations can include, but are not limited to, distributed processing, component/object distributed processing, parallel processing, virtual machine processing, which can also be constructed to implement the methods described herein. 
         [0127]    While the computer-readable storage medium  1010 ,  1810  is shown in  FIGS. 10 and 18  to be a single storage medium, the term “computer-readable storage medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “computer-readable storage medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure. 
         [0128]    The term “computer-readable medium” shall accordingly be taken to include, but is not be limited to, solid-state memories such as a memory card or other package that houses one or more read-only (non-volatile) memories, random access memories, or other re-writable (volatile) memories; magneto-optical or optical mediums such as a disk or tape. Accordingly, the disclosure is considered to include any one or more of a computer-readable medium as listed herein and to include recognized equivalents and successor media, in which the software implementations herein are stored. 
         [0129]    Although the modules were described above as comprising standalone hardware devices, the present invention is not limited in this regard. The modules can alternatively be implemented as software that runs on end nodes of an MTT enabled network. An example of such an MTT enabled network is schematically illustrated in  FIG. 19 . As shown in  FIG. 19 , the MTT enabled network  1900  comprises some of the same components as those of  FIG. 1 . Such components include NAC  104 , servers  111 ,  112 , switches  108 ,  109 ,  110  and bridge  115 . Each of the components  104 ,  108 - 112  and  115  implement the protocols of the MTT protocol stack  1300  described above in relation to  FIG. 13 . However, the client computers  101 - 103  of  FIG. 1  have been modified so as to obtain client computers  1901 ,  1902 ,  1903 . Specifically, each of the client computers  1901 ,  1902 ,  1903  has custom software installed thereon that is operative to perform identity parameter translation. The manner in which the identity parameters are translated by the client computers  1901 ,  1902 ,  1903  will become evident as the discussion progresses. 
         [0130]    Referring now to  FIG. 20 , there is provided a block diagram of client computer  1901 . The client computer  1901  can include, but is not limited to, a notebook computer, a desktop computer, a laptop computer, a personal digital assistant, and a tablet PC. The client computers  1902 ,  1903  of  FIG. 19  can be the same as or similar to client computer  1901 . As such, the following discussion of client computer  1901  is sufficient for understanding client computers  1902 ,  1903  of  FIG. 19 . Notably, some or all the components of the client computer  1901  can be implemented as hardware, software and/or a combination of hardware and software. The hardware includes, but is not limited to, one or more electronic circuits. 
         [0131]    Notably, the client computer  1901  may include more or less components than those shown in  FIG. 20 . However, the components shown are sufficient to disclose an illustrative embodiment implementing the present invention. The hardware architecture of  FIG. 20  represents one embodiment of a representative computing device configured to facilitate MTT technology. As such, the client computer  1901  of  FIG. 20  implements methods for translating identity parameters in accordance with embodiments of the present invention. Such methods will be described below in relation to  FIGS. 23-24 . 
         [0132]    As shown in  FIG. 20 , the client computer  1901  includes a system interface  2022 , a user interface  2002 , a random number generator  2030 , a CPU  2006 , a system bus  2010 , a memory  2012  connected to and accessible by other portions of client computer  1901  through system bus  2010 , and hardware entities  2014  connected to system bus  2010 . At least some of the hardware entities  2014  perform actions involving access to and use of memory  2012 . The memory  2012  can be volatile memory and/or non-volatile memory. For example, the memory  2012  can include, but is not limited to, a Random Access Memory (“RAM”), a Dynamic Random Access Memory (“DRAM”), a Static Random Access Memory (“SRAM”), a Read Only Memory (“ROM”), a flash memory, a disk driver and/or a Compact Disc Read Only Memory (“CD-ROM”). The memory  2012  can also have stored therein protocol stack software  2024  and a mission plan  2026 . The mission plan  2026  is the same as or substantially similar to the mission plans described above. 
         [0133]    The protocol stack software  2024  implements the protocols of a protocol stack employed by the client computer  1901 . A schematic illustration of an exemplary protocol stack is provided to  FIG. 21 . As shown in  FIG. 21 , the protocol stack  2100  is similar to the conventional protocol stack  1100  shown in  FIG. 11 . However, the protocol stack  2100  comprises a new module layer  2105 . The module layer  2105  comprises protocols for facilitating MTT translation of identity parameters. 
         [0134]    In order to implement the protocol stack  2100 , the protocol stack software  2024  comprises software for layers thereof. A schematic illustration of an exemplary embodiment of the protocol stack software  2024  is provided in  FIG. 22 . As shown in  FIG. 22 , the protocol stack software  2024  comprises application layer software  2210 , transport layer software  2208 , network layer software  2206 , module layer software  2205 , and data link layer software  2204 . The application layer software  2210  comprises applications  2220 ,  2222 . The applications  2220 ,  2222  can include, but are not limited to, applications operative to provide web browsing services, telephone services, network communication services, navigation services, commerce services, email services, web based services, and/or electronic calendar services. 
         [0135]    The transport layer software  2208  comprises modules  2224 ,  2226  implementing the protocols of the transport layer  1108  of the protocol stack  2100 . The network layer software  2206  comprises modules  2228 ,  2230 ,  2232  implementing the protocols of the network layer  1106  of the protocol stack  2100 . The modules  2224 ,  2226 ,  2228 ,  2230 ,  2232  are well known in the art, and therefore will not be described herein. Still, it should be understood that the modules can include, but are not limited to, WINDOWS® transport layer modules which operate in kernel mode and WINDOWS® network layer modules which also operate in kernel mode. 
         [0136]    The MTT layer software  2205  comprises an MTT translator driver  2234 . The MTT translator driver  2234  operates in kernel mode between the network layer software  2206  and the data link layer software  2204 . The MTT translator driver  2234  is operative to translate identity parameters of the transport layer  1108 , the network layer  1106  and the MAC layer  1112  of the protocol stack  2100 . As such, the MTT translator driver  2234  implements one or more methods of the present invention. These methods will be described below in relation to  FIGS. 23-24 . 
         [0137]    The data link layer software  2204  comprises drivers  2236 - 2242 . Drivers  2236 - 2242  are well known in the art, and therefore will not be described herein. Still, it should be understood that the drivers  2236 - 2242  can include, but are not limited to, data link layer drivers available from Broadcom Corporation of Irvine, Calif. 
         [0138]    Referring again to  FIG. 20 , system interface  2022  allows the client computer  1901  to communicate directly or indirectly with external communication devices (e.g., NAC  104  and servers  111 ,  112  of  FIG. 19 ). If the client computer  1901  is communicating indirectly with the external communication device, then the client computer  1901  is sending and receiving communications through a common network (e.g., the network  1900  shown in  FIG. 19 ). 
         [0139]    Hardware entities  2014  can include a disk drive unit  2016  comprising a computer-readable storage medium  2018  on which is stored one or more sets of instructions  2020  (e.g., software code) configured to implement one or more of the methodologies, procedures, or functions described herein. The instructions  2020  can also reside, completely or at least partially, within the memory  2012  and/or within the CPU  2006  during execution thereof by the client computer  1901 . The memory  2012  and the CPU  2006  also can constitute machine-readable media. The term “machine-readable media”, as used here, refers to a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions  2020 . The term “machine-readable media”, as used here, also refers to any medium that is capable of storing, encoding or carrying a set of instructions  2020  for execution by the client computer  1901  and that cause the client computer  1901  to perform any one or more of the methodologies of the present disclosure. 
         [0140]    In some embodiments of the present invention, the hardware entities  2014  include an electronic circuit (e.g., a processor) programmed for enabling MTT technology. In this regard, it should be understood that the electronic circuit can implement the protocols of the module layer  2116  of the protocol stack  2100  employed by the client computer  1901 . Accordingly, the electronic circuit can be configured to perform one or more of the methods described below in relation to  FIGS. 23-24 . 
         [0141]    Referring now to  FIG. 23 , there is provided a flow diagram of a method  2300  for translating identity parameters of an MTT packet (e.g., MTT packet  1400  of  FIG. 14 ) in accordance with the present invention. The method  2300  begins with step  2302  and continues with step  2304 . Step  2304  involves transitioning a system interface (e.g., system interface  2022  of  FIG. 19 ) of a client computer (e.g., client computer  1901  of  FIG. 19 ) from normal operating mode to an MTT operating mode of system interfaces (e.g., network interface cards). The MTT operating mode is similar to promiscuous operating modes of system interfaces (e.g., network interface cards). Promiscuous operating modes of system interfaces are well known in the art, and therefore will not be described in detail herein. Similar to promiscuous operating mode, at least some of the functions performed by the data link drivers (e.g., drivers  2236 - 2242  of  FIG. 22 ) of the protocol stack software (e.g., protocol stack software  2024  of  FIG. 20 ) are disabled in MTT operating mode. For example, receive filtering functions and transmit placement functions of the data link drivers are disabled in step  2304 . In effect, the client computer is able to read every MTT packet received thereat regardless of the MAC address contained therein. 
         [0142]    After the system interface is placed in its MTT operating mode, at least a portion of an MTT packet (e.g., MTT packet  1400  of  FIG. 14 ) is received at an MTT translator driver (e.g., MTT translator driver  2234  of  FIG. 23 ) running on the client computer, as shown by step  2306 . In a next step  2307 , the MTT translator device removes at least the MTT MAC layer protocol header (e.g., MTT MAC layer protocol header  1406  of  FIG. 14 ) and the LLC layer protocol header (e.g., LLC layer protocol header  1408  of  FIG. 14 ) from the received portion of the MTT packet. Thereafter, in step  2308 , the MTT translator device extracts an MTT MAC address (e.g., MTT MAC address  1426  of  FIG. 14 ) from the MTT MAC layer protocol header. 
         [0143]    The MAC address is used in decision step  2309  for purposes of determining if the system interface of the client computer is an intended destination device of the received portion of the MTT packet. As described above, the MTT MAC address can have a true value or a false value. The MTT packet portion can be read by the system interface of the client computer when it contains a false value for the MAC address since the system interface thereof is operating in its MTT mode. In this scenario, the determination of step  2309  can be made using a predetermined list of false values assigned to the system interface. This predetermined list can be specified by a mission plan (e.g., mission plan  2026  of  FIG. 20 ). 
         [0144]    If the system interface is not the intended destination device of the MTT packet portion [ 2309 : NO], then step  2310  is performed where the MTT packet portion is discarded and the method  2300  returns to step  2306 . If the system interface is the intended destination device of the MTT packet portion [ 2309 : YES], then the method  2300  continues with step  2311 . 
         [0145]    In step  2311 , the MTT translator driver determines which identity parameters of a network layer protocol header (e.g., MTT network layer protocol header  1410  of  FIG. 14 ) and/or a transport layer protocol header (e.g., MTT transport layer protocol header  1412  of  FIG. 14 ) comprise false values. The identity parameters can include, but are not limited to, a port number (e.g., MTT port number  1420  of  FIG. 14 ), a TCP sequence number (e.g., MTT TCP sequence number  1422  of  FIG. 14 ), an IP address (e.g., MTT IP address  1424  of  FIG. 14 ), a network prefix (e.g., MTT prefix  1428  of  FIG. 14 ), and a host number (e.g., an MTT host number  1430  of  FIG. 14 ). This determination can be achieved using the contents of a mission plan (e.g., mission plan  2026  of  FIG. 20 ) stored on a client computer (e.g., client computer  1901  of  FIG. 19 ). 
         [0146]    After determining which identity parameters include false values, the MTT translator driver performs operations for obtaining true values for the identity parameters as shown by step  2312 . The true values can be obtained by performing an inverse of a pseudo random process performed by a network node which generated the MTT packet (e.g., network node  104 ,  111 ,  112 ,  1902  or  1903  of  FIG. 19 ). Such an inverse pseudo random process can involve retrieving a true value from a predetermined list of true values specified by the mission plan. The list may include information associating the true value to a plurality of false values. Therefore, the true value can be identified using the false value extracted from the network layer protocol header (e.g., MTT network layer protocol header  1410  of  FIG. 14 ) and/or the transport layer protocol header (e.g., MTT transport layer protocol header  1412  of  FIG. 14 ) of the MTT packet. 
         [0147]    Once the true value has been obtained, step  2314  is performed. In step  2314 , the false value of the MTT packet is replaced with the true value, thereby generating a formatted data unit. The formatted data unit is then forwarded to the network layer software (e.g., network layer software  2206  of  FIG. 22 ) running on the client computer for further processing, as shown by step  2316 . Thereafter, step  2318  is performed where the method  2300  ends or other processing is performed. 
         [0148]    Referring now to  FIG. 24 , there is provided a flow diagram of an exemplary method  2400  for translating identity parameters of at least one protocol header of a formatted data unit in accordance with the present invention. The method  2400  begins with step  2402  and continues with step  2404 . Step  2404  involves transitioning a system interface (e.g., system interface  2022  of  FIG. 19 ) of a client computer (e.g., client computer  1901  of  FIG. 19 ) from normal operating mode to an MTT operating mode so that certain functions performed by the data link drivers (e.g., drivers  2236 - 2242  of  FIG. 22 ) of the client computer are disabled. For example, receive filtering functions and transmit placement functions of the data link drivers are disabled in step  2404 . In effect, the client computer is able to generate an MTT packet including any value for a MAC address associated with its systems interface. 
         [0149]    In a next step  2406 , a formatted data unit is received at an MTT translator driver (e.g., MTT translator driver  2234  of  FIG. 22 ) of the client computer. The formatted data units is received from the network layer software (e.g., network layer software  2206  of  FIG. 22 ) running on the client computer. Accordingly, the formatted data unit comprises application data (e.g., application data  1216  of  FIG. 12  or  1416  of  FIG. 14 ), an application layer header (e.g., application layer header  1214  of  FIG. 12  or  1414  of  FIG. 14 ), a transport layer protocol header (e.g., transport layer protocol header  1212  of  FIG. 12 ), and a network layer protocol header (e.g., network layer protocol header  1210  of  FIG. 12 ). Notably, all of the identity parameters of the formatted data unit received from the network layer software have true values. Therefore, the MTT translator driver performs steps  2408 - 2416  so as to generate at least a portion of an MTT packet comprising a false value for at least one identity parameter in accordance with MTT technology. 
         [0150]    In step  2408 , the MTT translator driver obtains a false value for at least one identity parameter of the transport layer header and/or the network layer header. The identity parameter can include, but is not limited to, a port number, a TCP sequence number, an IP address, a network prefix or a host number. The false value can be randomly selected from a predetermined list of values specified in a mission plan (e.g., mission plan  2026  of  FIG. 20 ) stored on the client computer. The random selection is facilitated using a random or pseudo-random number generated by a random number generator (e.g., random number generator  2030  of  FIG. 20 ) of the client device. Once the false value is obtained, the MTT translator driver replaces the true value for the identity parameter with the false value obtained in step  2408  so as to generate a modified data unit. 
         [0151]    Subsequently, the MTT translator driver generates an LLC layer protocol header (e.g., LLC layer protocol header  1408  of  FIG. 14 ) and an MTT MAC layer protocol header (e.g., MTT MAC layer protocol header  1406  of  FIG. 14 ). Notably, the MTT MAC layer protocol header comprises an MTT MAC address (e.g., MTT MAC address  1426  of  FIG. 14 ) assigned to the system interface of the client computer. The MTT MAC address can have a true value or a false value. The false value can be randomly or pseudo-randomly selected from a predetermined list of false values for the MAC address of the system interface. The predetermined list can be specified by the mission plan stored on the client computer. The random selection can be facilitated using a random or pseudo-random number generated by a random number generator (e.g., random number generator  2030  of  FIG. 20 ) of the client device. 
         [0152]    In a next step  2414 , the layer protocol header and the MTT MAC layer protocol header are appended to the modified data unit so as to form a portion of an MTT packet. This portion of the MTT packet is then forwarded from the MTT translator driver to the physical layer components of the client computer for further processing, as shown by step  2416 . Thereafter, step  2418  is performed where the method  2400  ends or other processing is performed. 
         [0153]    Although methods  2300  and  2400  were described above as being implemented in an end node of a network, embodiments of the present invention are not limited in this regard. For example, the methods  2300  and  2400  can also be implemented in intermediary nodes of a network. In this scenario, the intermediary nodes will employ software implementing the protocols of protocol stack  2100 . The end nodes will employ software implementing the conventional protocol stack  1100 . 
         [0154]    Although the invention has been illustrated and described with respect to one or more implementations, equivalent alterations and modifications will occur to others skilled in the art upon the reading and understanding of this specification and the annexed drawings. In addition, while a particular feature of the invention may have been disclosed with respect to only one of several implementations, such feature may be combined with one or more other features of the other implementations as may be desired and advantageous for any given or particular application. Thus, the breadth and scope of the present invention should not be limited by any of the above described embodiments. Rather, the scope of the invention should be defined in accordance with the following claims and their equivalents.