Secure autoconfiguration of field equipment in mobile automation ...

Secure autoconfiguration of field equipment in mobile automation system

Timo Ruohonen Tampere University of Technology, Institute of Automation and Control P.O. Box 692, FIN-33101 Tampere, Finland, [email protected]

Jari Sepp¨al¨a Tampere University of Technology, Institute of Automation and Control P.O. Box 692, FIN-33101 Tampere, Finland, [email protected]

Mikko Salmenper¨a Tampere University of Technology, Institute of Automation and Control P.O. Box 692, FIN-33101 Tampere, Finland, [email protected]

Hannu Koivisto Tampere University of Technology, Institute of Automation and Control P.O. Box 692, FIN-33101 Tampere, Finland, [email protected]

KEYWORDS:

Automation, field equipment, autoconfiguration, mobile, security

ABSTRACT In future the total amount of networked devices will increase significantly and cost effective management requires them to be as autonomous as possible. As the number of networked devices increases new business opportunities become available as long as the underlying network technologies can accomodate them. These changes force us to use automation in configuration of the devices. This paper presents a functional view of secure autoconfiguration in mobile automation system. The most significant mechanisms related to autoconfiguration are introduced. The suitability of Internet Protocol version 6 (IPv6) with mobility support is covered and test environment is expressed.

1

INTRODUCTION

Currently one of the biggest future visions is that the world will have pervasive communication network. Network interface will become everyday in all devices, even where we have not imagined it yet. In matter of fact larger machines and system will have more that one network interface used to create sort of internal network inside the machine, and then one gateway to the rest of the Internet. Thus the total amount of networked devices will increase significantly. Also the way we use networked services will change. It will be possible to use same services regardless of time, place or available terminal equipment. Because of increased amount of networked devices and use scenarios, manual configuration of devices is not feasible solution anymore. There is an obvious need for a different kind of mechanism that is able handle the autoconfiguration of networked devices. The autoconfiguration makes possible to create new kinds of products and concepts. As an example of this the business model in automation is changing to selling products with life-cycle management. This concept includes planning, the product itself, its maintenance and finally replacement of this device as it becomes obsolete. The autoconfiguration makes the maintenance of the product a lot of easier as less human interactions are needed. The autoconfiguration scheme presented in this study is designed for service oriented automation where the device is sold together with the service. Focus is concentrated on autoconfiguration of field equipment in mobile automation system. We define autoconfiguration of field equipment as stages from the powering on the field device to the beginning of execution of its intended task. Autoconfiguration is divided into two main ares of interest which are secure network connection handling and operations which use network connections. These operations using opened network connections could be for example software or configuration information downloading. This article concentrates on secure network connection handling primary based on Internet Protocol version 6 (IPv6). The main idea behind the autoconfiguration of the field equipment can be seen on 1. A typical case could be that field equipment is initialized in home network (factory in 1). After that the field equipment is transported to a

Figure 1: Idea behind the autoconfiguration in mobile automation system: The field device is transported from factory to place of operation after initialization

Figure 2: Functional view of the autoconfiguration in mobile automation system remote location possibly in foreign country (forest in 1) and then switched on.

2

FUNCTIONAL VIEW

The functional view of the autoconfiguration in mobile automation system environment is presented in 2. Actual autoconfiguration occurs after powering on the field equipment in remote location. After autoconfiguration the device should be ready to perform its task from foreign network and country without any human interactions.

2.1

Initialization

Before the field equipment can be transferred into foreign network some initial configurations has to be done. The field equipment must to know how to communicate with home network and especially which network elements are responsible for mobility in home network. This can be achieved by simple telling the field equipment the subnet prefix of the home network. In addition the field equipment has to know some security information namely initial authentication credentials and if necessary ciphering keys. If the requirements are met the field equipment can acquire rest of the necessary configuration information from the remote network and remotely from the home network during autoconfiguration phase.

2.2

Change of network

Field equipment has adapt to the network change where it is turned on and its geographical location has changed. First the field equipment has to authenticate with the current local network to access network parameters like address through IPv6 autoconfiguration. After this the field equipment has to authenticate to home networks system responsible for mobility management to update its location information. When the field device changes network the network address it has also changes. In cases where field equipment is responsible for starting the communication this poses no problem. Peer entity gets the field equipments address from information that field equipment sends to it. But when the correspondent device wants to start communication, there has to be a way for locating the remote device and its network address. This is one of the tasks of the mobility mechanism.

2.3

Interactions with home network

The use of the autoconfiguration requires interactions between the field equipment and the home network. The field equipment could for example change information related to addressing or accounting. The first issue is how the field equipment can find the home network and other network elements located there. The firewall is an essential part of network security nowadays and provides some protection against different harmful events. However firewall also blocks some useful mechanisms, mainly because they could be exploited if left unprotected. Because the actual network address of the field equipment changes according to its location and used network there cannot be any static rules in firewall allowing the mobile device to communicate with the home network. Solution to this is to allow certain secure and well known protocols to penetrate the firewall. These allowed protocols can the be used to create more secure connection between the field device and home network. this allows the field device then to bypass the firewall altogether An example of such a protocol is IKE (Internet Key Exchange) which allows necessary operations to establish a secure tunnelling between two peers.

