Host Identity Protocol (HIP) as a Virtual Learning Object

Download PDF
5 downloads 15534 Views 382KB Size Report
Comment
In this paper a net based HIP learning environment with a web interface is presented. ... either from a DNS lookup of the Responder's Fully Qualified Domain Name ..... software and IT technology as well as a sufficient and realistic budget are.
Proceedings of the Informing Science & IT Education Conference (InSITE) 2008

Host Identity Protocol (HIP) as a Virtual Learning Object Laura Bergström, Johan Fröjdman, Kaj J. Grahn, Jonny Karlsson, and Göran Pulkkis Arcada University of Applied Sciences, 00550 Helsinki, Finland [email protected], [email protected], [email protected], [email protected], [email protected]

Abstract This paper presents a virtual learning environment for HIP (Host Identity Protocol). HIP is a potential future Internet protocol currently under research. The main idea with HIP is the separation between the location and identity information by introducing a new cryptographic name space, called Host Identity (HI). This feature provides enhanced network security as well as easy management of mobility and multi-homing. Overviews of the basic features and implementations of HIP are included in the paper. A technical description of HIP, including a survey of specifications and details about the functionality of the protocol, is included in an appendix. The HIP learning environment has been produced to serve both contact and distance education in advanced networking. The development of the learning environment is described. A list of topics that developers of a learning environment should think of when designing the user interface is presented based on a theory on the structure of human behaviour. This theory is included in an appendix. The chosen didactical approach, the structured animation of HIP features, and the graphical design of the learning platform are presented and motivated. The IT tools and infrastructure needed to implement and use the learning platform are also described. Keywords: animation, didactical, learning environment, HIP, security, mobility

Introduction The original IP (Internet Protocol) address has two roles. The IP address of a network node represents both the identity and the location of the node in an IP network. In a traditional wired network both these roles are static during a networking session. However, terminal mobility means that the network location may change during a networking session. Mobile IP solves the problem with a changing network location by introducing two IP addresses for a mobile node, the home address and the Care-of Address (CoA). The home address of a mobile node represents the identity of the node and the CoA represents the location of the node. HIP (Host Identity Protocol) is a potential future Internet protocol where the location and identity information are separated from each other by introducing a new cryptographic namespace, called Host Identity (HI) (Moskowiz and Nikander, 2006). The HIs are globally unique public key in public key cryptography. The HIs are used to represent identities of hosts and the IP addresses are only used as locators. Mutual authentication of communicating parties and cryptographically protected network communication is supported by HIP, since the His are public keys. Present HIP implementations protect network communication using IPSec ESP (Internet Protocol Security Encapsulating Security Payload) technology. The described features make HIP suitable for a

2 future secure Internet, where the use of portable and mobile computers is continuously increasing. The same HI can be associated with multiple IP addresses and this mechanism can therefore accommodate both mobility and multi-homing. HIP is a strong candidate to complement current IP protocol and replace the Mobile IP protocol in the future because of the inherent security and mobility support of the cryptographic namespace introduced by HIP. Thus, teaching HIP protocol basics as a part of computer science education can be considered important already today. To learn HIP thoroughly is demanding, because learning the complex logistics and the detail richness of HIP requires good cognitive skills. Learning challenges are also understanding of the significance of a cryptographic namespace and how mobility support is implemented. A visual animation of this protocol is a significant tool in order to make it easier to learn and understand the protocol because cognitive skills are required. In this paper a net based HIP learning environment with a web interface is presented. This learning environment is a virtual learning environment, since it is net based. The paper is organized as follows. Initially the basic features of HIP protocol are described. Then the learning environment is presented including information about the animated HIP features, learning environment design issues, and IT infrastructure requirements. Two appendices are included, a detailed technical description of HIP and an overview of the human behaviour theory on which the learning environment design is based.

Overview of Host Identity Protocol (HIP) HIP is an IETF standard specified by the HIP Working Group, see http://www.ietf.org/html.charters/hip-charter.html. An overview of HIP specifications in current IETF RFC and draft documents is found in Appendix 1. In HIP, the location and identity information are separated from each other by introducing a new cryptographic namespace, called Host Identity (HI), to represent identities of hosts. IP addresses are used only as locators. This namespace is operated by the Host Identity Layer which resides between the network and the transport layer in the IP stack. The HIs and locators are dynamically bound to each other and the mapping is done at this new layer. Host Identities are cryptographic in nature. Each host has (at least) one public-private key pair. The public key of this pair is called the Host Identity (HI) of a network node. While the public key is long, it is represented by a Host Identity Tag (HIT), which is a 128-bit hash of the HI. In practise, this HIT is given to the application instead of the IPv6 address when it resolves the peer host’s address. If the application uses IPv4 API, a 32-bit Local Scope Identifier (LSI) is used instead. The byte value 1 in combination with the low order 24 bits of a HIT are used as an IPv4 compatible LSI. A HIT (or a LSI) is used only on the upper layers and it is mapped at the HI Layer to the correct IP address, which is used as a locator when data is transmitted in the network. Figure 1 depicts the differences of HIP with respect to the traditional IP stack. In the traditional IP architecture, the transport layer service points are defined by IP address and port pairs. In the HIP architecture these service points are defined by Host Identity and port pairs. The same HI can be associated with multiple IP addresses. This mechanism can therefore accommodate both mobility and multi-homing. Since a HI is a public key it is usually published. Resource Records (RR) in DNS and/or a Public Key Infrastructure can be used to publish HI values of HIP nodes. The dynamic binding of location and identity information in HIP provides an easy way to handle changing locators in a host, thus providing mobility support. When the host changes location, i.e. its IP address, the new location information is transmitted to all peer hosts using HIP mobility and multi-homing extensions. Each peer host can then update the binding between the HI and location with the new locator information.

3

Figure 1: Traditional IP (left) and HIP enhanced IP protocol stacks.

HIP Packets A HIP packet (Moskowitz et al., 2007) consists of a header and a payload consisting of zero or more HIP parameters. The HIT of the sender and the HIT of the receiver are included in the HIP packet header. HIP packet types are • Four HIP Base Exchange packet types. HIP packets of theses types are needed when a HIP connection is opened • CLOSE packet, a HIP connection closing packet • CLOSE_ACK packet, an acknowledgement packet to HIP connection closing packet • UPDATE packet. HIP packets of this type are used to change connection parameters and to acknowledge these changes. • NOTIFY packet. HIP packets of this type are used to indicate some type of protocol error or negotiation failure. HIP packet details are described in Appendix 1.

