IPsecLite: A Tool for Teaching Security Concepts Niakam Kazemi
Shiva Azadegan
Department of Computer and Information Sciences Towson University, Towson MD, U.S.A.
[email protected],
[email protected] communications at Internet (network) layer of Transmission Control Protocol/Internet Protocol (TCP/IP). IPsecLite can also be used for teaching basic concepts of communication networks, replay and tampering (such as spoofing) attacks, cryptographic algorithms, and IPsec performance evaluation and analysis.
ABSTRACT Active learning and using visualization tools provide an effective approach in computer science education. Without meaningful hands-on exercises or access to training tools, it is usually difficult for students to understand or elaborate on complex algorithms, protocols, and concepts underlying different aspects of computing. This paper introduces a tool, IPsecLite, which demonstrates the inner-working of IP Security (IPsec) standard. Built on many networking technologies and cryptographic techniques, IPsec provides services to secure network communication. We introduce IPsecLite through a series of labs that can be used in several security courses. IPsecLite is fully developed and can be easily integrated into curriculum.
In creating IPsecLite we emphasized on effectiveness, feasibility, and efficiency. Effectiveness refers to the tool’s contribution in accomplishing lessons’ Learning Objectives (LOs) when teaching (or studying) a topic. Feasibility refers to whether the user can provide the required resources to use the tool. Efficiency refers to the ratio of a) learning objectives that are met (when the tool is used) to b) the resources that are required to use the tool. An effective tool is not necessarily efficient. For example, a general purpose tool may be used to build models that are effective in teaching a topic. However, it may require acquiring skills to work with the tool and efforts to build the models. When these activities are not directly relevant to accomplishing the learning objectives, they may result in inefficiency. Taking the above criteria into account, our design objectives for IPsecLite were: 1) to require (only) minimal knowledge in networking and cryptography; 2) to require no programming and unrelated setup; and 3) to function similar to the real-world IPsec solutions.
Categories and Subject Descriptors K.3.2 [Computers and Education]: Computer and Information Science Education – Computer science education. C.2.0 [Computer-Communication Networks]: General – Security.
General Terms Performance, Experimentation, Security.
In this paper, we introduce IPsecLite and we show how it may be used in teaching network security concepts. We propose three Learning Objective Groups (LOGs): 1) IPsec fundamental concepts; 2) attacks and protection mechanisms; and 3) IPsec performance and overhead analysis. Then, we propose three sample labs that use IPsecLite to accomplish the LOs.
Keywords IP security, IPsec, network security, visualization, curriculum
1. INTRODUCTION In recent years, there has been much emphasis on computer security education to meet the demands for skilled personnel in the computer security field. Our institution has been a leader in computer security education and, since year 2002, it has offered specialized security tracks for graduate and undergraduate computer science programs. The courses in tracks were designed to provide strong hands-on experience with security tools that are commonly used in industry [1, 8].
The rest of this paper is organized as follows. In Section 2, we provide an overview of IPsec, briefly introduce IPsecLite, and review the related work. In Section 3, we present the LOGs and the sample labs. In Section 4, we present the future work. And, we present our conclusion in Section 5.
2. BACKGROUND 2.1 IPsec
Developing interesting and meaningful laboratory exercises for the security courses has been one of our main challenges during the past 7 years. IPsecLite was one of the tools that we developed to address this problem. This tool is primarily used for teaching IP Security (IPsec). IPsec is a standard for securing network
IPsec is a standard for protecting IP datagrams. It is mainly described in Request For Proposals (RFCs) 4301, 4302, 4303, and 4306. IPsec provides three primary security services: 1) dataorigin authentication; 2) data-integrity verification; and 3) data confidentiality. It also supports mechanisms to protect against packet replay and (limited) Denial of Service (DoS) attacks.
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SIGCSE’10, March 10–13, 2010, Milwaukee, Wisconsin, USA. Copyright 2010 ACM 978-1-60558-885-8/10/03...$10.00.
IPsec defines two protocols to provide its security services: Authentication Header (AH) and Encapsulating Security Payload (ESP). AH mainly provides data-origin authentication and dataintegrity verification services. ESP provides data confidentiality service, in addition to providing AH services.
138
IPsecLite supports modeling of multiple network nodes on the same PC, without Virtualization Software (VS). It also supports simulation of network deficiencies, such as of packet loss, packet corruption, and out-of-sequence packet delivery.
IPsec may operate in two modes: transport and tunnel. In transport mode, IPsec protects upper layer protocol packets. In this mode, the endpoints of a connection are also the endpoints of communication. In tunnel mode, IPsec prefixes the datagram with an additional IP header. In tunnel mode, at least one connection endpoint is usually a security gateway (or router) that implements IPsec. In this mode, connection endpoints and communication endpoints are not necessarily the same.
IPsecLite supports ESP and AH in both transport and tunnel modes. Only one secure connection, between each pair of nodes, is supported. IPsecLite provides visual presentation of IPsec concepts including IKEv2 messages, SAs, and protected packets (AH and ESP). For example, a user may select an incoming (or outgoing) protected packet and observe its parts.
IPsec architecture includes a Security Policy Database (SPD). SPD maintains the rules that govern traffic protection. IPsec architecture also includes a key management part whose main function is to manage Security Associations (SAs). SAs are manifestation of secure connections. An SA contains information that is used to process the corresponding network traffic. There are two types of SAs: 1) IKE-SAs for processing the Internet Key Exchange (IKE) messages; 2) CHILD-SAs for processing data (application) traffic. SAs are unidirectional and therefore an IPsec connection is associated with four SAs (one IKE-SA and one CHILD-SA in each direction). SAs are maintained in the Security Association Database (SAD). SAs may be maintained manually, however, scalable IPsec implementations require automated mechanisms to manage SAs. IKE version 2 (IKEv2) is the default automated mechanism for SA management in IPsec. IKEv2 is a message exchange scheme. Each IKEv2 message includes one or more payloads. A payload is identified by its type. Examples are: Security Association (SA), Key Exchange (KE), and Nonce (N). To establish a shared secret, IPsec endpoints perform a DiffieHellman (DH) exchange via IKE messages. The shared secret is used by a Pseudo-Random Function (PRF) to generate several keys for cryptographic algorithms that are used to provide IPsec services. The PRF and the cryptographic algorithms are negotiated using SA payloads.
IPsecLite provides processing overhead of IPsec operations per packet or at aggregate level (averages and standard deviations). Before calculating statistics, IPsecLite detects outliers and excludes them from calculations. IPsecLite implements (minimal) IKEv2 messages that are needed for starting and ending IPsec connections. These messages and their payloads are displayed in detail. IPsecLite supports several cryptographic algorithms (Figure 3) and it uses Pre-Shared Key (PSK) method for peer authentication.
2.3 Related Work To provide hands-on experience [3] developed a laboratory environment, referred to as SEED, and a set of laboratories, which included one for IPsec design and implementation. In this lab students develop IPsec software with limited features. The lab only requires support for ESP in tunnel mode and Advanced Encryption Standard (AES) encryption so the implementation is feasible in one semester. More than one machine is needed to test the implementation. VS may be used to alleviate this requirement. Reference [7] discusses the use of OPNET simulation tool for teaching IP encryption and decryption. After a couple of introductory classes on OPNET, teams of students are asked to create Virtual Private Networks (VPNs) using IPSec. The authors conclude that there is an advantage of using OPNET versus noninteractive teaching methods. They also acknowledge that the tool is insufficient in its focus on certain aspects of IPsec. For example, “the OPNET simulation tool is insufficient to display all the details of the IPsec header/trailer-encapsulated packets.” The authors address this deficiency by using additional tools, such as a network sniffer. In OPNET tool, simulation of some IPsec concepts requires changes which require a “significant level of expertise in OPNET and a programming language like C++.”
How IPsec is configured determines its behavior, performance, and the security level it provides. For example, using ESP results in IP datagrams whose payloads are encrypted. Another example is that providing data confidentiality using Data Encryption Standard (DES) requires less computation (cost) than providing the same service using Triple-DES. The former algorithm provides better performance, but the latter algorithm provides better confidentiality.
2.2 IPsecLite IPsecLite is a tool designed for experimentation with IPsec. It enables the user to efficiently model a network with several host and gateway nodes. Once a network is modeled, IPsecLite enables the user to 1) configure the nodes for IPsec-secure communications; 2) generate traffic among the nodes and observe the inner-working of network operations; 3) simulate attacks and observe mechanisms by which IPsec provides protection; and 4) collect packet processing data (and statistics) for conducting cost (overhead)-benefit analysis. IPsecLite’s friendly and intuitive user interface enables the user to complete all of these tasks without any special training or programming.
Reference [5] has developed an Integrated Internet Simulation Framework (NIIST) that includes IPsec and IKE protocols. This framework is integrated in the Scalable Simulation Framework (SSF) and SSF Network Model (SSFNet) to provide a modeling framework for large-scale networks. SSF’s focus is scalability and high-performance in simulating protocols behavior in such networks. A Data Modeling Language (DML) is used to simulate network operations. Another tool, NIIST Player, enables the user to review the results, IPsec state, and IKE events. In NIIST actual key exchange and actual cryptographic security functionalities are not implemented.
IPsecLite is not a discrete-events simulator. In IPsecLite network communication takes place in real-time. Also, in IPsecLite key exchange and packet protection operations physically take place. For example, IP datagrams that are protected by ESP, include encrypted payloads, ESP headers, and (optionally) Message Authentication Codes (MACs).
Other general purpose network simulators, such as NeSSi [1], NS2 [4], and GTNetS [6], provide mechanisms to model a network and simulate its operations. However, they are usually designed to
139
study the behavior of protocols in large networks. Also, they require familiarity with computer simulation concepts. Some also require programming skills.
3. Teaching IPsec by Using IPsecLite
Figure 1. The network for IPsec labs
To teach IPsec we first propose three LOGs in Section 3.1. In Section 3.2 we provide three sample labs that use IPsecLite’s features to accomplish the LOGs. Each lab may be conducted by students (hands-on activity) or by teachers (IPsec demonstration).
3.1 Learning Objectives Based on the IPsec overview in Section 2.1 we propose the following LOGs.
3.1.1 Group 1: Fundamental Concepts The LOs in this LOG are to learn about 1) host and gateway nodes; 2) SPD, IKE, SAD, IKE-SAs, and CHILD-SAs; 3) IPsec protocols and their differences; and 4) transport and tunnel modes (and their applications).
Figure 2. IPsecLite Instance Configuration Tool
3.1.2 Group 2: Attacks and Protection Mechanisms The LOs in this LOG are to learn about 1) packet replay attacks and Anti-Replay Window (ARW); and 2) packet tampering attacks and MACs.
3.1.3 Group 3: Overhead Analysis The LOs in this LOG are to learn about 1) factors that affect cost of IKE operations; and 2) overhead of IPsec security services.
3.2 Using IPsecLite In this section we propose three sample labs to accomplish the LOGs in Section 3.1. Each lab corresponds to one LOG. In these labs, we use “the user” to refer to the individual who performs the activities (the teacher or the student). Also, we use a sample network that is shown in Figure 1.
Figure 3. Security Policy Database Manager
3.2.1 Lab 1: Fundamental Concepts This lab includes four activities to accomplish LOG 1. Estimated time for this lab is 45 minutes.
3.2.1.1 Hosts and Gateway Nodes In this activity the user simulates the network and generates traffic between two nodes. To do this, they use IPsecLite Instance Configuration Tool (IPLICT) (Figure 2) and Network Traffic Generator Tool (NTGT) (not shown). Step 1: The user launches an instance of IPsecLite. They use IPLICT to configure a node (for example, G1). Then, the user uses Start button to enter the main window (not shown) inside which IP Traffic Monitor (IPTM) (not shown) is displayed.
Figure 4. Security Association Database Monitor
Step 2: The user repeats Step 1 to launch three more instances (in any order) to configure nodes: G2, H1, and H2. Step 3: On H1, the user uses NTGT to send a message from H1 to H2. Then, they observe that Trace box reports the arrival of a response from H2. Step 4: To observe the routing, the user uses IPTM on G1, and verifies that the message was routed to G2. Optionally, the user may inspect the traffic on G2, and H2 to follow the message path.
Figure 5. Protected Traffic Monitor (Incoming)
140
3.2.1.2 SPD, IKE, SAD, IKE-SA and CHILD-SA In this activity the user uses Security Policy Database Manager (SPDM) (Figure 3) and Security Association Database Monitor (SADM) (Figure 4) to 1) define traffic protection rules; 2) establish an IPsec connection and observe the corresponding IKE messages; and 3) observe the resulting SAs. Step 1: The user uses SPDM to add a rule for protecting packets between H1 and H2. They enter H2’s address in Destination IP box, they select ESP from Protocol box, and they keep other parameters unchanged. Then, they click on Add button and verify that the rule is added to Security Policy Rules (SPRs) list.
Figure 6. Attack Simulator Tool
Step 2: The user selects the rule in SPR list and clicks on Connect button to start an IKE message exchange for establishing an IPsec connection. IPsecLite switches to SADM.
3.2.1.4 Transport and Tunnel Modes
Step 3: The user observes the message exchange events (right pane) and verifies that an SA Created event occurred. They also observe the IKE messages (left pane) and inspect the payloads.
Step 1: The user establishes a secure connection, using ESP, between G1 and G2. Then, they verify the connection by repeating the appropriate steps in previous activities.
Step 4: The user observes that two CHILD-SAs are created. Step 5: The user selects Security Policy Database tab to switch to SPDM and verifies that SPI column in SPRs list contains a value. This value is used to identify the corresponding IKE-SA.
Step 2: The user sends one message between H1 and H2 and monitors the datagrams carrying the message between H1-G1, G1G2, and G2-H2 links. They observe that the communication through G1-G2 link is protected by ESP.
3.2.1.3 IPsec Protocols and Their Differences
Step 3: The user explains the differences between this scenario and scenarios in activity 3 (Step 2).
In this activity the user establishes a secure tunnel between gateways G1 and G2.
In this activity the user generates traffic that is protected by the connection that was established in the previous activity. Then, they establish another connection to protect the packets with AH. In both scenarios, they use IPTM and Protected Traffic Monitor (Incoming) (PTMI) (Figure 5) to inspect the protected packets and to learn about the differences between AH and ESP.
3.2.2 Lab 2: Attacks and Protection Mechanisms This lab includes two activities to accomplish LOG 2. In both activities, the user uses Attack Simulator Tool (AST) (Figure 6) to play the role of an adversary. Using AST, the user captures a transmitted IP datagram, and retransmits it to its destination. Estimated time for this lab is 20 minutes.
Step 1: The user uses NTGT to send a message from H1 to H2 and they verify that there is a response from H2.
3.2.2.1 Packet Replays
Step 2: The user uses IPTM to verify that the message was protected. Using Network Data list, the user compares the payload of the corresponding datagram with the payload of the datagram corresponding to the message that was sent to H2 in the first activity. The user observes that the payload of the datagram is not readable and that its protocol is ESP.
In this activity no changes to the captured datagram is made. Step 1: The user establishes an IPsec connection between H1 and H2. Step 2: The user opens AST on H1 and PTMI on H2. Then, they use NTGT to send a message from H1 to H2. Step 3: AST captures the corresponding IP datagram. The user observes that ARW includes a packet whose Sequence Number (SN) is included in New Sequence Number (NSN) box. Then, they use Replay button to retransmit the datagram to H2.
Step 3: The user opens a PTMI on H2. Then, they send several messages from H1 to H2. They observe values in Protocol, Next Protocol, and Processing columns to learn about 1) the IPsec protocol that was used to protect a packet; 2) what type of packet was encapsulated in the protected packet; and 3) whether the packet was successfully processed, that is, if the packet passed the dataintegrity verification and if it was decrypted successfully. They also observe the updates to Anti-Replay Window (ARW).
Step 4: The user observes that the datagram is rejected and that its Processing status is REPLAYED. They also inspect the cost of data-protection services. Step 5: To get around this problem the user (the adversary) attempts to assign a new SN to the IPsec packet (by using NSN) and resend the datagram. However, they observe that the datagram is rejected and processing status is INVALID-MAC. Also, the user observes that the cost of data confidentiality service is zero.
Step 4: The user selects an item from the Protected Traffic (Incoming) (PTI) list and inspects the corresponding ESP packet in ESP tab above PTI list. Step 5: The user ends the connection by clicking on Disconnect button on SPDM. They also inspect the new IKE message.
3.2.2.2 Packet Tampering
Step 6: They establish an AH connection between H1 and H2.
This activity is similar to the previous activity, except that, in one experiment, the user uses IP address box to change the source address of the datagram (spoofing), and in another experiment, they use Payload box to change the content of the packet. They observe
Step 7: The user repeats Step 1 to Step 4 and observes the differences. In Step 2, they compare the ESP packets with the new packets (now protected by AH).
141
that the IP datagrams are rejected. When the datagram is spoofed, processing status is NO-SA.
4. FUTURE WORK To provide further evidence on effectiveness of using IPsecLite and to explore more ways that this tool can be used, we are currently testing IPSecLite (and the labs) in the Network Security and Applied Cryptography courses at our school.
3.2.3 Lab 3: Overhead Analysis This lab includes two activities to accomplish LOG 3. Estimated time for this lab is 45 minutes.
The users may need to change the sample labs to comply with the resources that are available to them and to support other LOs. Also, other labs may be developed, for example, labs to demonstrate more complex IPsec configurations.
3.2.3.1 Key Exchange Overhead In this activity the user learns how the selection of DH Group affects the time that is required to establish an IPsec connection. Step 1: The user establishes a secure connection between H1 and H2. To define a rule they use SPDM, select DH group 1 (768 MODP), and leave the other parameters unchanged.
5. CONCLUSION In this paper we introduced a new tool, IPsecLite, and presented an approach, which uses this tool, to teach (or study) network security concepts (primarily IPsec). We developed IPsecLite to enable effective and efficient teaching of these concepts, especially, when resources are limited. To show how IPsecLite may be used, we defined three learning objective groups and we proposed sample labs to accomplish the objectives.
Step 2: On H1, the user uses SADM to capture and log the event times of three events: INITi [processing started], INITi [processing finished], and SA established. Then, they end the connection. Step 3: For each remaining DH group, they repeat Step 1 and Step 2.
Further information on IPsecLite and (free) software licenses may be obtained by contacting the authors.
Step 4: Using the collected data, they plot a chart with two series such that X-axis represents the length of DH MODP and Y-axis represents duration. The series show the elapsed time between the first two events, which includes the DH exponentiation, and the elapsed time between the first and the last event (in Step 2), which is the time to establish the connection, respectively.
6. REFERENCE [1] Azadegan, S., Lavine, M., O’Leary, M., Wijesinha, A., and Zimand, M. 2003. An undergraduate track in computer security. In Proceedings of the 8th ACM ITICSE. (Greece, 2003).
3.2.3.2 IPSec Security Services Overhead In this activity the user compares the overhead of ESP protocol under different encryption algorithms.
[2] Bye, R., Schmidt, S., Luther, K. and Albayrak, S. 2008. Application-level simulation for network security. In Proceedings of the 1st international conference on simulation tools and techniques for communications, networks and systems & workshops. Article 33. (Marseille, France, March 03-07, 2008).
Step 1: The user establishes an ESP connection between H1 and H2 using AES-CBC-128 for data-confidentiality service (and leaving the other parameters unchanged). Step 2: The user opens the PTMI on H2 and NTGT on H1.
[3] Du, W. and Wang, R. 2008. SEED: A suite of instructional laboratories for computer security education. ACM J. Educ. Resour. Comput. 8, 1, Article 3 (March 2008), 24 pages. DOI=10.1145/1348713.1348716. http://doi.acm.org/10.1145/1348713.1348716.
Step 3: The user sets the Out of Sequence, Packet Loss, and Packet Corruption boxes to 0. Step 4: With the help of Repeat box, the user sends many (for example, 1000) messages of length 512 bytes to H2. Step 5: The user uses Recalculate button on PTMI to calculate traffic statistics. Then, they log the results in a spreadsheet.
[4] Lacage, M. and Henderson, T. R. 2006. In Proceedings from the 2006 workshop on ns-2: the IP network simulator. Article 12. (Pisa, Italy).
Step 6: They repeat Step 1 through Step 5, for two other supported encryption algorithms (DES and Triple-DES).
[5] NIST IPsec and IKE Simulation Tool. http://www.antd.nist.gov/niist.
Step 7: They use the collected statistics to plot normal curves.
[6] Riley, G. F. 2003. The Georgia Tech Network Simulator. In Proceedings of the ACM SIGCOMM 2003 Workshops. (Karlsruhe, Germany, August 25 & 27, 2003).
Figure 7 shows the result when we used a PC (with 2.13 GHz Intel dual core processor and 2MB RAM) for H2. The PC ran 64-bit Windows Vista operating system. We used MS Excel 2007 to plot the normal distributions for CPU cycles for packet decryption. This result shows that in average ESP’s overhead is least when AES is used (compare to DES and Triple-DES).
[7] Ryoo, J. and Oh, T. H. 2008. Teaching IP Encryption and Decryption Using the OPNET Modeling and Simulation Tool. In Proceedings of the 12th Colloquium for Information Systems Security Education (University of Texas, Dallas, Dallas, TX, June 2 – 4, 2008). [8] Taylor, B. and Azadegan, S., 2007. Teaching Security through Active Learning, Frontiers in Education: Computer Science and Engineering. (Las Vegas, NV, 2007).
Figure 7. ESP overhead under different encryption algorithms
142
