Abstract:
A network device ( 100, 300 ) is connected to a network ( 102 ) having also a management station ( 107 ) connected thereto. The method for configuring the network device comprises the steps of  
     transmitting from the management station a configuration packet to the network device ( 201 ),  
     authenticating at the network device the management station as the genuine transmitter of the configuration packet ( 202 ) and  
     decoding the configuration parameters contained in said configuration packet and storing them as the configuration parameters of the network device ( 203 ).

Description:
TECHNOLOGICAL FIELD  
         [0001]    The present invention deals with a device to be connected to a network and especially its installation and configuration. Installation is a general concept that covers all the hardware operations needed to connect the device to a network. Similarly configuration is understood to cover all the software operations that enable controlled transmission of data in the network between the device concerned and other devices connected to the network. The invention does not limit the type of network in question: it can be the Internet, an intranet, a Local Area Network (LAN), a Wide Area Network (WAN) or any other network intended for transmission of data between electronic terminals. The physical form of the network may be Ethernet, Token Ring, cellular radio network or any other corresponding network known as such.  
         BACKGROUND OF THE INVENTION  
         [0002]    Intelligent network devices, such as routers, VPN (Virtual Private Network) devices, print servers, network printers, network cameras, and telecommunications adapters, require detailed configuration data before they can transmit and receive information through the network in a controlled manner. For instance in an P (Internet Protocol) network the device needs to know its own P address and the address of the default gateway, and possibly lots of other configuration data.  
           [0003]    Information travels through the network generally in the form of packets. As background information for the invention, two known addressing schemes for P packets are described, namely the IPv4 (Internet Protocol version 4) and IPv6 (Internet Protocol version 6) packet headers. The layout of an IPv4 packet header is illustrated in FIG. 1, and the layout of an IPv6 packet header is illustrated in FIG. 2. Column numbers in FIGS. 1 and 2 correspond to bits. In FIG. 1, the fields of the known IPv4 header are as follows: Version Number  101 , IHL  102 , Type of Service  103 , Total Length  104 , Identification  105 , Flags  106 , Fragment Offset  107 , Time to Live  108 , Protocol  109 , Header Checksum  110 , Source Address  111 , Destination Address  112 , Options  113  and Padding  114 . In FIG. 2, the fields of the known proposed IPv6 header are as follows: Version Number  201 , Traffic Class  202 , Flow Label  203 , Payload Length  204 , Next Header  205 , Hop Limit  206 , Source Address  207  and Destination Address  208 . The use of the fields in the headers is known to the person skilled in the art. An IP packet consists of a header like that of FIG. 1 or  2  accompanied by a data portion. In IPv6, there may be a number of so-called Extension headers between the main header shown in FIG. 2 and the data portion.  
           [0004]    In a network where security features are important, an authentication may be performed by computing a Message Authentication Code (MAC) using the contents of the packet and a shared secret key, and sending the computed MAC as a part of the packet in an AH (Authentication Header) or ESP (Encapsulating Security Payload) header. Privacy is typically implemented using encryption, and the ESP header is used. The AH header is illustrated in FIG. 3, where column numbers correspond to bits. The fields of the known AH header are as follows: Next Header  301 , Length  302 , Reserved  303 , Security Parameters  304  and Authentication Data  305 . The length of the last field  305  is a variable number of 32-bit words.  
           [0005]    The Encapsulating Security Payload (ESP) may appear anywhere in an IP packet after the IP header and before the final transport-layer protocol. The Internet Assigned Numbers Authority has assigned Protocol Number 50 to ESP. The header immediately preceding an ESP header will always contain the value 50 in its Next Header (IPv6) or Protocol (IPv4) field. ESP consists of an unencrypted header followed by encrypted data. The encrypted data includes both the protected ESP header fields and the protected user data, which is either an entire IP datagram or an upper-layer protocol frame (e.g., TCP or UDP). A high-level diagram of a secure IP datagram is illustrated in FIG. 4 a , where the fields are IP Header  401 , optional other IP headers  402 , ESP header  403  and ecrypted data  404 . FIG. 4 b  illustrates the two parts of an ESP header, which are the 32-bit Security Association Identifier (SPI)  405  and the Opaque Transform Data field  406 , whose length is variable.  
           [0006]    Several existing solutions are being used to configure newly installed network devices. Some devices have a display and keyboard for entering configuration data. Others may have a serial port in the device so that it can be attached to a separate configuration terminal for configuration. There are also solutions where a broadcast network packet or a ping packet is used to configure the device.  
           [0007]    Solutions based on having a display and keyboard are often too costly and cumbersome for users. Likewise, attaching a configuration terminal to the device is an extra burden for the user. Methods based on broadcast packets only work in the local network, and cannot be used to configure the device remotely. Remote configuration is becoming more and more desirable, as the number of installed network devices is growing much faster than the number of people skilled enough to configure them. Finally, methods based on a ping packet can be used to configure the device remotely, but are limited in the amount of configuration data. Also, such methods will not work if the device to be configured is behind a device that is also listening for several other configuration packets or if there are similar identical devices on the same network.  
           [0008]    Growing use of networks, especially increasing use of the Internet for electronic commerce and corporate communications is making security ever more important. Attacks against the network infrastructure are increasingly common. One opportunity for performing such attacks is the moment when the network device is being configured. At that time, most devices do not provide any security, and the attacker will be able to load the device with his/her configuration and software. The compromised device can then be instrumental in furthering the attack.  
         SUMMARY OF THE INVENTION  
         [0009]    The existing configuration methods for configuring network devices lack ease of use, robustness, and security. Problems during device configuration are often very difficult for users to understand and solve. It is therefore desirable to provide a method and apparatus for loading configuration data into the network device in a reliable, easy-to-use manner from a network management station controlled by an employee skilled in configurration of new network devices. This allows physical installation of new network devices to be carried out by employees that are not as skilled in configuration of new network devices. This genus of methods and apparatus will be referred to as the unsecure, remote configuration class. Further, in some networks where security is an issue, it is desirable to be able to configure new network devices remotely and securely from a remote network management station. This allows remote configuration via network packets without fear that an interloper with intent to attack the network will be able to intercept and alter the configuration data or other information such as network address or device identifier. The object of this invention is to provide methods, as well as a network device which can carry out the disclosed methods.  
           [0010]    The object of the unsecure, remote configuration methods of the invention is accomplished by installing the network device in a dummy mode, and sending a configuration packet, including a device-specific identifier, to the network device to be configured or reconfigured either by broadcasting a packet containing the new network device&#39;s device identifier or sending a configuration packet directly to the network device&#39;s network address with the packet containing the device identifier of the device to be configured. The new network device to be remotely configured then either recognizes its device identifier in the broadcast packet or recognizes its device identifier in the packet sent directly to its network address, and uses the data therein to configure itself.  
           [0011]    The object of the secure, remote configuration methods of the invention is accomplished by: transmitting the configuration packet from a remote network management station to the network device to be configured or reconfigured either by broadcast or by direct transmission to the network address of the device to be configured, authenticating the configuration packet at the network device to be configured or reconfigured as being from the proper network management station and containing the proper device identifier or by at least verifying that the configuration packet conatains the properly encrypted device identifier which could only have been encrypted by the authentic network managment station or some other secure information derived from the device identifier which can serve as a reliable indicator of the source of the configuration packet, and then decrypting and using the contents of the authenticated packet to configure the new network device.  
           [0012]    It is characteristic of the secure, remote configuration method according to the invention that it comprises the steps of  
           [0013]    transmitting from the management station a configuration packet to the network device,  
           [0014]    authenticating at the network device the management station as the genuine transmitter of the configuration packet and  
           [0015]    decoding the configuration parameters contained in said configuration packet and storing them as the configuration parameters of the network device.  
           [0016]    The invention applies as well to a network device, of which it is characteristic that it comprises a computing block arranged to  
           [0017]    compute device identifiers from cryptographic keys derived from recognised packets and  
           [0018]    compare computed device identifiers against information used to verify known device identifiers for authentication of transmitting parties.  
           [0019]    According to the invention, each new network device to be configured has a device identifier used to authenticate the device. There is also a management station connected to the network and used to remotely configure freshly installed network devices. The invention does not limit the nature of the device identifier; on the contrary, it should be understood very generally as something that can be used to identify a network device. According to a first embodiment of the invention, the management station knows the device identifier, IP address, default gateway, and other information needed to configure each new network device. When a new network device has been installed into the network it operates initially in a dummy mode where it only reads device identifiers from the packets it receives but does not otherwise process any data transferred in the network (or processes data in a factory-configured manner). The management station sends a specially formatted packet to the broadcast address of the network in which the new network device resides. The special packet contains an identifying code derived from the device identifier of the new network device and possibly other data. Whenever the new network device receives a packet, it checks whether the packet is a special packet with the identifying code matching its own device identifier. If the code matches, the device decodes the special packet, retrieves the configuration information from it and starts using its new configuration. It may also engage in a further information exchange with the management station to obtain further configuration data and to provide feedback to the management station user. In place of the identifying code derived from the device identifier the packet sent by the management station could also be a factory-configured (or generally preconfigured) address other than IP address, e.g. ethernet address, or some other kind of device identifier that the network will recognize.  
           [0020]    According to a second embodiment of the invention the network device has its IP address preconfigured manually before it is installed in the network. Thereafter, the management station may send a configuration packet directly to that address; the network device may even send a packet first to a preconfigured management station address to let know it is there and wants to be configured.  
           [0021]    According to a third embodiment of the invention the network device may obtain its IP address automatically from the network, e.g. using DHCP (Dynamic Host Configuration Protocol). According to a fourth embodiment of the invention the network device might respond to an ARP (Address Resolution Protocol) packet for IP addresses of some format, e.g. after a short delay to give a possible real owner of the address time to respond.  
           [0022]    Security against any network-level attacks can be provided with the method. The device identifier is most advantageously derived from a cryptographic public key. The device identifier may also be the cryptographic key itself or a certificate accompanying it. Both the new network device and the management station may know the other device&#39;s device identifier beforehand so that they may recognise a received packet as coming from the correct sender. Alternatively each device may display the identifier computed from data received from the other party to the user and have the user confirm that the identifier is correct. This is called a (manual) verification of the device identifier. Both the new network device and the management station verifies that the cryptographic public key received from the other side matches the (manually) verified device identifier. Then, they cryptographically generate a shared secret using the authenticated cryptographic public keys. One implementation of this is to have each cryptographic public key be a Diffie-Heilman public value. After the authentication and verification stages the configuration may proceed safely.  
           [0023]    The present invention provides a method to remotely configure a network device in a reliable, easy-to-use manner from a separate management station (which can be another network device). Optionally, the method can provide security.  
           [0024]    The method enables devices to be installed by fairly unskilled support personnel, and the technically more demanding configuration operation can be performed by an expert from a management station without needing to travel to the installation site. 
       
    
    
     BRIEF DESCRIPTION OF DRAWINGS  
       [0025]    The novel features which are considered as characteristic of the invention are set forth in particular in the appended Claims. The invention itself, however, both as to its construction and its method of operation, together with additional objects and advantages thereof, will be best understood from the following description of specific embodiments when read in connection with the accompanying drawings. Features well-known as such have not been described in detail so as not to obscure the invention.  
         [0026]    [0026]FIG. 1 illustrates a known IPv4 packet header,  
         [0027]    [0027]FIG. 2 illustrates a known IPv6 packet header,  
         [0028]    [0028]FIGS. 3, 4 a  and  4   b  illustrate other known packet headers,  
         [0029]    [0029]FIG. 5 illustrates some features of a network and a network device,  
         [0030]    [0030]FIG. 6 illustrates a method according to the invention and  
         [0031]    [0031]FIG. 7 illustrates a network device according to the invention. 
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0032]    The invention is here described in terms of a network device attached to an IP (Internet Protocol) network. However, the present invention is equally applicable to other network protocols.  
         [0033]    A network device  500  in FIG. 5 is a device that has one or more network interfaces  501 . A network interface is a connection to the physical network  502 , such as an Ethernet(network, a mobile radio network or some other network. In most networks, each network interface has one or more network addresses  503  that identify the network interface as the transmitter and/or receiver of packets. Network addresses are character strings; in FIG. 5 the characters are represented generally by X&#39;s. In an IP network the network address  503  is an IP address. The network knows how to route packets from a transmitting network address to a receiving network address from anywhere in the network. Such routing may involve travelling through multiple network devices, each device sending the packet down a link that it thinks will bring the packet closer to its final destination.  
         [0034]    As a network device comes from the manufacturer, it has normally no information about the network address or other configurable data it will have when it is installed in a network. Such configuration data needs to be entered into the device either before or after the device is physically connected to the network in the appropriate location.  
         [0035]    Configuration data is data that the network device needs to know before it can start normal operation. Typically, such data would include an IP address  503 , netmask  504 , default gateway address  505 , and operational parameters  506  for the network device  500 . Configuration data may also include new software to be downloaded to the device.  
         [0036]    A management station  507  is a network device that will provide the newly installed device with configuration data. It may, but need not, maintain communications with the new network device also after installation. The management station usually has a user interface (keyboard and display).  
         [0037]    Part of the present invention is that each network device  500  (and management station  507 ) can have a device identifier  508 , which is a public character string that could e.g. be printed on a sticker and attached to the bottom of the device. The device identifier  508  serves two purposes. Firstly it identifies the device to be configured, so that if multiple devices using the same configuration method are attached to the same network, or there are other network devices on the path that the configuration packet needs to travel to reach its destination, the appropriate network device can be identified and other devices can ignore configuration data which is not intended for them. The other, more important purpose of the device identifier is that if it is derived from an appropriate cryptographic key, the device being configured and the management station can use it to authenticate each other, and to exchange cryptographic keys with each other securely. The device identifier is optional, but multiple configurable devices on the same network cannot be distinguished and security cannot be guaranteed without device identifiers.  
         [0038]    It is possible to have the device generate its own device identifier (e.g. when it is first powered on) by some method known as such, and e.g. display the device identifier on screen if the device has one. This may be desirable in some cases to make all devices be identical when they leave the factory.  
         [0039]    The device identifier is used for identifying the particular network device being configured by having the initial packet(s) sent to it contain either the device identifier directly, or some information derived from the device identifier (such as a hash of it and some other data). All receiving devices can then ignore configuration packets that are not destined to themself by checking the device identifier (or derived information) in each received configuration packet. To ease troubleshooting by users, the network device may display a warning if it sees a configuration packet that is not destined to itself. Device identifiers may also contain parity bits or other data that can be used to validate that a user has typed them in correctly.  
         [0040]    To use the device identifier for security, it is a value derived from a cryptographic public key. The public key can be a Diffie-Helman public value, an RSA (Rivest-Shamir-Adelman) key, a DSA key (Digital Signature Algorithm; US Government Digital Signature Standard), or some other public key. The use of Diffie-Hellman public values is known from patents U.S. Pat. No. 4,218,582 and U.S. Pat. No. 4,200,770, and the use of RSA keys is known from patent U.S. Pat. No. 4,405,829. For security, the device identifier should be derived from the public key in a way that makes it very hard to come up with another public key that would have the same identifier. One possible method is to use a cryptographic hash function (e.g. SHA1; Secure Hash Algorithm 1) to compress the public key, and then use an appropriate number of bits from the returned hash value. The use of the SHA1 algorithm is known from the publication “NIST, FIPS PUB 180-1, Secure Hash Standard, April 1995”. To make the device identifier easier for users to communicate, it is also possible to further process it for readability, e.g. by converting it to short English words similarly to what is used by some one-time-password methods.  
         [0041]    An advantageous embodiment of the method according to the invention will be described below with reference to FIG. 6, where a multitude of possible authentication features are included. Later on it will be mentioned, which steps of the method are optional and not necessarily required by the invention.  
         [0042]    To configure a new network device that has been installed in the network, the management station sends at stage  601  a specially formatted configuration packet to the new network device. The packet will be addressed so that the new network device will be able to see it. The exact method of doing this depends on the network protocol that is used and on the embodiment of the invention that is applied. In an IP network, the configuration packet can be addressed to the broadcast address of the network containing the new device. This causes all devices on that physical network to see it, including the new device. Addressing directly to the new network device&#39;s IP address or some address behind it (for routers) will not work in this embodiment of the invention because the new network device has not yet been configured and consequently the ARP address resolving operation would fail. ARP (Address Resolution Protocol) is a known protocol that resolves IP addresses to Ethernet( addresses. Other alternatives than using the broadcast address have been described above in the general description of the invention.  
         [0043]    The configuration packet will typically contain the new device&#39;s device identifier (or derivation thereof), the device&#39;s IP address, netmask, default gateway, and the management station&#39;s IP address and device identifier and/or public key. It may also contain information for setting up a shared secret, such as the management station&#39;s Diffie-Hellman public value and/or a certificate that will be used to verify that the packet came from the correct management station.  
         [0044]    Each party (new network device and management station) needs to be assured that it is communicating directly with the other device and not with some intermediary (man-in-the-middle) that could modify the configuration data as it is transferred. If a single configuration packet is used without a further packet exchange, it may be sufficient to perform one-sided authentication, meaning that the new network device is assured that it receives the configuration packet directly from the management station without any intermediary tampering with the contents of the configuration packet.  
         [0045]    To authenticate bidirectionally and to establish security according to FIG. 6, each party will send its public key to the other party. At stage  601  the management station sends its public key to the new network device along with the configuration packet. When a new network device receives the configuration packet labelled with its own device identifier, it computes at stage  602  the transmitting party&#39;s device identifier from the public key (and whatever other data might be used in the computation in a particular implementation) included in the configuration packet. It verifies that the device identifier it got by computing matches the known device identifier of the correct management station. The invention does not limit the way how this check is accomplished. There are several possible ways, like the following:  
         [0046]    the network device displays the computed device identifier to a user, and the user verifies it using some out-of-band means (e.g. phone call or checking against written notes), and either accepts or rejects the identifier (e.g. by pressing the appropriate button),  
         [0047]    the device identifier identifying the correct management station has been entered into the new network device beforehand, or a user types it in on location by using a keyboard, and the new network device compares the typed identifier electronically against the computed one, or  
         [0048]    the device identifier is verified using some other means, such as checking a certificate or using a value stored in tamper-resistant memory means to verify that the identifier is acceptable; if a certificate contained in the packet is to be used the network device will most likely have the public key or a certificate of a CA (Certification Authority) in memory.  
         [0049]    After checking the identity of the management station at stage  602 , the new network device may compute a shared secret at stage  603  using any method known as such, some of which are listed below, and set up whatever method will be used for further communication with the management station. With IPSEC, for instance, it could set up an AH or ESP security association with the management station. At stage  604  the network device sends a reply packet back to the management station, typically containing its own device identifier, its Diffie-Helman public value or other public key, and other information depending on the particular application.  
         [0050]    Upon receiving the reply packet, the management station will verify at stage  605  that the received public key or corresponding value matches the correct device identifier. Same methods may be applied as the other way round at stage  602 . The management station may compute the shared secret at stage  606  before setting up whatever method will be used for further communication with the management station.  
         [0051]    The calculation of a shared secret at stages  603  and  606  corresponds to cryptographic authentication. Almost any authenticating key agreement method from the literature can be used. Examples include the following:  
         [0052]    Each public key is a Diffie-Hellman public value, and the device identifiers are derived from the public value (e.g. using the SHA1 hash); effectively, each party authenticates each other&#39;s public value, and computes the Diffie-Hellman shared secret. Because both public values were authenticated, the resulting shared secret is also authenticated.  
         [0053]    Each public key is a digital signature key (e.g. RSA or DSS), and the device identifiers are derived from the public key (e.g. using the SHA1 hash). The parties first obtain a shared secret (e.g. by a Diffie-Hellman exchange, public key encryption, or some equivalent method), and then digitally sign data used to derive it to prove to the other party that there was no man-in-the-middle.  
         [0054]    If the key agreement method uses implicit authentication, it may be necessary to actually use the shared secret to prove its possession to the other party.  
         [0055]    Once a shared secret has been established using any method, it can be used to cryptographically authenticate and/or encrypt any further messages. The configuration process may continue with an arbitrary packet exchange  607  protected by the shared secret. A number of well-established methods exist for doing this once the shared secret is available. One possibility is using the IPSEC AH and ESP headers for protecting the rest of the configuration exchange.  
         [0056]    It is also conceivable to use symmetric cryptographic keys with tamper-resistant hardware. In this case, the devices typically already have a shared secret key. No explicit authentication is necessary. The parties can directly use their secret key to encrypt or authenticate any messages they send, and the correct key will be needed by the other party to decrypt messages or generate/validate authentication codes. If cryptographic authentication is not required, it may be omitted from stages  603  and  606  altogether.  
         [0057]    Appropriate timeouts and recovery mechanisms must be used to cope with packets lost in the network. For instance, a network device may want to disable listening for configuration packets once it has been configured. However, it cannot do so until after it knows the management station has received the reply packet. Alternatively the network device may accept any time a new configuration packet that correctly indicates the management station as the authenticated transmitting party. This way the operation of the network is easy to change online by reconfiguring the appropriate network devices when necessary.  
         [0058]    A user&#39;s view of the configuration process depends on the method used for verifying the other device&#39;s device identifier at stages  602  and  605 . The following installation process alternatives give an idea of the possible variations:  
         [0059]    Known peer device identifier is explicitly typed in at both management station and new network device.  
         [0060]    Known network device identifier is explicitly typed in at the managemement station but not at the new network device. When the management station has sent the configuration packet to the new network device, the new network device will display the computed device identifier of the management station and wait for user confirmation. The user will need to verify the device identifier out-of-band (e.g. by telephone, or having previously written it on paper).  
         [0061]    No device identifier typed in on either side; both sides display it on screen for verification.  
         [0062]    [0062]FIG. 7 is a schematic block diagram of those parts of a network device or management station  700  that take part in the operation according to the invention. The following explanation of the block diagram refers to a new network device to be configured but the corresponding functions are equal in a management station, although during the remote configuration of a newly added network device they take place in different order in a management station than in the network device to be configured. Physical network interface  701  may be any prior art network interface known as such, adapted to receive and transmit packets through the network. Device identifier observation block  702  reads device identifiers from received packets to recognise those packets that are meant for this particular network device. A positive recognition occurs when the device identifier of the received packet coincides with the network device&#39;s own previously stored device identifier, read from the appropriate nonvolatile device identification memory  703 . A recognised packet will be written into a scratch pad storage  704  so that a computing block  705  may compute the device identifier of the transmitting device from the public key contained in the received and stored packet. To authenticate the transmitting device, the computing block  705  compares the device identifier it has computed against a known correct device identifier inputted by the user through a keypad  707 . Alternately the network device  700  may show the computed device identifier in a display  708  and wait for a positive or negative acknowledgement from the user through a keypad  707 . It is also possible to have the information used in the authentication read from a tamper-resistant memory  706 . A positive comparison or positive acknowledgement causes the configuration parameters contained in the received and stored configuration message to be transferred from the scratch pad storage  704  to a nonvolatile configuration memory  709 . If the result of the comparison or acknowledgement is negative, the temporarily stored configuration message is discarded from the scratch pad storage  704  and the network device  700  returns to its original dummy state where it only reads device identifiers from received packets and waits for its own configuration message without processing any other data received from the network.  
         [0063]    After the transmitting management station has been correctly authenticated, a transmitter block  710  assembles a reply packet containing at least the network device&#39;s own public key read from the device identification memory  703  and the management station&#39;s network address read from the configuration memory  709  as the recipient&#39;s address. The reply packet is sent through the network interface  701  through the network to the management station.  
         [0064]    Alternatively, the computer  705  may be programmed to use the apparatus already described to carry out any of the various other configuration methods described herein or included within the scope of the claims.  
         [0065]    Memory blocks  703 ,  704 ,  706  and  709  may be any suitable memory circuits known as such. Keypad  707  may be any known keypad or keyboard and display  708  may be a LED display, a LCD screen, a cathode ray tube or any other suitable display known as such. The intelligent blocks  702 ,  705  and  710  are most advantageously realised in a microprocessor by programming it to perform the necessary functions, which programming as such is within the normal ability of a person skilled in the art. A network device and a management station may naturally contain many other parts as those shown in FIG. 7. Also, the configuration of FIG. 7 is exemplary in the sense that other arrangements may as well be used to reduce the invention into practice.