HIP Base Exchange and HIP Association When a HIP node, an Initiator, wants to communicate with another HIP node, a Responder, the Initiator gets the Responder's HIT and one or more IP addresses associated with the Responder either from a DNS lookup of the Responder's Fully Qualified Domain Name (FQDN), from some other repository, or from a local table. Node-to-node authentication and setup of a HIP Association with the HIP Base Exchange is required before data communication between two HIP nodes. The HIP Base Exchange is a four-way handshake which takes place between the Initiator and the Responder. HIP Base Exchange details are described in Appendix 1. All Base Exchange details are specified in (Moskowitz et al., 2007). After the Base Exchange, there is no difference between the Initiator node and the Responder node any longer. HIP communication is terminated by closing the HIP Association with CLOSE packet sent by either node. The other node must then acknowledge with a CLOSE_ACK packet

Protected End-to-End Communication Data communication between two HIP nodes can start only after a successful Base Exchange. For end-to-end protection of this data communication the Base Exchange must be extended with an

4 end-to-end security protocol setup. The preferred way of implementing HIP is to use IPSec ESP to carry the actual data traffic (Jokela et al., 2007). Also the use of the Secure Real Time Protocol (SRTP) (Bauger et al., 2004) transport format has been proposed (Tschofenig et al., 2006). The ESP specification (Kent, 2005) defines the ESP packet format for IPSec. The HIP ESP packet is exactly similar to the IPSec ESP transport format packet. An ESP Security Association (ESP SA) between hosts using HIP is set up by including certain parameters in HIP Base Exchange packets (see Appendix 1).

Node Mobility and Multi-homing A network node is considered to be mobile if its IP address can change dynamically for any reason. In order to be reachable by its peers, a mobile node must inform them about a new IP address. This is done by exchange of three HIP UPDATE packets between a mobile node and each peer: • the first UPDATE packet includes the new IP address and is sent from the mobile node to the peer • the second UPDATE packet is an acknowledgement sent from the peer. This packet also checks the new IP address of the mobile node • the third UPDATE packet is an acknowledgement of the second UPDATE packet. This packet is sent from the mobile node. In this exchange of UPDATE packets also the session key can be re-keyed. If re-keying is initiated by the mobile node, then the new Diffie-Hellman parameters are included in the two first UPDATE packets. If re-keying is initiated by the peer, then the new Diffie-Hellman parameters are included in the second and the third UPDATE packets. In this case also a fourth UPDATE packet is required to acknowledge the receipt of new Diffie-Hellman parameters in the peer. UPDATE packets are signed with the private key of the sender and are therefore authenticated by verifying the signature with the HI of the sender. (Henderson, 2007)

Multi-homing A network node is considered to be multi-homed if it has more than one network interface. i.e. it has more than one globally routable IP address at the same time on different interfaces. LOCATOR is the HIP parameter that enables both node mobility and multi-homing. This HIP parameter includes IP addresses for one or more network interfaces of the mobile node and is usually carried in a HIP UPDATE packet. (Henderson, 2007)

Rendezvous Server (RVS) In order to reach a mobile HIP node, its current IP address(es) must be stored somewhere. In principle Dynamic DNS could be used to update IP reachability information in the DNS (Vixie et al., 1997; Wellington, 2000). The main problem with Dynamic DNS is latency. The update is not fast enough when a mobile node moves. A static rendezvous infrastructure has been specified to solve this problem. All mobile node location updates are done at a rendezvous point. A Rendezvous Server (RVS) provides HIP reachability service to HIP nodes. In order to be reachable by any other HIP node, a HIP node must register to a RVS with the HIP Registration Protocol. This protocol, which is an extension to the Base Exchange between a HIP node and the RVS, is outlined in Appendix 1. After a HIP node is registered to a RVS • the HIT and the current IP address(es) of the HIP node are stored in the RVS

5 •

the IP address of the RVS should be stored in the DNS together with the HIT of a HIP node registered to this RVS. A new DNS resource record (RR) has been specified for this purpose (Nikander & Laganier, 2007)

When another HIP node, an Initiator, wants to communicate with a HIP node registered to this RVS as Responder, the DNS lookup of the Responders FQDN will return the HIT of the mobile node and the IP address of the RVS. The HIP Base Exchange between the Initiator and the Responder will then be relayed through the RVS. This HIP Base Exchange modification is described in Appendix 1. When the mobile node changes the location, it updates the current location to the RVS using the UPDATE message exchange. (Laganier and Eggert, 2006) The role of a RVS in the HIP architecture is thus analogous to the role of a Home Agent in Mobile IP. However, the difference is that in Mobile IP, the location of the Home Agent cannot be changed. The Home Agent must be located in the IP network to which the Home Address of the mobile node belongs. In case of RVS, the mobile host is not tied to one RVS. A RVS can be changed and a mobile host and a mobile host can even have multiple RVSs.

Security Considerations Since HIP utilizes its own public key cryptography based identification scheme, it is hence more resilient to routing attacks than Mobile IP. An example of a routing attack is a man-in-the-middleattack, when a hostile network node conquers the communication partner role in relation to two communication network nodes, and all communication between these two nodes goes through this hostile eavesdropping node. Man-in-the-middle attacks are excluded by • mutual node-to-node authentication provided by the HIP Base Exchange, which is required before any data communication between two HIP nodes • HIP signatures in UPDATE packets for HIP connection parameter changes. IPSec ESP or some other secure end-to-end transport format for data communication between two HIP nodes can be set up in the HIP Base Exchange.

Current HIP Implementations It needs to be pointed out that current HIP implementations are not fully compatible with each other. Most implementations are still under development and they are often built based on different revisions of the HIP specifications.

hip4inter.net This HIP implementation is developed by Ericsson Research, Finland. It is developed mainly for FreeBSD. The current version is 6.1. Linux compatible code is available but is not actively maintained and is currently outdated. The software consists partly of a server application and partly of HIP code inserted into the operating system kernel. An automated installer performs the entire installation process, including recompilation of the kernel. hip4inter.net uses hooks in the IPv6 component of the operating system to detect connection attempts utilizing HIP. When a user tries to establish a connection using a Host Identity Tag (which has an appearance, which is identical to an IPv6 address), the HIP service takes over and manages the connection. If a machine name is used, it is resolved to a HIT using AAAA records in the DNS database or the local /etc/hosts file. If no HIT can be found the connection cannot be

