Patent Publication Number: US-2013246590-A1

Title: Autonomous network device configuration method

Description:
BACKGROUND OF THE INVENTION 
     The present invention generally relates to networks and configuring devices in such networks. 
     Management applications generally require direct access to target devices, such as routers, switches and hubs, for example, in order to ensure that the appropriate target device receives the configuration data. 
     If the central network administrator does not have physical access to the target devices, then the network administrator must trust the technicians that do have physical access to the device. It is very undesirable to grant such limited-trust technicians full access to the data contained in the configuration. 
     Current deployment solutions have a limited capability to ensure that the configuration is deployed only to the intended targeted device. This is particularly true if the deployment must occur through a secondary computational device, such as a laptop or notebook computer or PDA. 
     If the configurations need to be deployed via an indirect channel, such as a technician physically interacting with the target device using a laptop or PDA, then it is difficult to ensure that the configuration remains in existence for only a specified duration of time. Therefore timeliness of the deployment is difficult to ensure. 
     If the configuration is deployed indirectly, the configurations (in current implementations) would remain on the intermediate device, such as laptop or PDA. thus allowing a malicious technician to have time to attack the encrypted configuration and potentially compromise the data integrity. 
     Current practice is to encapsulate configurations in simple text files. Even though it is possible to encrypt such text files to protect them during transit to the target device, without an autonomous encapsulated agent, it is not possible for the configuration itself to enforce the intended use of the configuration. Such enforcement would have to be implemented by management applications requiring direct interaction with the target device. Such requirements increase the cost and complexity of management solutions, and also impose undesirable connectivity requirements. 
     SUMMARY OF THE INVENTION 
     One embodiment of the present invention comprises a method of configuring one or more target network devices for operation, that further comprises the steps of creating an object for deployment to a predetermined target network device, the object having configuration data for configuring the target network device, and at least one of identification data identifying the object, an autonomous encapsulated agent for executing necessary steps for installing the configuration data, identification data identifying the predetermined target network device, and authentication data for authenticating at least one of the predetermined target network device identification data and object identification data, transporting the object to the predetermined target network device, and the autonomous encapsulated agent begins an on-site process of installing the configuration data in the predetermined target network device. 
    
    
     
       DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a block diagram of an object having attributes of the present invention; 
         FIG. 2  is a flow diagram for carrying out a beginning portion of an embodiment of the method of the present invention; and 
         FIG. 3  is a flow diagram for carrying the remaining portion of an embodiment of the method of the present invention. 
     
    
    
     DESCRIPTION OF THE EMBODIMENTS 
     The present invention involves embodiments of a method of protecting and reliably installing configuration data on network devices such as routers, switches and hubs, for example. Currently, a remote network administrator has to create the configuration file for a network device as a text file and somehow get it to a remote assistant, such as by email, and the assistant receives the file, opens it, and after physically configuring the device, then download the configuration data into the device. The assistant or technician has to have or know the security credentials that are needed in order to log into the device. Physical access by the person is often necessary, i.e., the person may need to walk up to the device and connect a cable from a laptop computer to the device, for example, or to physically manipulate the switches or settings on the device. Very often the device will be in another building or a different city from where the network administrator is sitting, so it is desirable to connect to the device over a network and apply configuration changes over the network. However, not everything about configuring a device is possible without being physically present, because part of the configuration process requires placing the device in a rack, plugging in wires in the ports, plugging in the power cord and turning it on. 
     Configuration data is sensitive because it will contain policies as to how a particular network device is to behave. For example, it will have policies that certain users cannot get access to certain ports, or certain users cannot send traffic through a certain port. Configurations determine the kind of traffic that is permitted and the traffic priorities that the central administrator wants to go through the device. That kind of information, if available to an attacker, is exactly the kind of information that the attacker would like to have access to. It is desirable to limit that amount of trust that is given to a local assistant or technician and to be able to configure the device without having to disclose the information to the assistant or others in an organization. 
     Embodiments of the present invention create a single software object, into which is tightly encapsulated a network device configuration coupled with software that enables the unit to autonomously install itself into the appropriate target device and automatically delete itself after successful deployment. 
     Turning to the drawings and particularly  FIG. 1 , an object  10  is created which preferably comprises authentication data  12  for authenticating the object itself, configuration data  14  for target devices such as routers, switches and hubs, for example, although the present invention can be used with other types of devices that are capable of being configured. The object  10  also comprises identification data for the target device  16  and an autonomous encapsulated agent  18   
     Embodiments of the invention employ network device configurations that would be encapsulated into a tightly coupled module or block containing both data and the autonomous encapsulated software agent  18 . The entire configuration for such a device can be set up in the form of a text file that has information about how that device is to be configured. The configuration files are constructed for these network devices and contain information, for example, internet protocol (or “IP”) address, simplified network management protocol (or “SNMP”) community strings necessary for the network device to properly communicate on the network, the operating speed of particular ports of the device; the name given to the device, the users that are allowed to access the device, the security credentials that are needed to access the device, for example. There may be a long list of items that need to be configured. That information can be extracted from the devices and can also be redeployed back to the devices to restore the devices back to a specific configuration state. 
     The configuration text file contain configuration data destined for configuring the device, plus code, i.e., instructions that would be executed automatically as soon as that file was downloaded onto a personal computer or onto a switch. Those instructions would cover what could be done with the configuration data that was bundled within that block or object. In order to implement this, the autonomous agent  18  must be deployed on the device that can examine these encapsulated configuration files and execute the instructions contained within them and be able to decrypt them and determine if a particular file is destined for it or not. 
     If an assistant or technician does not have the security keys that decrypt the block of data were to look at the block of data, it is not possible to tear it apart and identify the part that defines the configuration, or the part that contains the instructions or the part of the key for decrypting. It would not be possible for anyone to analyze the content of the block of data. The block therefore contains configuration data, instructions and security keys that are encrypted. Someone who does not have the proper credentials would be unable to identify the boundaries of the three different parts of the block of data, much less determine what the text file contains. 
     The software agent is preferably an executable agent that exposes a programmatic interface capable of interacting with potential target network devices. In other words, if it were installed in a switch device, the agent in the switch would trigger execution of the code imbedded in the configuration file. 
     The object  10  shown in FIG. I is constructed in the manner as shown in the flow diagram of  FIG. 2  whereby an object is created (block  20 ) and then configuration data for a target device is inserted in the object (block  22 ). This is followed by insertion of an autonomous encapsulated agent in the object (block  24 ) as well as the target network device identification data (block  26 ). Similarly, the object itself is provided with object authentication data (block  28 ). At this point, the object as shown in  FIG. 1  is complete and it is then necessary to transport the object (block  30 ) to a target network device. This can be done by transmitting the object over a network or the Internet or can be loaded onto an intermediate device such as a laptop, PDA, or other device that is capable of storing the object. When it is in communication with the target network device, such as by a direct link from a laptop to the device, for example, the installation process in the target network device is begun (block  32 ). 
     The first thing that is done is to authenticate the target network device (block  34 ). More particularly, once the agent detects contact with a network device (via a serial port, a USB connection, or even a standard network connection), it verifies that the device it is in contact with is the intended target device. This is done by validating certificates or other security credentials available on the target device. 
     If it is not authenticated, then the installation process is aborted (block  36 ). If it is authenticated then the object  10  also supplies its own credentials to the target device in order for the target device to validate the authenticity of the object transporting the configuration data (block  38 ). Once mutual authentication is complete, the agent deploys the configuration to the device in a secure fashion. 
     If that authentication is confirmed, then the configuration data is installed on the target device, (block  40 ), but if not, then the installation process is aborted (block  36 ). Once the deployment to the target device is complete, the agent  18  destroys the configuration data, ( 42 ) and terminates its own execution existence. There are different platforms that support different mechanisms for deleting data or files. If it was on a USB flash drive, and you put the flash drive on a laptop computer, the Windows operating system would automatically execute the autoexec code and would execute whatever it is supposed to do. 
     It is desired that the installation of the configuration data be done within a predetermined time period, and if it is not installed also results in the destruction of the configuration data (block  42 ). Thus, in either event, the configuration data is not left intact on a technician or assistant&#39;s laptop, for example, and is therefore not vulnerable to improper or inadvertent misappropriation. 
     There are several advantages of the embodiments of the present invention. The device configurations can be deployed over indirect and insecure delivery channels without concern for compromising the contained configuration. By indirect, it is meant that the configuration can be deployed to an intermediate computational device (such as a laptop or notebook computer or a FDA), which in turn delivers it to the target device. 
     Also, the source of the autonomous configuration, which is preferably an authorized management application, need not have physical connectivity with the target device. Such autonomous configurations can be given to technicians with only a limited security clearance, because it is very unlikely that such limited trust technicians would be able to decode and read the configuration data. The embodiments only deploy the configuration data to an authorized and intended target device and deploy the configuration in a timely manner. This is because if the autonomous configuration is not deployed to the target device within a specified window of time, it self-destructs. The embodiments also substantially eliminate unauthorized access to the configuration after deployment, for the same reason that the autonomous configuration self-destructs after a successful deployment. 
     While various embodiments of the present invention have been shown and described, it should be understood that other modifications, substitutions and alternatives are apparent to one of ordinary skill in the art. Such modifications, substitutions and alternatives can be made without departing from the spirit and scope of the invention, which should be determined from the appended claims. 
     Various features of the invention are set forth in the following claims.