3

RELATED MECHANISM

In practise the essential functionalities of the autoconfiguration in mobile automation system and also in mobile telecommunication generally are address autoconfiguration, security and mobility management. In particular the security is much more challenging because of address autoconfiguration and mobility. One meaning of AAA concept is to provide security.

3.1

Address autoconfiguration

Address autoconfiguration is requirement for the rest of the autoconfiguration functionality. Before any information can be transferred on the local network the field equipment must at least network layer address. The address autoconfiguration means that the field equipment acquires its address autonomously or that some server or router transmits address information to field equipment. The actual address autoconfiguration process is rather easy to implement nowadays. The main challenge is to implement a secure address autoconfiguration in a mobile environment.

3.2

Mobility

Usually wireless link layer (Data Link Layer) technologies include at least some kind of mobility support. These link layer technology specific mobility mechanisms are implemented on link layer. If we want to change the link layer technology eg. switch between link medias such as GPRS, WiFi, WiMAX, Bluetooth, Ethernet etc. and to do so interrupting already active transport layer connections the mobility in link layer is not enough. We have to implement the mobility on network layer or above. Flexible moving between different link layer technologies is important to guarantee that most suitable and cost effective telecommunication service can be used.

3.3

AAA

The idea behind of AAA concept is to combine security related operations together. Accounting is mostly based on authentication and authorisation requests and authorising needs authentication. The main reason for the need of separate AAA mechanism in autoconfiguration of mobile automation system is location change. When the field equipment moves into foreign network and start to operate it has to inform the home networks mobility system about its current location. Without at least authentication and authorization functionalities in the mobility system anyone could corrupt the information related to field equipment. Most access networks require authentication. For example in mobile phone network SIM (Subscriber Identity Module) card handles the authentication. Furthermore the automation system itself (or any other application layer service in OSI model) could request the field equipment to authenticate. By integrating these two AAA mechanisms (single sign-on) we can achieve some significant advantages. Separate authentication between different protocol layers decreases the usability of services. Single sign-on also provides easier management thus to better security. One single sign-on solution is presented in /5/.

3.4

Security

Security is a separate function of the autoconfiguration in the mobile automation system. It is related to all functionalities described earlier. Implementing mobility and address autoconfiguration increases amount of security risks. On the other hand AAA concepts role is to provide authentication and authorization services which improve security.

The security in automation systems is far more important than in systems used for example in homes because automation systems are usually essential parts of large scale business operations. In our case the biggest challenges to security come from mobility management. As we know there are more security risks concerning wireless communication systems than fixed. In the mobile automation system the foreign network has to know if the field equipment is allowed to connect to network. This is only possible by communication with home and foreign network. Due to transporting sensitive subscriber information through network security issues must be considered carefully. The address autoconfiguration also exposes the home networks automation system to different kinds of security threats. For example some one could try to fake a network device. More specific information about security issues in automation systems can be found in /4/ and /7/.

4

AUTOCONFIGURATION USING MOBILE IPv6

In this part we consider how the concept of mobile autoconfigurable automation system can be implemented according the mobile extension to IPv6 defined on IETF’s RFC 3775 /1/. IPv6 with this extension will be called Mobile IPv6.

4.1

IP version 6

The future automation systems will be so called All-IP i.e. their networking capabilities, at least long range, will be base on IP. Although link layer technologies change, the amount of IP based solutions is growing. At this time the IP version 4 (IPv4) is still largely used. The too small address space and the lack of built in security mechanisms will force the system providers along with network operators to change gradually to IPv6. This will happen mosty due the fact that mobile terminal equipment (like cell phones) will be forced to support the newer IP version as the amount of customers grow. This transformation can already be seen in Far East countries. Another reason for use of IPv6 is that the address autoconfiguration in IPv4 is not fully sufficient for automation system requirements. Most of required functionalities in this project can be implemented with IPv4. However, utilisation of IPv6 simplifies some part of the problem area. IPv4 address autoconfiguration is done with DHCP service. The problem with DHCP is that it requires separate solutions like address servers and protocols. In IPv6 it is possible to use DHCP through stateful address autoconfiguration but it is also possible to choice stateless address autoconfiguration when there is no need for DHCP as the router takes care of address configuration. The terminal device forms the address in stateless address autoconfiguration from locally available information and router advertised information /8/. The most essential difference between IPv4 and IPv6 concerning security issues is the built in Internet Protocol Security (IPSec) in IPv6. It is possible to use add-on IPSec in IPv4 but it is not as robust and simple as built-in implementation of IPv6. IPSec makes it possible to use two different modes: Authentication Header (AH) and Encapsulating Security Payload (ESP). AH provides data integrity check and data origin authentication. With ESP the payload of the IP packet is encrypted in addition to before mentioned AH features /2/.

4.2

Mobility support