6 established and results in a “no route to host” situation. The HIP service uses ORCHID prefixes to distinguish a HIT from a real IPv6 address. Legacy IPv4 and IPv6 applications are supported and utilize LSI mapping as a bridge between the network layer and HIP. The most current version as of November 2007 is release 2007.11.14, which is built upon the IETF documents draft-ietf-hipbase-10, draft-ietf-hip-mm-05, and draft-ietf-hip-esp-06. It does not currently implement a rendezvous service, but such a service is under development. The project homepage is http://www.hip4inter.net.

InfraHIP This implementation is developed in a joint project of Helsinki Institute for Information Technology and Helsinki University of Technology. It is developed for Linux compatible systems. A precompiled and preconfigured version of InfraHIP is available for download on a bootable CD image which provides easy testing of the software. InfraHIP supports the use of OpenDHT to map HITs to IP addresses, in addition to a local mapping in /etc/hip/hosts. The most current version as of November 2007 is version 1.0.2. The project homepage is http://infrahip.hiit.fi/.

OpenHIP This HIP implementation is an open source project created, hosted and mainly contributed by Boeing. It has precompiled binary packages for Windows, Linux and MacOS X, in addition to the source code. OpenHIP uses a slightly different approach in detecting when connection attempts should utilize HIP. It hooks connection requests to machine names that have .hip appended, e.g. http://www.hiptestserver.net.hip. The OpenHIP project also hosts a HIP RR patch for the bind9 DNS server. However, testing showed some problems in the support of rendezvous service entries in the HIP DNS record. The most current version as of November 2007 is version 0.5 released October 22, 2007. This version is built upon the IETF documents draft-ietf-hip-base-06, draft-ietf-hip-esp-05, draft-ietf-hip-mm05, draft-nikander-hiprg-hi3, draft-ahrenholz-hiprg-dht, draft-ietf-hip-registration-00, and draftietf-hip-rvs-00 of the preliminary HIP specifications. The project homepage is http://www.openhip.org. The OpenHIP project hosts patches for the Wireshark protocol analyzer tool (see http://www.wireshark.org/) that enable it to decode and show information about HIP traffic. This patch is applied to the source code and is therefore available to all platforms that are supported by Wireshark.

Net Based Learning Environment “HIP animation” is a learning object, which can be integrated in virtual network courses as well as in traditional network courses. The chosen didactical approach is a structured animated network environment in which the communication between an Initiator and a Responder can be studied. The objective is to understand the HIP architecture, the Base Exchange, mobility and multi-homing, and the combination of HIP and ESP. The communication logistics for all options of the HIP can be studied on the highest level. Communication details, like the data packet header fields, can be interactively studied on lower levels of the animated environment. Similar learning environments could of course be designed also for other networking protocol, but design implementations are still protocol specific.

7

Animated HIP Features The learning environment should be a static and scalable framework for the dynamic features of Host Identity Protocol (HIP). The underlying visualization model of the HIP animation includes following features: • communication architecture • communication HIP nodes in different TCP/IP network sites • DNS and routing • Mobile HIP nodes and mobility support from a rendezvous server • data communication paths • flow of data packets on different layers of the network protocol stack • structure of data packets. Integration of additional HIP features is supported.

Learning Platform The learning platform is a Flash application. The animation is implemented in an environment where most elements are symbols. These elements thus have a conventional relationship to their referent. This means that the referents, the technical objects, are typically described with these more easily comprehended symbols or graphical elements. Internet is described with the help of white waves (“routes” in the Internet) on a brownish background and networks are described by transparent areas inside the Internet area. Routers and computers are described by traditional sized desk computers labeled with names. Data packets in data communication are described with rectangular boxes. Nevertheless there are also elements that are described through their imaginable physical appearance. These elements are the information flow that is described with a packet flow and the radio signals that are described with a flow of waves. In every scene the user has the possibility to study how the data flow appears on each data layer. As he moves between the different layers, the animation environment is enriched (or impoverished) by elements that, in that particular layer, seem to take part of the data flow. Therefore, for example, when the data flow is animated on the application layer, there are only two computers that communicate with each other. But when the animation goes down to the transport layer, ports are added to the computers and the communication between the computers is now realized between two particular ports. See screen snapshot sequence in Figure 2. The animation environment is designed to help the study process and to establish a connection between theory and reality as all the levels of communication are brought to the highest level of abstraction through a physical appearance. The implemented Host Identity Protocol becomes comprehensible for everybody as it is in a recognizable and imaginable environment. The animation is structured through a division of the learning material into six scenes with their respective detail scenes. Besides helping the comprehension of the animation and its contents, this division also contributes to reducing the consequences of errors that a user might commit when navigating in the product. It also renders the use of the product easier as the search times for particular events are shorter than in an animation without scenes.

8

Figure 2: In this screen snapshot sequence the animation flow of scene one is presented. The animation starts with application layer communication and via transport layer communication it ends in network layer communication.

User Interface Design Issues Based on the theories on human behavior (see Appendix 2), we can compile a list of topics that we should think through and answer when designing a user interface to our product: 1. What does the user want to achieve by using this product and does the product give the opportunity to reach this goal? 2. Which are the different product modes, how are they visualized and do they become evident? 3. What could the action models of the user be? 4. Do the action models of the user correspond to the possible actions offered by the interface? 5. Do the possible actions give proper feedback to the user? 6. When a new user is interpreting the verbal and graphical signs of the interface, can he rely on analogies and are the signs described in a way which is relevant to their effects. In other words, will he be able to understand the interface without reading the guidelines? 7. Do text and audio compensate each other? 8. What is the length of the words in the menus and in other attention drawing elements? As the topics go from a very wide perspective to a very narrow one (the last bulletin considers only the composition of single element) they try to include the main problems regarding the design of a graphical interface for a learning object like an animation. Here we will analyze the learning platform by the means of these eight topics.

9 What does the user want to achieve by using this product and does the product give the opportunity to reach this goal? The answer to the first question can seem quite obvious, to learn the Host Identity Protocol. However, we have to bear in mind the different types of information that the user could be interested in. Especially a returning user could actually just be looking for a particular detail of the protocol, and doesn’t want to go through the animation just to find that small set of information that he is interested in. Therefore the interface is planned in a way that allows the HIP material to be divided into different scenes and levels. Also all the controls and elements in the menus are designed to support this. Which are the different product modes, how are they visualized and do they become evident? The animation consists of two scene types. The main scenes that can be opened from the scene menu on the left (see Figure 3) are scenes where you can’t see the details of the packets that are sent over the networks. The (main) scene menu is a simple grouping of numbers from one to six where each number refers to one main scene. When a main scene is playing, the number that the scene represents will be surrounded by the gray frame that surrounds the movie field. The detail scenes are offered to the user only after opening a main scene, but only if the main scene in question has detail scenes. The detail (scene) menu appears under the movie field. When a detail scene is playing the color of the details scene (orange for detail scene one, blue for detail scene two and so on) will highlight the movie field frame (see Figure 4). The differing frame visualization of these two scene modes underlines their different content: the main scenes describe the information flow and the detail scenes describe message details.

Figure 3: The elements of the interface are (1) Scene menu, (2) Detail menu, (3) Control panel, (4) Layer menu, (5) Flow bar, (6) Audio text area, and abbreviations and definitions area.

10

Figure 4: Here a detail scene is playing and the details of a packet are visible. In addition to the scene modes, the product has two different kind of playing modes. You can choose to play the scenes one by one, as one single long animation, or you can also choose to play one scene at a time. When you play the animation having chosen the second option, the animation stops at every scene and layer transition point. The scope with the playing mode feature is that if you only want to see one scene or a part of a scene (a layer) you can do so without playing the whole animation. We applied this option instead of a “stop” option, as it would have been technically a much bigger challenge to realize the second one. The playing modes buttons are located in the control panel under the movie field (see Figure 3). Clicking on them when you are on the homepage brings you to scene one. But once the user is already playing a movie, if he then changes the mode from continuously to scene-by-scene mode, it seems like the action wouldn’t have an effect on the playing of the animation. In other words, it seems that the action doesn’t have consequences on the forth going of the animation like it should have. But actually it does have an effect. When the animation reaches a transition point, which are all the transitions from one layer to another (the information flow in the scenes is divided into different layers and this division is evidenced by the layer menu on the top of each scene, see Figure 3) or from one scene to another, it doesn’t automatically go forward to the next layer or scene as it would have done in continuously mode. Instead it stops at that transition point. The option would have been that the button would reload the current scene, as a feedback of the users’ action to choose another playing mode. This seemed unnecessary especially in situations, when the intervals between the transition points are quite short and the user will get feedback of his

11 action as soon as he reaches that point. Moreover, the button itself gives feedback of being chosen (the gray frame becomes yellow). The continuously mode is the default mode, i.e. if you choose a scene from the scene menu, the mode is automatically continuously. What could the action models of the user be? A user who returns to the product or a user who is familiar to a similar learning object will probably want to start the animation as soon as he opens the product. He will want to open the audio text area when he realizes that it is not open by default. He may have got acquainted to the “play faster” function that lets you skip the beginning explanation of every scene, and searches for the button that enables this function. On the opposite, a new user would most likely want to read some information about the product, to fully understand what he can gain by using it. He could be interested to open an introduction to the animation, and he may even want to read the user guidelines. But most likely he’ll rapidly explore the interface and grabs on to the element that seems to bring him forward in the animation. Do the action models of the user correspond to the possible actions offered by the interface? It is important, for the reasons mentioned in the previous answer, that the trained user can get started with the animation as quickly as possible. Therefore the scene menu, which consists of big numbers that are easy to read and comprehend (they have an efficient relationship to their effect), is placed on the top left, where the users eye looks when he comes to a new website (at least in left to right reading countries). When the user brings the mouse over one of the scene buttons, a scene description appears to clarify the content of the particular scene. A trained user knows what kind of features and functions he is and can be looking for, and therefore a large number of attention drawing elements placed in the environment can be irritating for him. However, a new user has to be considered. If he is impatient and starts to use the product without having read the guidelines, some important elements, like the audio text area and the control panel, could be left unnoticed. This is why it is important that the two text areas and the control panel draw attention in some way. Because a new user would probably not expect that the interface has two text areas (not common elements), these text areas must draw attention to themselves (the user does not seek them). Here this is realized by using a different color in their layout compared to the rest of the interface. On the contrary, the control panel will most likely get noticed even though it doesn’t graphically draw attention to itself, as at some point the user will want to return home or to mute the animation. The user knows that these actions exist (every product tends to have such actions) and he goes looking for them in the interface. When he finds these actions he’ll find also the other functions (the two playing modes and the play faster function). The home page is planned for a new user, although it is easily “jumped over” when you’re not interested in the information given in it. On this page, and on the pages linked to it, is introduced all the relevant information regarding the topic, the interface and the animation environment. For users finding themselves on this page simply because they don’t know how to go forward, a solicitation to start the animation or the introduction movie appears after a while. Do the possible actions give proper feedback to the user? Both the scene menu and the control panel give not only a graphical feedback, but also a further explanation (text) of what the button does. The buttons in the scene menu act upon command. With this we mean here that, immediately after the users action (button press), the scene changes to the chosen one, and therefore the feedback is visible. Some buttons in the control panel work in a different way, as only the home and audio on/off buttons act upon command and give

12 immediate feedback to the user. Buttons play continuously and play scene by scene act upon command only when the platform is at the home page. In other modes they have a visible effect only at a transition point (as previously described). Also the activation of the skip/hear beginning explanation function is visualized only at a particular point; when a new scenes is uploaded it plays (default) or skips the beginning explanation of every scene. All buttons in the control panel therefore gives at least some immediate feedback and the graphical feedback is emphasized in this menu. In addition to a change in the button image, an action of the user action has an effect also on the text on the left side of the control panel, where all viewing preferences of the user are listed (play continuously, audio on and hear beginning explanation are defaults). An ulterior menu is the menu layer that is situated inside the animation. It describes itself quite well as it asks the user to see the scene in different layers and the layer buttons are named after the layer in question. It also acts upon command. When a new user is interpreting the verbal and graphical signs of the interface, can he rely on analogies and are the signs described in a way which is relevant to their effects? In other words, will he be able to understand the interface without reading the guidelines? The first question concerns especially the control panel, the text areas and the detail menu. Let’s go through them one by one. There are five buttons in the control panel. The home button is represented with a well known sign; a house. The two playing modes could not be described with conventional signs. Therefore a graphically explicative motive was chosen (icon). A path that continues without interruptions stands for play continuously and a path divided into two parts stands for play scene by scene. As long as these buttons are found and tried out, there shouldn’t be a problem understanding their purpose. The typologies of the signs on the audio on/off button are called indexes, as they are effects of the cause: when the audio is on then the animation will talk (bla bla) and, on the contrary, when the audio is off then the animation is quiet (shh). The last button, the hear/skip beginning explanation button, is the only button that does not have an efficient relationship to a referent. The user must actually read the explicative text that appears under the button to understand the button functionality. The actual solution was considered to be the best one as the action couldn’t be referred to, graphically, in an easy way. Conventional signs haven’t been established since this is not a common functionality. The text areas are simply named as audio text and abbreviations & definition, explaining their content in their headlines. The biggest problems in the design were • to describe the difference between main scenes and detail scenes • to show, in a visible manner, to the user in which scene he currently is. Solutions to both problems are important for the goal of users. Therefore these problems must be noticed and solutions must be found at the right moment in the animation. These problems were resolved by giving the detail menu buttons a particular color (orange for detail scene one, blue for detail scene two and so forth) and by framing the movie frame with the same color when a detail scene is playing (see Figure 4). As the interface can be used with minimum amount of actions, it is possible to use the product without having to read the guidelines, although it is still recommended that the user would read them. It’s actually sufficient that the user chooses a scene (hopefully he starts from scene one!) and responds to the control pop up’s of some events (for example if the user wants to see the detail scene), and the environment takes care of the rest by playing the entire animation. The other functions, play scene by scene, audio off, skip beginning explanation, see audio text and abbreviations & definitions, are benefiting features, but are not necessary for using the product. Do text and audio compensate each other? Yes, everything that is said is also in written form, placed in the audio text area. However, the