The main idea behind the Mobile IPv6 is that mobile device (mobile node, MN) has home network and home address (3). Regardless of where the MN is located other devices (correspondent node, CN) can communicate with MN using its home address. Home network has node called home (HA) agent whose task is to map MN’s home address to valid address called care-of-address. This mapping is known as binding. When CN wants to communicate with MN while it is on home network traffic is routed normally. If MN is on foreign network the HA has to tunnel the traffic to care-of-address. It is also possible that bindings are maintained by CN in which case traffic does not stress the HA. The essential functions of Mobile IPv6 are: MN changes network, CN sends information to MN and MN sends information to CN. The description of each follows. MN changes network • MN movement to foreign network creates the need for securely informing the HA about the present location of MN. • After the MN has received a care-of-address it starts IKE (Internet Key Exchange) process with HA. • As a result of IKE process there is two SA’s (Security Association) between HA and MN. • Now MN can securely inform HA about its present location. These created SA’s are only for binding update traffic. The return routability process that confirms MNs address needs own two SA’s. CN sends information to MN

Figure 3: Mobile extension to IPv6 based on RFC 3775.

Figure 4: Mobile extensions to IPv6 without bindings maintained by CN. • CN has to first check if it has entry in its binding cache linking MN’s home address to care-of-address. • If it finds entry for this specific home address it should add the home address to IPv6 headers destination address field and the care-of-address to separate routing header. • If it does not find entry in cache it should send the packet normally to home address without routing header. MN sends information to CN • If MN is in home network information is transferred to CN normally. • If MN is in foreign network it has to use a care-of-address as source address. • However upper layers should see the home address of MN so that they do not be disturbed. Transforming care-of-address to home address is task of mobile extension.

5

TEST ENVIRONMENT

The built test environment is based on RFC 3775 with few modifications. The most essential modification is that CN is not allowed to communicate directly with MN if it is not in home network (4). This makes it easier to

monitor and restrict communication from home network which is essential for service oriented automation. The restriction enables easier billing and control of remote users. The main goal of our tests is to find out is it possible to use mentioned implementation in field devices autoconfiguration. All the available implementations of RFC 3775 are still developing and do not necessarily implement everything mentioned in RFC. Our test environment is based on Mobile IPv6 for Linux (MIPL /3/. MIPL version 2.0 was the most potential choice in our purpose as it supports IPSec, however, it is still in beta phase. Development of MIPL at Helsinki University of Technology is done in co-operation with Widely Integrated Distributed Environment (WIDE) Universal Playground for IPv6 (USAGI) project /9,10/. Nautilus 6 would have been another viable implementation of RFC 3775 /11/ but it lacks support of IKE and therefore IPSec. The main purpose of tests is to find out is it possible to use current implementations of Mobile IPv6 in autoconfiguration of field equipment in global environment. Currently, the environment is finished and the beta version of MIPv6 is under evaluation. As the selected implementation matures, the actual tests will be done. The long time goal is to test the built system with long range mobile connetions and finding feasible ways of dealing with device identity management.

6

CONCLUSIONS

Automation business is moving towards service oriented architecture and total life-cycle management of remote devices. The change management will be the far most important problem area of remote device management. Autoconfiguration will be one of the solutions required for solving the management problem. Specifications and implementations exist which enable autoconfiguration support for automation systems. However, these specifications and especially implementations are still developing and do not necessarily form fully functional entity. As long as these implementations are not mature enough the change management have to be done in old fashioned and difficult ways. Mobile IPv6 on paper is one of the viable autoconfiguration solutions for remote devices. Its maturity level, however, is not yet good enough for more than experimental purposes. In the future as the implementations evolve and better operator support will become available Mobile IPv6 could provide easy and secure way of autoconfiguration for remote as well as local automation devices.

7

REFERENCES

1. Johnson D. (Rice University), Perkins C. (Nokia Research Center), and Arkko J. (Ericsson): Mobility support in IPv6 (RFC 3775), IETF Network Working Group, (2004). 2. Kent S. (BBN Corp.) and Atkinson R. (@Home Network) (1998): Security architecture for the internet protocol (RFC 2401), IETF Network Working Group, (1998). 3. Mobile-IPv6.org: Mobile ipv6 for linux (MIPL), http://www.mobile-ipv6.org/ (30.10.2004). 4. Nikunen J.: Security considerations on wide area net working industrial solutions, Master’s thesis, Tampere University of Technology, Automation Department, (2001). 5. Pashalidis A. and Mitchell C.: Using GSM/UMTS for single sign-on, Mobile Future and Symposium on Trends in Communications, (2003). 6. Salmenper¨a M. and Sepp¨al¨a J.: Data security considerations in modern automation networks, International Conference on Informatics in Control, Automation and Robotics, Setubal, Portugal, August 2004. 7. Thomson S. (Bellcore) and Narten T. (IBM): IPv6 stateless address autoconfiguration (RFC 2462), IETF Network Working Group, (1998). 8. USAGI Project. Linux IPv6 development project, http://www.linux-ipv6.org/, (30.10.2004). 9. WIDE: Widely integrated distributed environment, http://www.wide.ad.jp/ (30.10.2004). 10. Widely Integrated Distributed Environment (WIDE): Nautilus6 working group, http://www.nautilus6.org/ (15.10.2004).