13 graphical text in the scenes of the animation is not included in the audio. What is the length of the words in the menus and in other attention drawing elements? The only menu that consists of text is the layer and detail menu. In both menus the buttons are described with two words. In the detail menu the button words are short and identical, only with the digits 1 or 2 (when multiple detail scenes) attached to the words. In the layer menu the second word is always the same (layer) and therefore the attention goes automatically to the first word; it is between 4 and 11 letters. In other words we remain within the recommendation of at most 12+4 letters. Also the explanation tags on the elements in the animation environment (for example “DNS” and “host” on computers) are short and have less than 12 letters.

IT Infrastructure Requirements Offering the product requires an Apache www server with installed Secure Socket Layer (SSL) support for secure authentication of learning environment users. User authentication to a virtual course, into which the HIP learning environment has been integrated, is necessary. Email address, mobile phone number and Skype address of the user are needed for communication with course teachers. Requisites for using the product are a high bandwidth Internet connection, a Flash Player that can be downloaded from the website of Macromedia (http://www.macromedia.com), and loudspeakers or headphones. Nevertheless, the animation can be seen without sound as it contains all the audio also as text. A relatively high screen resolution is another important hardware characteristic that is needed for playing the animation properly. In a 800 x 600 pixel resolution screen not even the whole animation area is fully visualized and the user must scroll both vertically and horizontally to see all corners of the learning platform. With a 1024 x 768 pixel resolution all except the text area is fully visualized. In all screens with 1280 x 1024 pixels and more the learning platform is fully visualized. Therefore a computer screen with a resolution of at least 1024 x 768 pixels is recommended. In other words at least a laptop is needed for optimal use of this product. A PDA is not sufficient. The product works with the browsers Mozilla Firefox and Internet Explorer.

Conclusions In this paper we have, given an overview of the Host identity Protocol (HIP) and pointed out the main challenges in teaching the functionality of the protocol. The development of a virtual HIP learning environment has been presented. The structure of the learning environment has been described in detail and different issues that have to be considered when designing such a product have been discussed. The amount of virtual learning environments (VLEs) is constantly increasing and they have turned out to be effective teaching tools in education. Based on several case studies it has been stated that virtual learning environments overall are suitable for higher education (Koskela et. al., 2005). In (Piccoli et. al., 2001; Marandi & Luik, 2003; Zhang et. al., 2004) it was proved that VLE:s are even more effective than traditional lecturing since the VLE students outperformed the traditional lecture students. These case studies were mainly performed in the area of information and communications technology. HIP is a potential future protocol to replace current IP and Mobile IP protocols. Thus, teaching HIP in IT education is relevant even though the protocol is still only in the development phase. HIP is a complex protocol with many options and extensions. The creation of a virtual learning environment is thus a demanding challenge.

14 In the learning environment, presented in this paper, an approach based on a graphical animation of the HIP protocol has been chosen. An animated network environment is an important tool in learning the functionality of a complicated protocol. Based on earlier teaching experiences, animation of network protocols has been a useful learning tool for students in networking courses (Bergström et. al., 2006). However, the production of a virtual learning environment requires a lot of effort. Experts, like graphical designers, have to be included in the production team. Prototypes have to be tested and feedback from students is needed before the learning environment is in its final form. A proper choice of computer software and IT technology as well as a sufficient and realistic budget are essential issues.

References Baugher, M., McGrew, D., Naslund, M., Carrara, E., and Norrman, K. (2004). The Secure Real-Time Transport Protocol. IETF RFC 3711 Bergström, L., Grahn, K. and Pulkkis, G. (2006). A Virtual Learning Environment for Mobile IP. In Proceedings of 2006 Informing Science and Information Technology Education Conference InSITE2006. Manchester. England. pp. 83-101. ISSN 1535-07-03 Henderson, T (ed.) (2007). End-Host Mobility and Multihoming with the Host Identity Protocol, IETF Internet Draft draft-ietf-hip-mm-05 Jokela, P., Moskowitz, R., and Nikander, P. (2007). Using ESP transport format with HIP. IETF Internet Draft, draft-ietf-hip-esp-06 Kent, S. (2005). IP Encapsulating Security Payload (ESP), IETF RFC 4303. Koskela, M., Kiltti, P., Vilpola, I., and Tervonen J. (2005). Suitability of a Virtual Learning Environment for Higher Education. In Electronic Journal of e-Learning, Vol. 3, Issue 1, pp. 21-30. Laganier, J. and Eggert, L. (2006). Host Identity Protocol (HIP) Rendezvous Extension. IETF Internet Draft draft-ietf-hip-rvs-05 Marandi, T. and Luik, P. (2003). Teacher Training – With or Without Computers? In Proceedings of the 2nd European Conference on e-Learning, Roy Williams (Ed), Academic Conferences International Reading, UK, pp. 303-310. Moskowitz, R. and Nikander, P. (2006). Host Identity Protocol (HIP) Architecture. IETF RFC 4423. Moskowitz, R, Nikander, P., Jokela, P. (ed.), and Henderson, T. (2007). Host Identity Protocol. IETF Internet Draft, draft-ietf-hip-base-07 Nikander, P. and Laganier, J. (2007). Host Identity Protocol (HIP) Domain Name System (DNS) Extensions. IETF Internet Draft, draft-ietf-hip-dns-09 Piccoli, G., Ahmad, R. and Ives, B. (2001). Web-Based Virtual Learning Environments: A Research Framework and a Preliminary Assessment of Effectiveness in Basic IT Skills Training. MIS Quarterly, Vol. 25, No. 4, pp. 401-426. Tshofenig, H., Muennz, F., and Shammugam, M. (2006). Using SRTP transport format with HIP. IETF Internet Draft, draft-tshofenig-hiprg-hip-srtp-03. Vixie, P., Thomson, S., Rekhter, Y., and Bound, J. (1997). Dynamic Updates in the Domain Name System (DNS UPDATE). IETF RFC 2136 Wellington, B. (2000). Secure Domain Name System (DNS) Dynamic Update. IETF RFC 3007. Zhang, D., Zhao, J. L., Zhou. L. & Nunamaker, J. F. Jr. (2004). Can e-Learning Replace Classroom Learning? Communications of the ACM, Vol. 47, No. 5, pp. 75-79.

15

Appendix 1: Technical Description of Host Identity Protocol (HIP) This technical description of HIP consists of • An overview of HIP specification • HIP packet details • HIP base exchange details. All these HIP details can be studied in the implemented learning environment.

HIP Specifications The Internet Engineering Task Force IETF hosts documents describing the Host Identity Protocol (HIP), see http://www.ietf.org/html.charters/hip-charter.html. HIP is still not fully standardized, but IETF maintains draft versions of specification documents. Because these documents do not describe standards, they are somewhat speculative and do not give solutions to some open issues. These drafts rather discuss how HIP could be specified in future revisions. The current HIP documentation consists of the following ten documents, which describe the protocol on a conceptual level and present some exact technical specifications: 1. Host Identity Protocol (HIP) Architecture (RFC 4423) (http://www.ietf.org/rfc/rfc4423.txt) 2. Host Identity Protocol (http://www.ietf.org/internet-drafts/draft-ietf-hip-base-10.txt) 3. End-Host Mobility and Multi-homing with the Host Identity Protocol (http://www.ietf.org/internet-drafts/draft-ietf-hip-mm-05.txt) 4. Host Identity Protocol (HIP) Domain Name System (DNS) Extensions (http://www.ietf.org/internet-drafts/draft-ietf-hip-dns-09.txt) 5. Host Identity Protocol (HIP) Rendezvous Extension (http://www.ietf.org/internet-drafts/draft-ietf-hip-rvs-05.txt) 6. Using ESP transport format with HIP (http://www.ietf.org/internet-drafts/draft-ietf-hip-esp-06.txt) 7. Host Identity Protocol (HIP) Registration Extension (http://www.ietf.org/internet-drafts/draft-ietf-hip-registration-02.txt) 8. HIP Extensions for the Traversal of Network Address Translators (http://www.ietf.org/internet-drafts/draft-ietf-hip-nat-traversal-02.txt) 9. Native Application Programming Interfaces (APIs) for Host Identity Protocol (HIP) (http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-03.txt) 10. Using the Host Identity Protocol with Legacy Applications (http://www.ietf.org/internet-drafts/draft-ietf-hip-applications-02.txt)

HIP architecture RFC 4423 is the most conceptual document describing the HIP architecture in general. It describes the key concepts of the protocol; the methods by which host identities are used and how HIP as a concept would work within the constraints of the real Internet. Solutions to problems that these constraints produce, such as the Local Scope Identifier in legacy applications and how HIP deals with the problem of being used from a network using NAT (Network Address Translation), are discussed. This document also briefly describes all the other topics that are discussed in more detail in the technical specifications for the different components.

Base Exchange The document draft-ietf-hip-base-10 (expires May 2, 2008) describes and specifies the base exchange, where specific information packets (I1, R1, I2 and R2) are passed between the

16 communicating hosts for the purpose of establishing trusted data communication by e.g. detecting tampered data packets and verifying each others identity. If ESP encryption is used, the procedure of generating secure keys is done as a part of the Base Exchange. The document also discusses security considerations related to the Base Exchange topic.

Use of Encapsulated Security Payload encryption with HIP The document draft-ietf-hip-esp-06 (expires December 13, 2007) describes and specifies the use of ESP (Encapsulating Security Payload) to encrypt HIP communication between hosts.

HIP extensions for DNS The document draft-ietf-hip-dns-09 (expired in October 15, 2007) describes and specifies how a Host Identity, a Host Identity Tag, and rendezvous information are stored in DNS records. It is worth noticing that as of December 2007 few (if any) implementations of HIP actually retrieve HIP information as described in this document. It is more common to use a local file that maps IP addresses and Host Identity Tags, or to store the HIT as an IPv6 (AAAA) record in DNS. Distributed Hash Tables (DHT, see http://www.opendht.org/) are used as an alternative to DNS by the InfraHIP implementation (see http://infrahip.hiit.fi) to store HITs and IP addresses. In DHT a HIT is used as a search key to look up an IP address. DHT is not part of the IETF specifications of HIP.

Registration for services The document draft-ietf-hip-registration-02 (Expired in December 9, 2006) describes and specifies how a client using HIP can request registration for a service e.g. to use a rendezvous service. This document is related to, and extends the Base Exchange document.

Mobility and Multi-homing In the document draft-ietf-hip-mm-05 (expired in September 3, 2007) the concepts “mobility” and “mobile hosts” are largely related to wireless devices that cannot maintain a static address. The document describes and specifies solutions to problems related to HIP when used by mobile devices, how a device can maintain a connection using HIP. The multi-homing sections describe and specify solutions to the problems that occur when a device has several IP addresses. The mobility issues in this document are related to the situation when a node has already established a connection to another node. The rendezvous extensions document specifies how a node can establish a HIP connection to another node without knowing the network level address.

The rendezvous extension The draft-ietf-hip-rvs-05 (expired in December 9, 2006) describes and specifies the technique used to establish a connection to another node using HIP, without knowing the network level address. The solution presented here is about using rendezvous servers which maintain databases with mappings between host identities and their current network level addresses. The IP address of the Rendezvous Server used by a host is registered in a HIP DNS record for such a host. A host wishing to be available despite not being available through network-level addresses in DNS (or in any other system) can register with a Rendezvous Service. The Rendezvous Service is automatically given the current network-level address by the host using it. Hosts connected to a host using a Rendezvous Service are automatically sent information about updated addressing information.

17

HIP over network using NAT or firewalls The document draft-ietf-hip-nat-traversal-02 (expires January 7, 2008) describes and specifies the technique used to handle the problem of accessing a HIP node that is inside a local NAT network or behind a firewall. A typical problematic situation is when a NAT device cannot resolve incoming connections to the intended recipient. Such situations can occur, because a NAT device is not preprogrammed to forward incoming connections, which do not belong to an established connection. Firewalls produce a similar, although intentional, effect.

HIP Packet Details The structure of a HIP packet (Moskowitz et al., 2007) is shown in Figure A1. The HIP header is logically an IPv6 extension header and includes the following fields: • Next Header. This 8-bit field is not utilized in the current HIP specification. Its value is decimal 59, which is the No Next Header value in IPv6. • Header Length. This 8-bit field contains the length of the HIP Header and HIP parameters in 8-byte units, excluding the first 8 bytes. Since all HIP packet headers contain the sender's and receiver's HIT fields, the minimum value for this field is 4 and the maximum length of the HIP Parameters field is 255*8-4*8 bytes= 2008 bytes. • Packet Type. This 8-bit field indicates the HIP packet type. HIP packet types are o I1, R1, I2, and R2. HIP Base Exchange packets with Packet Type values 1,2,3, and 4 respectively o CLOSE. HIP connection closing packet with Packet Type value 8 o CLOSE_ACK. Acknowledgement packet to HIP connection closing packet with Packet Type value 9 o UPDATE. HIP UPDATE packets with Packet Type value 16 are used to change connection parameters and to acknowledge these changes. o NOTIFY. HIP NOTIFY packets with Packet Type values 17 are typically used to indicate some type of protocol error or negotiation failure. NOTIFY packets are unacknowledged • Version. This 4-bit field indicates the HIP version number. The current version number is 1. • Reserved. This 3-bit field is reserved for future use. These bits must be zero in a sent HIP packet. • The two fixed bits in the header. These bits are reserved for potential compatibility with the Level 3 multi-homing shim protocol (Bagnulo and Nordmark, 2006). • Sender’s and Receivers HIT. The length of the HIT fields is always 128 bits (16 bytes). • Controls. The 16-bit HIP Controls field conveys information about the structure of the packet and capabilities of the node. In HIP VERSION 1 only the last bit has been defined: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | | | | | | | | | |A| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A means Anonymous. If A is set, then the sender's HI in this packet is anonymous, i.e. not listed in a directory. Anonymous HI values should not be stored. This control is set in R1 and/or I2 packets. The peer receiving an anonymous HI may choose to refuse it. The other bits in the Controls field are reserved for future use and must be set to zero in sent HIP packets. • Checksum. Since the 16-bit checksum covers the source and destination addresses in the IP header, it must be recomputed on HIP-aware NAT devices. HIP parameters following the header define HIP signaling information that is exchanged between HIP nodes.

18

Figure A1: Format of a HIP Packet (Moskowitz et al., 2007).

HIP Base Exchange Details When a HIP node, an Initiator, wants to communicate with another HIP node, a Responder, the Initiator gets the Responder's HIT (HITR) and one or more IP addresses either from a DNS lookup of the Responder's FQDN, from some other repository, or from a local table. Node-to-node authentication and setup of a HIP Association with the HIP Base Exchange is required before data communication between two HIP nodes. The HIP Base Exchange is a four-way handshake which takes place between the Initiator and the Responder. An outline of the HIP Base Exchange is shown in Figure A2. All Base Exchange details are specified in (Moskowitz et al., 2007).

Figure A2: Outline of HIP Base Exchange (Moskowitz et al., 2007).

19 The four Base Exchange HIP packets I1, R1, I2, and R2 include the Initiator’s and Responder’s HIT values (HITI, HITR) in the packet header. However, the Initiator may replace HITR with NULL in I1, if HITR is not known by the Initiator before the Base Exchange. This type of connection initialization is called Opportunistic Mode. The other parameters are HIP parameters, which are essential for the Base Exchange. The packets R1, I2, and R2 are signed with the private key of the sender. Both HIP nodes authenticate each other by verifying signatures of received packets with the HI of the sender. The Initiator is also in packet R1 challenged by the Responder with a puzzle, to which a correct solution must be included in packet I2. In the Base Exchange the Initiator and Responder also agree on a symmetric session key with the Diffie-Hellman protocol. HIP Association keys are derived from the Diffie-Hellman keying material. The Initiator’s HI (HII) in message I2 may be encrypted with the HIP Association key.

HIP Base Exchange with ESP Setting up an ESP Security Association (ESP SA) between hosts using HIP consists of three messages passed between the hosts. The needed parameters are included in R1, I2, and R2 messages during Base Exchange (see Figure A3): • The R1 message contains the ESP_TRANSFORM parameter, in which the sending node defines the possible ESP transforms it is willing to use for the ESP SA. • The I2 message contains the response to an ESP_TRANSFORM received in the R1 message. The sender must select one of the proposed ESP transforms from the ESP_TRANSFORM parameter in the R1 message and include the selected one in the ESP_TRANSFORM parameter in the I2 message. In addition to ESP_TRANSFOM, the sending node includes the ESP_INFO parameter, which contains the Security Parameter Index (SPI) value to be used by the peer node. • In the R2 message, the ESP SA setup is finalized. The packet contains the SPI information required by the Initiator for the ESP SA.

Figure A3: HIP Base Exchange with ESP SA Setup extensions (Jokela et al., 2007).

HIP Registration Protocol In order to be reachable by any other HIP node, a mobile HIP node must register to a RVS with the HIP Registration Protocol. This protocol is an extension to the Base Exchange between a HIP node and the RVS (see Figure A4). The RVS informs the HIP node about its rendezvous

20 registration type with the REG_INFO parameter in a R1 packet. The HIP node requests rendezvous registration with a REG_REQUEST parameter in an I2 packet and the RVS grants this rendezvous registration with a REG_RESPONSE parameter in a R2 packet. (Laganier and Eggert, 2006)

Figure A4: Protocol for a HIP Node registration to a RVS (Laganier and Eggert, 2006). After a HIP node is registered to a RVS • the HIT and the current IP address(es) of the HIP node are stored in the RVS • the IP address of the RVS should be stored in the DNS together with the HIT of a HIP node registered to this RVS. A new DNS resource record (RR) has been specified for this purpose (Nikander & Laganier, 2007)

HIP Base Exchange through a Rendezvous Server (RVS) When another HIP node, an Initiator, wants to communicate with a HIP node registered to a RVS as Responder, the DNS lookup of the Responders FQDN will return the HIT of the mobile node and the IP address of the RVS. The I1 packet of the Base Exchange between the Initiator and the Responder will then be relayed through the RVS (see Figure A5) and the current IP address stored in the RVS is used as the destination address. When the mobile node changes the location, it updates the current location to the RVS using the UPDATE message exchange. (Laganier and Eggert, 2006).

References Bagnulo, M. and Nordmark, E. (2006). Level 3 multihoming shim protocol, IETF Internet Draft, draft-ietf-shim6-proto-07 Laganier, J. and Eggert, L. (2006). Host Identity Protocol (HIP) Rendezvous Extension. IETF Internet Draft draft-ietf-hip-rvs-05 Moskowitz, R, Nikander, P., Jokela, P. (ed.), and Henderson, T. (2007). Host Identity Protocol. IETF Internet Draft, draft-ietf-hip-base-07 Nikander, P. and Laganier, J. (2007). Host Identity Protocol (HIP) Domain Name System (DNS) Extensions. IETF Internet Draft, draft-ietf-hip-dns-09

21

Figure A5: HIP Base Exchange with a Responder registered to a RVS. I, R, and RVS are the IP addresses of the Initiator, Responder, and RVS respectively (Laganier and Eggert, 2006).

Appendix 2: A Theory on the Structure of Human Behavior The structure of human behavior can be described through the following three steps (Sinkkonen, 2002): -

Firstly, we act upon a goal. If we do not have a goal, our behavior is not intentional. It is important to consider what goals the user might have, to be able to understand his intentions and what he is looking for in a product.

-

Then we decide to act. We decide to do something to change the current status, or mode, of the product.

-

At last we’ll evaluate the result of that action. To be able to evaluate the action, the interface has to give us feedback from our actions. Therefore feedback is an essential function of every element in a users interface and the use of an interface can not be learned without feedback. Evaluation has two purposes. One is to find out if an action has to be made or is the product already in the wanted state. In other words, the current state of the product has to be visible (beginning feedback). The other purpose of evaluation is to find out if the system functions as it should function and if the goal has been reached (end feedback). The second kind of feedback has to be a clear and an immediate effect of what a user is doing. This is also the initial feedback for the next action.

According to the TOTE (test-operate-test-exit) model, human action is based on feedback loops

22 where evaluation (testing) and action (operating) are repeated until the user reaches a situation that is satisfactory and therefore decides to exit the situation (Miller, 1960). By taking in consideration these two aspects of human action, we can plan an interface that allows users to spend their full cognitive resources on the task, and not on the interface. According to Norman’s theory, which divides any human activity into seven different stages of activities, this is achieved by minimization of the gulfs of execution and gulfs of evaluation (Norman, 2002; Griffiths, 2007). The gulf of execution is in the seven step cycle the gap between intention and action, and the gulf of evaluation is the gap between perception and evaluation. Before we come as far as evaluating and acting, we percept the product with our sense of sight and hearing, give our attention to some elements over others, observe the stimulations given by the product and interpret these according to different personal and cultural factors, including knowledge and prior experience (Sinkkonen, 2002). -

Our sense of sight is structured in a way that we can focus only on one thing at a time, even though our brain handles at the same time the information that is placed outside our range of focus (in the range of sight). This means that only one screen element at a time should be active (need attention). What comes to perception and text on screen, we are able to focus only 12 letters forward and four letters backward (the amount of letters forward and backward is cultural dependent). This should be taking in consideration especially when planning elements to a (terminological) menu. Audio and image compensate each other and therefore audio should not replace image or text. Another tip to remember is that text and audio should always be the same because we can not listen to one text and read another text. A readable text is better for beginners as they are able to go through it at their own speed.

-

We give our attention to a particular element in the interface by selecting the attention point consciously, automatically or by reflex. Higher cognitive operations (like learning) are possible only when we consciously give our attention to something.

-

An environment that offers too much stimulation and information can be misinforming, as the observation of only one element can become impossible and lead to a situation where the important information will get lost (noise).

A first time user is, hopefully, a conscious user and acts based on that. The user has probably an idea of how to start to use the product (relying on analogies). Normally a new user focuses on terminology and therefore he goes through the menus and links, searching for the term that suites his goals. He searches for meaningful and known elements that will lead him to his goal. If no known words are found, the next thing he’ll do is to look for synonyms or words that could mean the same. Finally, if nothing is found, the user leans to exclusion. According to the previously cited model of Norman, the task from intention to action can be extremely demanding when starting to use a product for the first time (Sinkkonen, 2002). Normally the user tries to figure out the new interface, for example through analogies between possible actions and his goal, through conventions known to him, or through exploration of the visual elements and its symbols. Only when he can’t figure out himself how to use the product, he decides to read the user guidelines. Therefore, considering principals like visibility, presentation of operations and results in a coherent, consistent system image, efficient relationships between elements and their effects (the relevance of the word or sign used) and feedback is of extreme importance when designing elements for an interface. (Norman, 2002; Griffiths, 2007)

References Griffiths, R. (2007) Norman's gulfs of execution and evaluation. Lecture Notes. Retrieved March 11th, 2008, from http://www.it.bton.ac.uk/staff/rng/teaching/notes/NormanGulfs.html

23 Miller, G.A., Galanter, E., and Pribram, K.H. (1960). Plans and Structure of Behavior. Holt, Rinehart & Winston. Norman, D. A. (2002). The design of every day things. New York: Basic Books. Sinkkonen, I., Kuoppala, H., Parkkinen, J. and Vastamäki, R. (2002). Käytettävyyden psykologia. Helsinki: Edita Oyj/IT Press.

Biographies Laura Bergström has a BSc in Media Culture from Arcada University of Applied Sciences, Helsinki, Finland. Since March 2002 she works for Arcada University of Applied Sciences as graphical designer in virtual education development.

Johan Fröjdman is presently a BSc (Eng) student in Information Technology at Arcada University of Applied Sciences, Espoo Finland.

Kaj J. Grahn, Dr. Tech., is presently senior lecturer in Telecommunications at the Department of Business Administration, Media, and Technology of Arcada University of Applied Sciences, Helsinki, Finland. His current research interests include Wireless and Mobile Network Security.

Jonny Karlsson has a BSc in Information Technology from Arcada University of Applied Sciences, Helsinki Finland. Since May 2002 he has been working in Arcada University of Applied Sciences as a course assistant and course teacher in programming and network security related courses and as a research assistant. His current research interests include Wireless and Mobile Network Security.

24

Göran Pulkkis, Dr. Tech., is presently senior lecturer and researcher in Computer Science and Engineering at the Department of Business Administration, Media, and Technology of Arcada University of Applied Sciences, Helsinki, Finland. His current research interests include Network Security and Applied Cryptography.