AN EXTENSION OF MULTI LAYER IPSEC FOR SUPPORTING DYNAMIC QOS AND SECURITY REQUIREMENTS

Transcription

1 AN EXTENSION OF MULTI LAYER IPSEC FOR SUPPORTING DYNAMIC QOS AND SECURITY REQUIREMENTS A THESIS Submitted by Arnab Kundu for the award of the degree of MASTER OF SCIENCE (ENGG.) Supercomputer Education and Research Centre Indian Institute of Science Bangalore February 2010

2 ACKNOWLEDGEMENTS I express my sincere gratitude to Professor N. Balakrishnan for his guidance and specifically, for his emphasis on systematic approach, details and rigor in the process of research. I cherish the discussions I had with him and thank him for his advice and all the support throughout my research work. I am grateful to Dr. G. Athithan for his guidance and especially, for his constant encouragement for developing a deep passion towards research and emphasis on hard work and rigorous experimentation. I thank him for his efforts in improvement of my writing skills. I would also like to thank the faculty members of the institute with whom I had fruitful interactions during my stay in the institute. I thank Mr. V. S. Mahalingam, Director CAIR, for giving me the opportunity and allowing me to use the facilities of the laboratory to carry out research. I thank the staff of the Supercomputer Education and Research Centre (SERC) and also the authorities of the Indian Institute of Science, Bangalore for their timely help. I thank my colleagues in CAIR, with special thanks to Anupam for his support and encouragement.

3 I am indebted to my parents and my wife for the care, affection and love they have showered on me and for their concern and support. - Arnab Kundu ii

4 ABSTRACT Keywords: IP Security; Intermediate QoS and security service; Multi Layer IPSec; The IPSec protocol is a standard for providing confidentiality, integrity and origin authentication for communications in Internet scenario. However, the end-to-end protection model of IPSec is in direct conflict with intermediate routers providing QoS and other performance enhancement and security related services. The problem is that these services would not be able to access relevant information from the upper layer headers that arrive fully encrypted from the source. The Multi Layer IPSec (ML- IPSec) protocol solves this problem partially by providing different levels of security to different segments of IP datagrams. For this purpose, it uses manual configuration of security parameters at all intermediate nodes. As a consequence, this approach is not suitable for Internet scenario and mobile networking environments, where the requirement of prior knowledge of the intermediate nodes involved can not be met always. The ML-IPSec also ignores the presence of IP datagrams with variable size IP and TCP headers, which may be required for the proper working of applications at the intermediate nodes. In our research, we propose an extension to the ML- IPSec protocol to address these two issues. By adding a dynamic key sharing protocol to the ML-IPSec, access to the upper layer headers is provided at the intermediate nodes on need basis. The extension also proposes to use the explicit or implicit header length field information for accommodating IP datagrams with varying header lengths. The extended ML-IPSec is implemented in the Linux kernel of IPSec processing, and experimental validation involving standard intermediate applications is carried out.

5 The outcome of the experimental validation proves that the proposed extension to ML-IPSec, the Dynamic Multi Layer IPSec, provides the functionality of on-the-fly sharing of the required upper layer information with the intermediate nodes without any major overheads on packet size and processing delay. iv

6 TABLE OF CONTENTS Acknowledgements Abstract List of Tables List of Figures Abbreviations i iii viii ix xiii 1 INTRODUCTION Network Security Services Cryptographic Techniques Network Security and IPSec Objectives of the Thesis Organization of the Thesis COMMUNICATION SECURITY PROTOCOLS Layering at the TCP/IP protocol suite Protocol layering and Communication Security Protocols Application Level Security End-System level security Subnetwork Level Security Direct-Link level security The IPSec protocol suite Security Association and Policies in IPSec Authentication Header (AH) Encapsulating Security Payload (ESP)

7 2.3.4 Mutual Authentication and key sharing Summary Problem of QoS and Network access control with IPSec QoS Processing at intermediate nodes Security services at intermediate nodes IPSec and intermediate device interoperability Replacing IPSec with a transport-layer security mechanism Tunneling one security protocol within another Using a transport-friendly ESP format Multi Layer IPSec (ML-IPSec) Summary An Extension to ML-IPSec protocol - Dynamic Multi Layer IPSec Elements of DML-IPSec DML-IPSec Zone DML-IPSec Packets Security Associations The DML-IPSec Protocol DML-IPSec Processing Key sharing Protocol Handling of variable Zone sizes Summary Design and Implementation of DML-IPSec in Linux Environment Implementation aspects of basic IPSec Implementation of Protocols User space utility Implementation of the DML-IPSec protocol vi

8 5.2.1 Implementation of Zones Implementation of security association Implementation of the datagram processing at the endpoints DML-IPSec processing at the intermediate nodes Security Databases configuration utility Key Sharing Protocol Experimental validation of the DML-IPSec protocol Test bed setup Validation with respect to intermediate services Overheads of DML-IPSec Summary SUMMARY AND CONCLUSION Contributions of the work Scope for further research Bibliography 104 vii

9 LIST OF TABLES 2.1 The four Layers of the TCP/IP Protocol Suite Applications, their use and the headers of the IP datagram accessed by them Working of different intermediate application in different zone mappings Packet Length Comparisons (Bytes) between IPSec and DML-IPSec with two zones for AH and ESP in transport and tunnel modes Packet Length Overhead (Bytes) in IPSec and DML-IPSec protocol with two zones over standard IP protocol. The numbers in square brackets denote the min and max values possible for that particular case

10 LIST OF FIGURES 2.1 Processing of a HTTP Packet by different layers (i) Format of AH Header (ii) AH protocol in transport mode(iii) AH protocol in tunnel mode IPSec in both modes of operations: (i) IPSec in tunnel mode of operation between IPSec Gateways Gateway1 and Gateway2. (ii) IPSec in transport mode of operation between clients C11 and C (i)esp Header format (ii)esp protocol in transport mode (ii)esp protocol in tunnel mode SSL Record Protocol Operation Zone and Zone map in ML-IPSec ML-IPSec Protocol Operation ML-IPSec Packet Format (i) Authentication Header (ii) Encapsulating Security Payload Different zone mappings of a HTTP Packet Zone Map DML-IPSec Packet Format (i) Authentication Header (ii) Encapsulating Security Payload Security association for DML-IPSec Outbound Processing at DML-IPSec endpoint Inbound Processing at DML-IPSec endpoint Partial Inbound DML-IPSec Processing at intermediate node Partial Outbound DML-IPSec Processing at intermediate node

11 4.9 Key Sharing Protocol Zone map and Cryptographic message format during Key Sharing Protocol Key Sharing Protocol Example SPD and SA in Linux Implementation of IPSec Illustration of interaction between user space utilities and Kernel Zone structure and Zone specific DML-IPSec ESP SA SPD and SA structures in the DML-IPSec Illustration of interaction between user space utilities and Kernel in DML-IPSec High level Interaction of DML-IPSec implementation Test bed Set up ESP packet corresponding to TCP request at the forwarding chain of firewall at IN Partially decrypted TCP packet corresponding to FTP request at the forwarding chain of firewall at IN ESP packet corresponding to Web request at the forwarding chain of firewall at IN Partially decrypted TCP packet corresponding to Web request at the forwarding chain of firewall at IN Ping Traceroute Output Wireshark output for the Ping Application on eth1 interface Layout of captured ESP Packet on eth0 interface of IN Layout of partially decrypted ESP packet on eth1 interface of IN x

12 5.16 RTT of ping obtained in different communication scenarios between GW1 and GW2. (1) Normal IP communication (2) Native IPSec ESP tunnel mode (3) ML-IPSec ESP tunnel mode without any type I zone (4) ML-IPSec ESP tunnel mode with one type I zone and one type II zone of static length (5) DML-IPSec ESP tunnel mode with one type I zone and one type II zone of variable length Comparison of RTT in presence of intermediate processing obtained in different communication scenarios between GW1 and GW2. (1) ML-IPSec ESP tunnel mode with one type I zone and one type II zone of static length (2) DML-IPSec ESP tunnel mode with one type I zone and one type II zone of variable length xi

13

14 ABBREVIATIONS IP IPSec TCP TCP/IP UDP ICMP IGMP ATM HTTP FTP IETF RFC SMIME PGP TLS MPLS ESP AH IKE PEP QoS ML-IPSec DML-IPSec OSI - Internet Protocol - Interney Protocol Secutiry - Transmission Control Protocol - Transmission Control Protocol/Internet Protocol - User Datagram Protocol - Internet Control Message Protocol - Internet Group Management Protocol - Asynchronous Transfer Mode - Hyper Text Transfer Protocol - File Transfer Protocol - Internet Engineering Task Force - Request For Comments - Secure Multipurpose Internet Mail Extensions - Pretty Good Privacy - Transport Layer Security - Multi Protocol Level Switching - Encapsulating Security Payload - Authentication Header - Internet Key Exchange - Performance Enhancement Proxy - Quality of Service - Multi layer IPSec - Dynamic Multi Layer IPSec - Open System Interface xiii

15 SA CSA SAD SPI SPD ICV IV RSA DES AES CBC ISAKMP TF-ESP EOP DH PKI - Security Association - Composite Security Association - Security Association Database - Security Parameter Index - Security Policy Database - Integrity Check Value - Initialization Vector - Rivest Shamir Adleman - Data Encryption Standard - Advanced Encryption Standard - Cipher Block Chaining - Internet Security Association and Key Management Protocol - Transport Friendly ESP - End Of Packet - Diffie Hellman - Public Key Infrastructure xiv

16 CHAPTER 1 INTRODUCTION Today governments, military, corporations, financial institutions and others exchange a great deal of confidential information using the Internet and Intranets. Protection of such confidential information, ensuring data integrity and data origin authenticity are of paramount importance. The Internet was however originally designed for research and educational purpose, not for commercial applications [1]. As such, its security relied on mutual trust and openness of the users, as well as their understanding of conduct considered appropriate on the network. As the Internet grew, the user community expanded, and the existing security framework was found inadequate for modern day applications. This was mainly due to the lack of security services in the TCP/IP (Transmission Control Protocol/ Internet Protocol) [2 5] protocol suite. The broadcast nature of the lower layer protocols, absence of authentication mechanism at the entire TCP/IP protocol suite, lack of protection to packet contents and easily predictable TCP sequence numbers of some TCP implementations are among the basic security flaws of the TCP/IP protocol suite [6 9]. In the commercial usage of Internet and TCP/IP, these problems manifest themselves in a number of ways [10] : Eavesdropping attacks on a network can result in the theft of private information such as credit card numbers and customer account numbers. Similarly, such attacks can result in the theft of services normally limited to subscribers, such as information-based products. Data modification attacks can be used to modify the contents of certain transactions e.g., changing the payee on an electronic check or changing the amount being transferred to a bank account. Spoofing 1

17 attacks can be used to enable one party to masquerade as another party. Repudiation of transactions can cause major problems with billing systems and transaction processing agreements. 1.1 NETWORK SECURITY SERVICES In due course of time, safeguards were brought about to address the security related issues due to the inherent problems of the TCP/IP protocol suite. In the computer communication context, the main security safeguards are referred to as security services [11, 12]. There are five generic security services : Authentication Service: This service provides assurance of the identity of some entity (a person or a system). In other words, when some entity claims to have a particular identity, an authentication service will provide a mechanism to validate this claim. Authentication is one of the most important security services, because all other security services depend upon it to some extent. Authentication is the means of countering the threat of masquerade which can directly lead to compromise of any of the security objectives. Access Control Service: This service protects against unauthorized use or manipulation of resource. Access control is a means of enforcing authorization. Access control directly contributes to achieving the security goals of confidentiality, integrity, availability and legitimate use. Authorization decisions govern which initiator may access which targets for which purposes and under what conditions. These decisions are reflected in an access control policy. Access requests are filtered through an access control mechanism which enforces the access control policy. Another aspect of access control is preventing sensitive information from being transmitted through environments where it might be at risk. 2

18 Confidentiality Service: This service protects against information being disclosed or revealed to unauthorized entities. Achieving a confidentiality objective ideally requires protecting against disclosure of information through any information channel. In computer communications security, there are two types of confidentiality services. A data confidentiality service makes it infeasible to deduce sensitive information from the content or size of a given data item. A traffic flow confidentiality service makes it infeasible to deduce sensitive information by observing the traffic flows. Data Integrity service: This service complements access control service and protects against data being manipulated without authorization. An important characteristics of a data integrity service is its granularity. There are three important cases of authentication service. The first one, called connection integrity service, applies to all data transmitted on a connection. The second one, called connectionless integrity service, applies to all data comprising one connectionless item. The third is a selective field integrity service, which applies only to some field of a data unit. Non-repudiation: This service protects against one party to a communication exchange later falsely denying that the exchange occurred. Non-repudiation is fundamentally different from all other security services. Its primary purpose is to protect users of communications against threats from other legitimate users; rather than from unknown attackers or eavesdroppers. One important point to note is that it does not eliminate repudiation. Rather it ensures the availability of irrefutable evidence to support the speedy resolution of any disagreement related to repudiation. A robust security solution for transaction processing should provide all the five security services. The security services are implemented using the cryptographic tech- 3

19 niques as described next. 1.2 CRYPTOGRAPHIC TECHNIQUES Cryptographic techniques, such as encryption and digital signatures, are the building blocks in the implementation of all security services [12 15]. The most basic building block is called a cryptographic system or cryptosystem. A cryptosystem defines a pair of data transformations. The first transformation is applied to an ordinary data item, known as plaintext and generates a corresponding unintelligible data item called ciphertext. The second transformation, applied to ciphertext, results in regeneration of the original plaintext. An encryption transformation uses as input both plaintext data and an independent value known as encryption key. Similarly, the decryption transformation uses a decryption key along with the ciphertext to regenerate the plaintext. The transformations are most commonly called encryption and decryption respectively. There are two basic types of cryptosystems: symmetric cryptosystems and asymmetric cryptosystems. Symmetric cryptosystems are characterized by the fact that the same key is used in encryption and decryption transformations. In contrast to symmetric cryptosystems, asymmetric cryptosystems use complementary pairs of keys for encryption and decryption transformations. One key, the private key is kept secret like the secret key in a symmetric cryptosystem. The other key, the public key, does not need to be kept secret. This two key approach can simplify key management by minimizing the number of keys that need to be managed and stored in the network. The key distribution system is also much simpler as it can use unprotected medium for the distribution of the public keys. Data integrity and/or data origin authentication for a message can be provided as follows. The originator of the message generates, using all the data bits of the message contents and a secret key, an Integrity Check Value which is transmitted along with the message. The message recipient checks that the 4

20 received message content and Integrity Check Values are consistent before accepting the message. A digital signature can be considered as a special case of a Integrity Check Value. The digital signature may need to be used to resolve a dispute between the originator and recipient of a message. Symmetric encryption based or keyed hash algorithm based approach is usually inadequate for this purpose. Asymmetric cryptosystems provide more powerful digital signatures. 1.3 NETWORK SECURITY AND IPSEC In order to provide the five fundamental security services, a number of cryptographic protocols have been proposed. While these protocols are similar in the services they provide and in the cryptographic techniques they use, they vary in the manner in which they provide the services and in their locations with respect to the rest of the TCP/IP protocol stack. The issue of where within the protocol stack to provide security is contentious. Proponents of placing security lower in the stack argue that lower-layer security solutions can be implemented transparently to end users and application developers. Proponents of higher-layer solutions argue that application-layer solutions allow application-specific security services (e.g., protecting selected fields within a protocol, or individual methods, as in HTTPS) [16]. There exist protocols at different layers of TCP/IP protocol stack to provide these security services. Application level encryption viz. PGP [17, 18] for secure mail transfer, TLS [19] based VPN for secure TCP communication, IPSec for providing IP layer security [20, 21], MPLS based security [22] at data link layer are among these security solutions. Due to scalability and wide acceptance of the IP protocol and its application independent character, the IPSec protocol has become a standard for providing Internet security. IPSec [20,23,24] provides security services at the IP layer by enabling a system to 5

21 select required security protocols, determine the cryptographic algorithms to use for the services and put in place any cryptographic keys required to provide the security services. Two protocols are used to provide the security: an authentication protocol designed by Authentication Header (AH) [23] and a combined encryption/authentication protocol designed by Encapsulating Security Protocol (ESP) [24]. The AH provides the following security services: Connectionless Integrity, Data Origin Authentication and Replay Protection. The ESP protocol provides confidentiality of data as well as of traffic flow on top of the services provided by the AH. IPSec also uses a separate protocol, called Internet Key Exchange (IKE) [25 27] for establishing cryptographic parameters. Both AH and ESP support two modes of use : transport and tunnel mode. Transport mode provides security protections for upper layer protocols, whereas tunnel mode provides protection to the entire IP packet. This is achieved by encapsulating the entire IP packet inside a new IP packet. The cryptographic keys used in the IPSec security services are shared only between the IPSec endpoints. All other intermediate nodes in a network, whether they are legitimate routers or malicious eavesdroppers can only see the IP header when encryption is provided through ESP protocol. Even in the case of AH, the payload of IP datagram cannot be tampered by any intermediate node without being detected at the IPSec endpoint. This end-to-end model of security restricts performance enhancement and security related operations of many intermediate networking and security devices as they can t access/modify the original IP header (in case of tunnel mode) and upper layer protocol headers. These intermediate devices include routers providing Quality of Service (QoS), Performance Enhancement Proxies (PEP), Application level Proxy devices, Packet filtering firewalls etc [28, 29]. The interoperability problem between IPSec and intermediate devices has been addressed in literature [30]. Using transport layer security (TLS), splitting single 6

22 IPSec tunnel into multiple tunnels, Multi layer IPSec (ML-IPSec) are a few of the proposed solutions. We observe that ML-IPSec provides better solution compared to other alternatives as it solves the interoperability issue without violating the end-toend security paradigm for the data portion, unlike the case of splitted tunnel. The ML-IPSec also provides security to the entire IP datagram as opposed to the solution like TLS or Transport Friendly ESP (TF-ESP) where some important header fields are kept out of the scope of security services. The ML-IPSec protocol [31, 32] provides a novel approach for solving these interoperability issues. The ML-IPSec protocol partitions an entire IP packet into multiple zones and provides different security to different zones of the packet. The cryptographic information of the zones spanning over the upper layer protocol headers are made available to the legitimate intermediate nodes for their processing. The cryptographic keys of the zones spanning over data portion are shared only among the ML-IPSec endpoints, thus retaining the end-to-end security of original IPSec protocol for the data portion of an IP packet. Though the ML-IPSec protocol works well in a closed environment, the requirement of sharing security parameters and the requirement of prefixed zone sizes become difficult in large scale networks and in distributed environments. The main issues of the ML-IPSec protocol in this regard are as follows: 1. Routing infrastructure has to be known prior to implementation and use, as each router that requires access to higher layer protocol data will need to be manually configured before communication can commence. In some cases this will break the inherent reliability built into the Internet and it will not function correctly over multiple routes unless the appropriate router in each separate route is known and configured in advance. While this may not be a large problem in a geo-stationary satellite environment, where the satellite link terminates at a single terrestrial gateway, it could pose problems in a mobile or distributed 7

23 environment where many base stations may be in use. 2. The requirement of manual configuration at all the intermediate nodes makes the assumption that ML-IPSec endpoints have access to and control over the intermediate routers that require partial access to the network payload. However, the ML-IPSec endpoints may not necessarily be trusted by an intermediate router providing QoS based service or an intermediate security device for manual configuration without prior arrangement. 3. Security zones are designated as static byte ranges and need to be specified before communication ever commences. As a result, the exact length of the headers need to be known prior to implementation. ML-IPSec will not function correctly if the end nodes change the use of IP or TCP options, as the offsets and lengths of the headers will change, causing the zone mapping to fail. This will also be an issue when ML-IPSec is used with multiple clients, each of which may use different TCP options depending on the capabilities and configuration of the operating systems TCP/IP stack. This makes ML-IPSec extremely inflexible, particularly when it is used in tunnel mode. 4. The zone mapping proposed in ML-IPSec is static in nature. This forces one to configure the zone mapping before the commencement of the communication. It restricts the protocol from dynamically changing the zone mapping for providing access to intermediate nodes without terminating the existing ML- IPSec communication. The ML-IPSec endpoints can off course, configure the zone mapping with maximum number of zones. This will lead to unnecessary overhead that increases with the number of zones. Again, static zone mapping could pose problems in a mobile or distributed environment, where communication paths may change. 8

24 1.4 OBJECTIVES OF THE THESIS This work aims at improving the ML-IPSec protocol for providing multilayer IPSec capabilities without the need of static configuration and for IP packets with variable size header lengths. The thesis first aims at providing dynamic configurability and cryptographic information sharing between the IPSec endpoints and intermediate devices. This will enable intermediate nodes to access required header portions of IPSec packets of an existing IPSec communication on need basis, rather than depending on the static configuration before the commencement of the communication. Another aim of the thesis is to accommodate TCP/IP packets with variable length headers. Through these enhancements, the thesis aims to address the issues of using ML-IPSec in mobile network environments. The scope of the work is limited to Internet Protocol Version 4 (IPv4). 1.5 ORGANIZATION OF THE THESIS Chapter 2 gives an overview of protocols to provide communication security at different layers of the TCP/IP protocol suite. It also describes the working of different components of the IPSec protocol suite viz. AH, ESP and IKE in detail. Chapter 3 provides a study on the interoperability issues between IPSec and intermediate devices. It also discusses about different solutions including the ML-IPSec protocol proposed in the literature to address these interoperability issues. Chapter 4 presents the extension to the ML-IPSec protocol, called Dynamic ML-IPSec (DML-IPSec), for providing multi layer IPSec capabilities with the feature of on-the-fly access to upper layer protocol headers to intermediate nodes. Chapter 5 gives the design and implementation details of DML-IPSec in Linux environment. It also provides experimental validation of the protocol. Chapter 6 summarizes the research work carried out as part of this 9

25 thesis, highlights the contributions of the work and discusses the directions for further research. 10

26 CHAPTER 2 COMMUNICATION SECURITY PROTOCOLS The TCP/IP protocol was conceived with the primary objective of communication between two remote machines. The security aspects of communication became important much later with the growth of Internet. As such, the TCP/IP protocol suite does not have provisions for the security features like confidentiality, authenticity and data integrity etc. as part of the network standard implementation. Research efforts have resulted in several communication security protocols at different layers of the TCP/IP protocol suite. In this chapter we discuss the different layers of the TCP/IP protocol suite and follow it with a discussion on the communication security protocols at these layers. 2.1 LAYERING AT THE TCP/IP PROTOCOL SUITE The TCP/IP protocol suite involves a whole family of protocols designated to perform different tasks and provide services [33]. These protocols belong to different layers of the TCP/IP protocol suite. The functionalities of the different layers are as follows: Table 2.1: The four Layers of the TCP/IP Protocol Suite Application Telnet, FTP,HTTP, etc. Transport Network Link TCP and UDP IP,ICMP,IGMP Ethernet,ATM etc. 1. Application layer: It handles the details of a particular application. The standard implementation provides support for different types of applications such 11

27 as FTP, HTTP, Telnet and VoIP [34 36]. 2. Transport layer: It provides end-to-end flow of data, for the application layer. It enables the communication between applications running in different terminals and provides port numbers to different applications. The TCP and UDP are two major transport layer protocols. 3. Internet layer: It handles the movement of packets around the network. Routing of packets takes place at this layer. It makes the communication among different networks transparent. It allows the transport layer to see a unique virtual network. The main protocol is IP, although there are other associated protocols viz. ICMP, IGMP. 4. Link layer: It manages the underlying network. This layer is network dependent. The Ethernet, ATM are typical examples in this layer. Table 2.1 shows the different protocols present at different layers of the TCP/IP protocol suite. As the scope of thesis is restricted to providing security at IP Layer, only the Internet and Transport layer are relevant to us and are discussed. In the TCP/IP protocol suite, the IP protocol operating at the network layer provides unreliable service. That is, it does its best job of moving a packet from its source to its final destination, but there is no guarantee of the successful delivery of the packet [33,37], TCP on the other hand, provides a reliable transport layer service over the unreliable service of IP. The TCP protocol achieves this by performing timeout and retransmission, in the event of the non-receipt of a packet within a stipulated time [33, 38 42]. However, the UDP which is the other important transport layer protocol offers connectionless and unreliable service. packet. Figure 2.1 depicts the processing of different layers of TCP/IP stack for a HTTP 12

28 Application Data HTTP Header HTTP Payload Application Layer TCP Layer TCP Header HTTP Header HTTP Payload IP Layer IP TCP HTTP HTTP Header Header Header Payload Link Layer Ethernet Header IP Header TCP Header HTTP Header HTTP Payload Ethernet Trailer Fig. 2.1: Processing of a HTTP Packet by different layers 2.2 PROTOCOL LAYERING AND COMMUNICATION SECURITY PRO- TOCOLS The provisions of security protocols in a layered communication architecture, like TCP/IP protocol suite, raise some important issues. Protocol layering results in encapsulation of one data item within another data item and connection is carried out inside another connection. Hence there are major decisions to be made as to the layer(s) at which data item or connection-based security should be provided. However, irrespective of the level at which the security is provided, the following basic services are essential: 1. Authentication 2. Authorization 3. Confidentiality 4. Integrity 13

29 5. Nonrepudation 6. Key management From the communication protocol perspective, we can identify four different levels where the requirements of distinct security protocols arise. These four different levels are listed below. 1. Application level: Security protocols are application dependent. 2. End-System level : Security protocols provide protection on end-to-end basis. 3. Subnetwork level: Security protocols provide protection over a subnetwork which is considered less trusted. 4. Direct-link level: Security protocols provide protection over each link separately. The placement of security protocols at these different levels depends on several factors. In the following discussion, we list the major deciding factors for the placement of security protocols. Traffic Multiplexing: The layering of the TCP/IP protocol suite provides multiplexing of several higher level services and applications through lesser number of lower layer protocols. This traffic multiplexing provides some advantage in placing security protocol at lower layers. Application dependent Protection: If the security policy is dependent on userspecific information, providing security at higher layer is necessary. Protocol Header Protection: Security protocol at any particular layer can t provide security to it s lower layer headers. Thus, in a scenario, where lower layer headers carry sensitive information, placing the security protection at the lower layer is advantageous. 14

30 Number of protection points: Placing security at a very high level (i.e., application level) requires security to be implemented for every sensitive application in the system. Placing security at the lowest layer (i.e. direct-link level) requires installation of security at every network link. Placing the security at middle layer (sub-network level) is a better choice as it requires significantly less number of installation of the security protocol. Route Knowledge: At a lower layer, more knowledge of different links and routes are available. In environments, where these information is useful for deciding on the security requirements, placing security at lower layer is important. Next, we discuss the properties of the communication security protocols at the different levels and the corresponding layer of the TCP/IP protocol suite Application Level Security The application level security provides protection to the application layer of the TCP/IP protocol suite. In many cases, the lower level alternatives provide better solutions with respect to operational cost or lower number of equipment than the application level solutions. However, there exists many scenarios where application level security is the only viable solution. One of which is the case, where the security service and the policies are application-specific either semantically or by virtue of being built into a particular application protocol. For example, the security protocol for providing secure file transfer, has to know the complete working of the file transfer protocol. Similarly, if a security protocol has to provide security to some particular fields, as in the case of electronic transaction where the PIN number has to be protected, the knowledge of the application is mandatory for the working of the security protocol. Thus the security protocol has to be implemented along with the application itself. Next is the case, where security services traverse application relays. Here, the application involves 15

31 more than two end systems, as in the case of secure mail transfer. A mail has to traverse multiple entities before reaching the final destination. The requirement is to protect only the content of the mail while providing access to protocol headers for proper delivery of the mail. There are many popular application layer security protocols. Pretty Good Privacy(PGP), SMIME for secure mail transfer, HTTPS for secure HTTP connection are among them. In all these application layer security protocols, authenticity and confidentiality of the application layer are maintained End-System level security The end-system level security protocols are required to address the scenario, where the end-systems are trusted but not the underlying network(s) and same security policy is enforced upon all communications involving a system regardless of applications. Thus security protections like confidentiality, authenticity can be applied on all traffic of the system for all applications. One point to note here is that the end-to-end communication security can be achieved by using the application level security protocol also. However, the following factors favor an end-system level solution over a comparable application level solution. The end-system level solution makes security services transparent to the applications. The end-system level solution provides better performance as it has the ability to operate on larger data units. Management of security facilities, like key management service, can be achieved on per-system basis rather than involving individual applications. The upper layer protocol headers can be protected using end-system level security. 16

32 In the TCP/IP protocol suite the end-system layer of security may be provided either in the TCP layer or in the IP layer. The most popular protocol of providing security at the TCP layer is Secure Socket Layer (SSL). The end-system layer security can be achieved by the IP layer security protocol, IPSec, also. The transport mode of the protocol provides the end-system level security at the IP layer. However, SSL has gained more popularity for providing end-system level security at the TCP layer. The IPSec protocol suite in the tunnel mode of operation, has become a standard for providing subnetwork layer security Subnetwork Level Security Subnetwork level security provides communication security across one or more specific subnetworks only, in contrast to the end-to-end security. In the following discussion, we describe the scenario, where providing subnetwork level of security is advantageous over the other levels of security. It is very common that subnetworks close to end-systems are trusted to the same level as that of the end-systems, because of their geographic proximity to the endsystems. Moreover, these sub-networks mostly comes under the same security administration of the end-systems. This enables one to provide the subnetwork level security at the boundary between trusted local subnetwork and the less trusted (external) subnetwork (i.e. at the gateway machines). In any network, the number of end-systems usually far exceeds the number of network gateways. Thus providing the subnetwork level system security at the gateway machines reduces the operational cost as well as security administration related complexities. Subnetwork level of security thus has an edge over end-system level security. In TCP/IP protocol suite, subnetwork layer security can be provided at the IP layer using the IPSec protocol in tunnel mode or at the data link layer in case of LAN. However, 17

33 because of the wide acceptance of the IP protocol, IPSec in tunnel mode has become a standard for providing gateway to gateway communication security [43] Direct-Link level security The appropriate scenarios for using direct-link level security are those with comparatively few untrusted links in an otherwise trusted network. Provision of security at this level can be transparent to all higher layer protocols. Thus the security solution is not tied to any communication architecture. (like TCP/IP or OSI or proprietary protocols). Hardware security devices can be attached to the communication device interfaces. The main advantage of this solution is speed. However, this solution is not scalable and works well only on dedicated links. Direct-link level security can be provided at the physical layer, making the security protocol transparent to all upper layer protocols. For example, encryption may be provided to the bit-streams passing through interface points. Direct-link level security may be provided at the data link layer also where the protection is provided at the frame level. This model is also useful in scenarios where all the machines are connected via dedicated links. If IP network is used instead of dedicated secure links, direct linklevel solution at the data link layer security would not suffice. 2.3 THE IPSEC PROTOCOL SUITE The IPSec provides a standard, robust and extensible mechanism to ensure security to IP and upper layer protocols. The protection takes the form of data integrity authentication, data confidentiality, anti-replay protection and limited traffic flow confidentiality. As discussed in the previous section, IPSec may provide end-system level security as well as subnetwork level security [44,45]. IPSec supports these two levels of 18

34 security by using two modes of operation, i.e., transport and tunnel modes. It provides two protocols, i.e., Authentication Header (AH) and Encapsulating Security Payload (ESP) for securing the IP datagrams. The AH provides data origin authentication, connectionless integrity and anti replay protection. The ESP provides all the security functionalities of AH along with data confidentiality and limited traffic flow confidentiality. The IPSec protocols -AH and ESP- can be used to protect either an entire IP packet or the upper layer protocols of IP payload. In transport mode, IPSec header is inserted between the IP header and the upper layer protocol header to protect the entire upper layer protocol. In tunnel mode, the entire IP datagram to be protected, is encapsulated inside a new IP packet and the IPSec header is inserted between the outer and inner IP headers. The security services that IPSec provide, require shared keys for authentication and encryption. IPSec also provides the functionalities of both manual and dynamic negotiation of security parameters through a key management protocol called IKE Security Association and Policies in IPSec Before discussing the working of the two IPSec protocols -AH and ESP- we will define some basic concepts used in IPSec protocol suite. A security Association (SA) is a relationship between two end-points of IPSec communication that describes how the entities will use security services to communicate securely. A SA consists of all the information needed to characterize and exchange secured communication. One point to note is that SA is an unidirectional relationship. Thus a pair of nodes require two separate SA to define the security relationship of their bi-directional communications. The repository of the SAs is named as Security association database (SAD). A SA includes various pieces of information that the IPSec processing routines can use to determine whether the SA can be applied to a particular 19

35 inbound or outbound IP datagram. These information, known as selectors of the SA decide the scope of any particular SA. The fields in this SA selectors typically include the following: Source and Destination IP addresses Name, either a user ID or system name Transport layer protocol Source and destination ports Each SA also contains cryptographic information for the IPSec processing routines These information include : Data for providing authentication protection: authentication algorithm, key details etc. Data for providing confidentiality protection: encryption algorithm, key, IV etc. Data for providing anti-replay protection: sequence number counter, sequence number overflow flag, anti-replay counter, anti-replay window. IPSec mode: Tunnel or Transport mode. SA lifetime: in elapsed time or number of bytes protected. The inbound processing module of IPSec uses the SA entries from SAD to protect an IP datagram. When protected IP datagrams are sent, the sender needs to indicate which SA was used to encrypt the communication, so the receiver can use the same SA to decrypt the IPSec protected IP datagram. This is mentioned using a field called Security Parameter Index (SPI) present at IPSec headers. Thus, the sole responsibility of SADB is to determine the particulars about IPSec header and cryptographic protections on the outbound IP traffic and decapsulation of the incoming IPSec packet at the inbound traffic. 20

36 Another important database in IPSec processing is the Security Policy Database (SPD). The SPD fulfills different roles for outbound and inbound processing. For outbound traffic, the SPD defines the action to be taken on the outgoing IP datagram whereas the inbound SPD determines whether the current packet can be accepted by the receiver machine or not. Each SPD rule consists of one or more selector fields as mentioned in the discussion about SA and the action corresponding to the rule. At the outbound processing, the possible actions can be any one of the following Drop the packet. Send out the packet without any protection. Apply IPSec protection: In this case, SPD contains an entry to the corresponding SA. In case of inbound processing, the IPSec routine first decapsulates the incoming IP packet using the SA entries selected by the SPI and IP address fields of the incoming IPSec packet. A record of the SAs that were used and the order in which they were applied is maintained and passed to SPD processing routine. The SPD processing routine of the inbound processing ensures that each SA that protected the packet is applied in the proper order. After successful verification, an appropriate rule is applied to the packet Authentication Header (AH) The Authentication Header (AH) of the IPSec protocol suite provides the following types of protections. Connectionless Integrity guarantees that the receiver has received the exact message sent by the sender without any tampering happening in midway. The word connectionless signifies that the protocol does not ensure the orderly delivery of the datagram as the IP protocol itself is a state-less protocol. 21

37 Data Origin Authentication ensures that the message was actually sent by the apparent originator of the message and not by another user masquerading as the original message originator. Replay Protection ensures that the same packet is not delivered multiple times and the packets delivered are not grossly out of order. This capability must be implemented at the sender; the receiver may optionally enable its use. Next Header Payload len Reserved (set to zero) Security Parameter Index(SPI) Anti replay sequence number Authentication Data (i) IP Header Outer IP header (new) AH Header AH Header Upper protocol headers and data Authenticated Fields Inner IP header (original) Authenticated Fields Upper protocol headers and data (ii) (iii) Fig. 2.2: (i) Format of AH Header (ii) AH protocol in transport mode(iii) AH protocol in tunnel mode. Figure 2.2 illustrates the AH header format. The header comprises of six fields. Five of the fields have fixed length, for a total length of three 32 bit words; the sixth field is variable length. The individual fields are as follows : Next header is a 8 bit field which indicates the payload that follows the AH [46]. Payload length field is the size of the AH header in 32 bit words minus 2. Reserved is a field for future use, currently all the bits are set to 0. SPI along with the destination address in the outer IP header is an index to SA at the receivers end. Sequence number is a monotonically increasing number that keeps track of the number of messages sent from sender to receiver using the current SA. It is used to prevent replay attacks. 22

38 Authentication data is a variable length field which contains ICV (integrity check value) of the message contents needed to authenticate the packet. The ICV is computed by hashing the contents of the message. The mandatory keyed hash algorithms for IPSec AH are HMAC-MD5 and HMAC-SHA1 [47 51]. AH protocol can provide authentication both at end-system level and as well as in subnetwork level depending on the mode of operation. AH protocol supports two modes of operations. These modes are as follows: The transport mode of AH provides end-system level security. In this mode of operation, the communication endpoints must be the IPSec endpoints. The AH header is inserted into the IP datagram by placing it immediately after the IP header (and any OPTIONs) and before the next upper layer protocol header. Figure 2.2(ii) illustrates the layout of an AH packet in transport mode. As depicted in the figure, the AH protocol provides authentication security over the entire IP datagram. The tunnel mode of AH provides subnetwork level security. In this mode of operation, a security gateway is used to provide protection for multiple hosts on a network. An additional IP header whose source address is that of the security gateway is placed at the beginning of the packet. The address of the original IP header is kept intact and it becomes part of the payload of the new IP header. The destination IP address of the outer IP header is modified to the IP address of the destination gateway machine, if the destination network is also protected by a security gateway. Figure 2.2(iii) shows the position of the AH header in an IP datagram in tunnel mode. AH follows the new IP header and precedes the original IP header. As shown in the figure, AH provides authentication protection to the entire IP datagram including the new IP header, the AH header and the original IP datagram. 23

39 Local Network Client 11 Client 12 IPSec IPSec Tunnel IPSec Gateway 1 Gateway 2 Public Network Client 21 Client 22 Local Network Client 1n (i) Client 2m Client 11 IPSec Transport mode Security Client 21 Local Network Public Router 1 Network Router 2 Local Network (ii) Fig. 2.3: IPSec in both modes of operations: (i) IPSec in tunnel mode of operation between IPSec Gateways Gateway1 and Gateway2. (ii) IPSec in transport mode of operation between clients C11 and C21. Fig 2.3 depicts the different networking scenarios where the different modes of IPSec protocols can be used for providing sub-network level and endsystem level of security Encapsulating Security Payload (ESP) The AH provides several crucial security services to an IP datagram, but it does not provide confidentiality to the IP datagram. The Encapsulating Security Payload (ESP) protocol of IPSec provides confidentiality to IP datagram along with the security protections offered by AH. The following types of protection can be provided through the use of ESP: Confidentiality guarantees that the message contents are not available in clear to possible eavesdroppers. Traffic analysis protection (Tunnel mode only) provides the assurance that an eavesdropper cannot determine the ultimate source and destination involved in communication. 24

40 The ESP header can also provide the following types of protections offered by AH: Connectionless integrity Data origin authentication Replay protection Security Parameters index(spi) Anti replay sequence number Payload Data (Sepcial unencrypted data + encrypted data) IP Header ESP Header Upper protocol headers and packet data ESP Trailer ESP auth data Padding ( bytes) Authentication Data Pad length Next Header Encrypted fields Authenticated fields (ii) (i) Outer IP Header ESP Header Inner IP Header Upper protocol headers and packet data ESP Trailer ESP auth data Encrypted fields Authenticated fields (iii) Fig. 2.4: (i)esp Header format (ii)esp protocol in transport mode (ii)esp protocol in tunnel mode. Figure 2.4(i) illustrates the ESP header format. The header compromises seven fields, two of which are optional. The individual header fields are as follows: SPI is the index into the receivers SA database. Sequence Number field is the number of messages sent from the sender to the receiver using the current SA. Payload Data field is a variable-length field that fulfills the main purpose of ESP header of providing confidentiality. If the IP header is to be provided confidentiality protection, this field contains an encrypted version of the message s contents. 25

41 Padding is an optional field with a maximum length of 255 bytes. Padding is required to ensure that the data s length is an integral multiple of the encryption algorithm. In that case, the effective length of the plaintext is the sum of the lengths of the unencrypted data, padding, the pad length field and the next header field. The mandatory encryption algorithms for IPSec ESP are DES-CBC [52] and null encryption algorithm [53 55]. The later one does not provide encryption protection. As ESP must provide at least one of authentication and encryption, null encryption algorithm should not be used along with null authentication algorithm [56]. If the message is to be authenticated, padding is required to ensure that the authentication data field begins on a 4-byte boundary. Pad length is a one byte field that represents total number of bytes of padding contained in the payload data field. Next header represents the type of header that follows the ESP header. Authentication data field is an optional field that contains the ICV, if the packet is to be provided with authentication and integrity protection. The mandatory keyed hash algorithms for IPSec AH are HMAC-MD5 and HMAC-SHA1 and the null authentication algorithm [50, 51]. The ESP header normally consists of four parts. These four parts are as follows: 1. The initial ESP header portion consists of SPI and sequence number. 2. The data consists of the original IP packet payload and the original IP header in case of tunnel mode. 3. The ESP trailer consists of padding, if any, pad length and the next header field. 26

42 4. The ESP authentication data consists of the authentication data, if any. The ESP header can also be used in either transport mode or tunnel mode similar to the AH protocol. Figure 2.4 (ii) and (iii) illustrates the placement of the different portions of ESP header in both modes Mutual Authentication and key sharing IPSec uses a separate protocol called Internet Key Sharing (IKE) for providing key sharing after mutual authentication among the peers [25 27,57]. The main goal of IKE is to negotiate an IPSec SA with a peer. That is accomplished through a two-phase protocol. Phase 1 establishes an Internet Security Association and Key Management Protocol (ISAKMP) SA which is a secure channel through which the actual IPSec SA negotiation can take place. Phase 2 negotiates a pair of one-way SAs: one for inbound and another for outbound communications. 1. IKE Phase 1:ISAKMP The establishment of the ISAKMP SA can be accomplished through the completion of one of several different phase 1 exchanges, also referred to as modes: Main Mode, Aggressive Mode and Base Mode. A phase 1 exchange has three goals. To negotiate security parameters: The initiator and the responder of Phase 1 of IKE must agree on the the values and settings of the security parameters that will govern the phase 2 communication. They also must negotiate, which authentication method would be used to authenticate the peers. To authenticate identities: The peers authenticate each others identity based on some additional information. 27

43 To establish a shared secret: Once the peers have agreed on the methods and the parameters to be used to generate phase 1 shared secret, an exchange of message transfer is used to generate the shared secret. Three authentication methods are used in IKE: preshared secret key, digital signature and public key encryption. Any one of these three methods is used in the phase 1 of the IKE to authenticate peers. Preshared secret key authentication relies on information (the preshared secret) shared between the IKE originator and responder. The other two authentication methods require each pair to posses its public-private key pair. The negotiation of security parameters is achieved by sending possible security proposals from the initiator, and the receiver acknowledges the selected proposal as counter-proposal message. In phase 1, the initiator proposes one or more alternative collection of attributes. This takes the form of a single SA payload, containing a single proposal, which in turn contains one or more transformation payloads. Each transformation payload defines the exact algorithm details. The responder selects one of the proposal and sends that proposal back to the sender. This chosen proposal becomes the basis of ISAKMP negotiation. The attributes that are open to negotiate are the following: Encryption algorithm, Hash algorithm, Authentication method, Group description type, Keyed pseudo-random function and Life duration. The above mentioned functionalities i.e. Authentication of peers and negotiation of security parameters are accomplished through the completion of one of several different phase 1 modes. 2. The phase 2 of IKE: Quick Mode Once the phase 1 negotiation is complete, an ISAKMP SA, which is a pro- 28

44 tected channel, is established between the pairs. The phase 2 exchange uses this ISAKMP SA to negotiate IPSec SA. The only phase 2 IKE exchange that has been defined so far is Quick mode. The phase 2 quick mode has the following goals: To negotiate security parameters. The initiator and the responder must agree on the values and settings of security parameters that will govern the operation of the negotiated IPSec SA. To prevent replay of phase 2 negotiations. To generate keying materials for the IPSec SA. A phase 2 Quick mode exchange consists of three messages. The first two proposals are the proposal from the initiator and counter-proposal from responder respectively, similar to phase 1 of IKE. These two exchanges negotiate the IPSec SAs policy and parameters and generate keying material in an authenticated manner that protects against a replay of a previous negotiation. The last message, from the initiator to the responder, concludes the exchange and reassures the responder that the responders proposal was received. 2.4 SUMMARY In this chapter, we have described different layers of the TCP/IP protocol suite and the functioning of the individual layers. We have also discussed about the four different levels of security protocols along with the scenarios, where these security protocols may be implemented. We then discuss about communication security protocols at different layers of he TCP/IP protocol suite. We observe that security protocols at different levels and layers of the TCP/IP protocol suite have their own advantages and disadvantages. The level at which the security is to be provided should be judiciously 29

45 decided based on these considerations. Next, we review the IPSec protocol suite. We have described the security database organization and their role towards the IPSec processing. IPSec protocols (AH and ESP) definition and processing. a brief discussion on the Internet Key Exchange protocol. We have explained the We have also presented We observe that IPSec provides several security protection to IP datagrams. However, the encapsulation of upper layer protocol headers viz., transport, application layer headers and even the original IP header in case of tunnel mode, restricts several intermediate devices from performing QoS and security related processing. In the next chapter, we discuss the interoperability issue between IPSec protocol and QoS and security related processing at intermediate devices. 30

46 CHAPTER 3 Problem of QoS and Network access control with IPSec The IPSec protocol suite has become a standard for providing security services for Internet communications. It protects the entire IP datagram, so that no intermediate network node in the public Internet can access or modify any information above the IP layer in an IPSec-protected packet. However, recent advances in Internet technology have introduced a rich new set of services and applications, like traffic engineering, TCP performance enhancements, transparent proxying and caching, all of which require intermediate network nodes to access certain parts of an IP datagram, usually the upper layer protocol information. This access is required to perform flow classification, constraint-based routing, or other customized processing. Some security devices too require access to transport and upper layer headers for providing traffic analysis and firewalling capabilities. This is in direct conflict with the IPSec mechanisms. 3.1 QOS PROCESSING AT INTERMEDIATE NODES Fundamentally, end-to-end protection model of IPSec and its strict layering principle are unsuitable for an emerging class of new networking services and applications. Unlike in the traditional Internet, intermediate routers are beginning to play more and more active roles. They often rely on some information about the IP datagram payload, such as certain upper layer protocol header fields, to make intelligent routing decisions. In other words, routers have need to participate in the processing of layers above IP. In this regard, we discuss several intermediate applications used for providing Quality of Service. 31

47 Traffic Engineering The flow information in IPv4 is encoded in both the IP header and the upperlayer protocol headers, such as TCP or UDP port numbers. Therefore, any mechanism that discriminates between flows inside the network (generally called flow classification) will need to access the upper-layer protocol headers. If this is done inside the network (as opposed to classification at end-points), it may potentially conflict with IPSec. Flow classification is essential in providing rich classes of services and quality-of-service (QoS) support. These include flowbased and class-based queuing, random early detection (RED), router-based congestion control and policing, integrated services [resource reservation protocol (RSVP)] and differentiated services [multi protocol level switching (MPLS)], etc [58 60]. Application-Layer Proxies Some Internet routers can provide application-layer services for performance gains. For example, an intermediate router can become a transparent web proxy when it snoops through the TCP and HTTP header of an IP datagram to determine the web page request, and serve it with the web page from the local cache. It is transparent to end-users but boosts the responsiveness, because the delivery paths for web request and data between the intermediate router and the web site server are eliminated. Transport-aware link layer mechanisms Internet has accommodated a very wide range of link technologies, but certain transport protocols like TCP have not achieved optimal performance, when operated over a path that includes lossy wireless links or long-delay satellite links. For example, to significantly improve the TCP performance over a wireless link, 32

48 the base station at the lossy link must be aware of the TCP state information in each passing flow, and deliberately delay or drop certain types of TCP packets. Such link-layer mechanisms for TCP performance improvement (often referred to as TCP Performance Enhancing Proxies or TCP-PEP) require intermediate nodes to access and sometimes modify the upper layer protocol headers [61 64]. 3.2 SECURITY SERVICES AT INTERMEDIATE NODES The intermediate nodes not only provide services for improving the overall performance of the communication, they also perform several security related functionalities. These includes traffic analysis, access control through firewalling etc [65]. Network engineers and administrators often need the ability to monitor and analyze traffic from a network to perform a variety of tasks like diagnosis, intrusion detections, firewalling etc. These tasks often require the ability to access upper-layer protocol headers within packets, but the advocated proliferation of IPSec encryption can prevent such analysis, or limit its granularity (for example, individual nodes or flows are inseparable in an IPSec tunnel between two gateways). The fact that such analysis is both necessary and essential means that we should find a way of accommodating its prerequisites. In case of providing firewall service for controlling network access, the firewall may require to access transport layer and application layer headers depending on the security policy. For example, for providing stateful firewall, access to TCP header is required, and application level firewalls require access to application layer protocol headers. The end-to-end security of IPSec restricts the access to the upper layer headers in these cases too. 33

49 3.3 IPSEC AND INTERMEDIATE DEVICE INTEROPERABILITY Over the last decade or more, researchers have proposed many solutions to address the issue of interoperability between IPSec and several intermediate devices required for providing QoS or Security services. In this section, we describe some of the relevant solutions Replacing IPSec with a transport-layer security mechanism This approach uses a transport-layer security mechanism as an alternative to IPSec to provide security services. The transport-layer mechanism such as secure socket layer (SSL) or transport layer security (TLS) operates above TCP payload. SSL is not a single protocol, rather two layers of protocols. The SSL Record Protocol provides security to TCP payload. Three higher layer protocols, i.e., SSL handshake protocol, SSL change cipher spec protocol and SSL alert protocol are used in the management of SSL exchanges. The SSL Record Protocol provides the following security services to the TCP payload: Confidentiality: The handshake protocols define a shared secret key that is used for encryption of TCP payload using symmetric key cryptographic algorithm. Message Identity: The handshake protocols also define a shared secret key that is used to form a keyed message authentication code of the TCP payload data. Figure 3.1 depicts the overall operation of the SSL Record Protocol. The Record protocol takes an application message, fragments the data into blocks, compresses the data, applies MAC, encrypts, adds SSL record header and transmits the resulting unit in a TCP segment. Received data are decrypted, verified, decompressed, reassembled and delivered to the application level. SSL encrypts the TCP data while leaving the TCP header in unencrypted and unauthenticated form so that intermediate nodes can make use of the TCP state in- 34

50 Application Data Fragment Compress ADD MAC Encrypt Add SSL Record Header Fig. 3.1: SSL Record Protocol Operation formation encoded in the TCP header. In fact, many Internet applications already implement security with SSL or TLS, such as most web browsers (using HTTPS protocol) and mail programs (using SIMAP and SPOP). However, letting the entire TCP header appear in clear text exposes several vulnerabilities of the TCP session to a variety of TCP protocol attacks (in particular traffic analysis), because the identity of sender and receiver are now visible without confidentiality protection. Further, SSL/TLS works only on TCP, and not on user datagram protocol (UDP), thus, the range of applications supported is smaller than with IPSec [66] Tunneling one security protocol within another Another solution for interoperability advocates for tunneling one security protocol inside another. This solution proposes to use some transport layer security protocol (for example SSL/TLS) for providing end-to-end security of the transport layer payload. The transport layer header can be protected using IPSec protocol in tunnel mode. The cryptographic parameters used in IPSec protection can be shared with the intermediate nodes for their processing keeping the cryptographic parameters used in SSL/TLS 35

51 secret between the endpoints only. However, the IPSec protocol not only encrypts the transport layer header but also the entire transport layer payload. Thus the transport layer payload gets encrypted twice. Moreover, the intermediate nodes require to decrypt/encrypt the entire IP datagram just to access the transport layer headers resulting in unnecessary overheads Using a transport-friendly ESP format The Transport-Friendly-ESP (TF-ESP) proposed by Bellovin [67] modifies the original ESP packet format to include limited TCP state information, such as flow identification and sequence numbers, in a disclosure header outside the scope of encryption (but authenticated). This approach works well for some TCP PEP mechanisms which do not require any write access on TCP header fields but fails in other cases. Further, the unencrypted TCP state information is made available universally, even to untrustworthy nodes, which creates vulnerabilities for possible attacks. In addition, TF-ESP is not flexible enough to support all upper-layer protocols Multi Layer IPSec (ML-IPSec) The ML-IPSec [30,32] uses a multilayer protection model in place of a single end-to-end model. Unlike IPSec where the scope of encryption and authentication applies to the entire IP datagram, this scheme divides the IP datagram into zones. It applies different protection schemes to different zones. Each zone has a set of security associations, a set of private keys that are not shared with other zones, and a set of access control rules defining which nodes in the network path have access to the zone. A zone is any portion of an IP datagram under the same security protection scheme. The granularity of a zone is one octet. The entire IP datagram is partitioned into non-overlapping zones, except for the IP header in the transport mode. A zone 36

52 IP Datagram Zone 1 (2 Sub Zones) Zone 2 (2 Sub Zones) Zone 3 ( Sub Zone) Fig. 3.2: Zone and Zone map in ML-IPSec need not be a contiguous block in an IP datagram, but each contiguous block is called a sub-zone. A zone map is a mapping relationship from octets of the IP datagram to the associated zones for each octet. There are some important points to note about the zone definition of ML-IPSec. The ML-IPSec zone map is static for the entire lifespan of the ML-IPSec communication. It can not be reorganized to provide service to some new intermediate node. The ML-IPSec zones are specified on physical byte level. Thus the accommodation of TCP/IP datagrams with variable size OPTION field is not possible. Figure 3.2 depicts a sample zone map of an IP datagram with three zones. The ML-IPSec redefines the concept of security association of standard IPSec protocol as the intermediate nodes participate in defining the security parameters for different zones. It uses a single SA for each of the zones and finally a composite SA (CSA) is derived for the protection of any IP datagram. The protocol uses manual mechanism for establishing these SAs before the commencement of DML-IPSec communication. Another import point to note is that these SAs remain constant for the entire lifespan of the communication. When ML-IPSec protects a traffic stream from its source to its destination, it first partitions the IP datagram into zones and applies zone-specific cryptographic 37

53 Sender any node TCP PEP node any node Recevier IP Hdr ESP Hdr IP Hdr ESP Hdr IP Hdr ESP Hdr IP Hdr Zone1 IP Hdr Zone1 IP Hdr TCP Hdr TCP Hdr TCP Hdr TCP data Zone2 Zone2 Zone2 TCP data Fig. 3.3: ML-IPSec Protocol Operation protections. When the ML-IPSec protected datagram flows through an authorized intermediate gateway, a certain zone of the datagram may be decrypted and/or modified and re-encrypted, but the other zones will not be compromised. When the datagram reaches its destination, the ML-IPSec will be able to reconstruct the entire datagram. Fig 3.3 depicts the operation of ML-IPSec protocol. The IP datagram is protected in tunnel mode of operation. The original IP header and TCP header constitutes the first zone and the cryptographic information for this zone is shared between the ML-IPSec endpoints and intermediate nodes, TCP PEP agents here. The other zone is spanned over TCP payload and secured in end-to-end manner between ML-IPSec endpoints. The same security protocols, AH and ESP, are used in ML-IPSec with relevant changes to support multiple zones. Both AH and ESP support transport mode and tunnel mode of operation. In case of AH, the authentication header is further divided to contain zone specific authentication information. In case of ESP, the payload portion is divided into zones. Each zone is encrypted separately after padding (if required). Finally the authentication trailers of all the zones are appended after the last encrypted zone. Figure 3.4 describes the format for both the headers for a case in which the ML- IPSec protocol involves three zones. 38

54 Nxt Hdr Payload Len Reservered Security Parameter Index (SPI) Sequence Number Authentication Data for zone 1 Authentication Data for zone 2 Authentication Data zone 3 (i) Security Parameter Index (SPI) Sequence Number Encrypted Payload for zone 1 (Variable length) Pad Pad Length Next Header Encrypted Payload for zone 2 (Variable length) Pad Pad Length Encrypted Payload for zone 3 (Variable length) Pad Pad Length Authentication Trailer for zone 1 Authentication Trailer for zone 2 Authentication Trailer for zone 3 Fig. 3.4: ML-IPSec Packet Format (i) Authentication Header (ii) Encapsulating Security Payload The ML-IPSec protocol works well in a closed environment; however the protocol suffers from the following deficiencies [68]: (ii) The ML-IPSec requires complete knowledge about all intermediate routers before the commencement of the communication. This can pose problems in Internet scenarios and also in mobile networking environments. All the intermediate routers need to be manually configured for ML-IPSec zones and cryptographic information. This requirement causes scalability problems for the deployment of the ML-IPSec solution. Security zones are designated as static byte ranges and need to be specified before communication commences. As a result, the exact length of the headers need to be known prior to implementation. The ML-IPSec will not function correctly if the end nodes change IP or TCP option fields. The static zone mapping of ML-IPSec forces one to configure the zone mapping before the commencement of the communication. It restricts the protocol from 39

55 dynamically changing the zone mapping for providing access to new intermediate nodes without terminating the existing ML-IPSec communication. 3.4 SUMMARY In this chapter we have discussed the interoperability issues between several intermediate nodes and IPSec protocols. We also described the possible solutions proposed in the literature to address the issues. We observe that the ML-IPSec protocol provides a novel solution of providing multi layer security to an IP datagram. This approach solves the issue of the access to the upper layer headers to intermediate nodes. However, the manual key sharing mechanism and static zone mapping of the protocol gives rise to some important issues with respect to scalability of the solution. In the next chapter, we describe our extension to the ML-IPSec protocol, called DML-IPSec to address all these issues. 40

56 CHAPTER 4 An Extension to ML-IPSec protocol - Dynamic Multi Layer IPSec The IPSec protocol was designed for providing security for communications over the IP layer primarily between two end-points. Over time, the protocol had to address the issue of giving access to upper layer protocol headers at intermediate nodes while protecting the communication between end-points. The ML-IPSec protocol was proposed for resolving this issue. However, the current version of ML-IPSec protocol fails to address the requirement of dynamic key sharing between the intermediate and source nodes. It is also not designed to support variable zone sizes. A partial solution to cater to variable zone sizes has been proposed in [68]. However, this solution may not give access to application layer headers of any generic application in intermediate nodes. Additionally, it may sometimes lead to suboptimal zone partitioning resulting in unnecessary overheads both in forms of packet size and processing delay. Also the discussion lacks implementation details and performance related issues. Our extension to the ML-IPSec protocol, called Dynamic Multi Layer IPSec (DML- IPSec) aims to solve these issues. The DML-IPSec tries to achieve this by re-defining some of the IPSec fundamentals such as the packet structure, security association etc. It also redefines the ML-IPSec zones and zone mapping. A new key sharing protocol enables dynamical sharing of cryptographic information between the source and intermediate nodes. Finally a solution to the variable zone size issue of ML-IPSec protocol is implemented through on-the-fly derivation of the zone lengths. This chapter is organized as follows. Section 4.1 presents the basic definitions 41

57 and terminologies in the context of the DML-IPSec protocol. Section 4.2 presents the details of DML-IPSec protocol. 4.1 ELEMENTS OF DML-IPSEC DML-IPSec Zone In ML-IPSec protocol, an IP packet is partitioned into non-overlapping segments called zones. A zone need not be contiguous, in which case, all contiguous portions of a zone form a subzone of that zone. Each zone is given a cryptographic protection that is independent of the other zones by using a separate set of cryptographic parameters. A zone map is a mapping relationship from octets of the IP datagram to the corresponding zones. The zone map defines the zone boundaries for all the zones and these boundaries remain constant throughout the lifespan of the ML-IPSec Security Associations (SAs). For each zone, all octets of all subzones are concatenated (in the order they appear in a datagram) and then encapsulated into the ML-IPSec Payload Data field. During in-bound processing, original IP datagrams are reconstructed from the decrypted zones using the zone mapping. It can be observed that though the zones themselves may not be contiguous, however the position of the different protocol headers are non-overlapping and contiguous inside an IP datagram. This observation justifies the zones to occupy contiguous segments in an IP datagram in our definition of DML-IPSec protocol. Thus, in the DML-IPSec protocol, zone is defined as a set of non-overlapping and contiguous partitions of an IP packet. This is in contrast to the case of ML-IPSec, where a zone may consists of many contiguous portions called subzones. All the zones are provided with cryptographic protection independent of other zones. We also propose to classify zones into two separate types depending on the accessibility requirements at the intermediate nodes. The first type of zone, called type 42

58 I zone, is defined on headers of IP datagram and is required for examination and modification by intermediate nodes. Thus, we can define different type I zones for IP, transport, application layer headers or in suitable combinations of these headers. The second type of zone, called type II zone, is meant for the payload portion and is kept secure between the endpoints of IPSec communications. The single type II zone starts immediately after the last type I zone and spans till the end of the IP datagram. So, the scope of the single type II zone depends on that of the last type I zone. In our approach, an IP datagram is partitioned into several type I zones followed by a final type II zone. Fig. 4.1 shows the case of an HTTP packet in ESP tunnel mode. We may define three type I zones, one each for inner IP header, TCP header, and HTTP header respectively and the type II zone is defined on the HTTP payload. Alternatively, we may define only a single type I zone consisting of inner IP header and TCP header and in this case the whole TCP payload (including HTTP header and HTTP payload ) forms the single type II zone. However, this partitioning depends on the level of access required by the intermediate nodes. For example, if no intermediate processing is required during the entire DML-IPSec session, the single type II zone may cover the entire portion of the datagram secured by DML-IPSec. In that case no type I zone exists in the IP datagram and this scenario resembles the case of a normal IPSec packet. This new definition of a zone not only facilitates all granularities of access to the protocol headers by the intermediate nodes, but also enable us to define logical zone boundaries in contrary to byte level physical zone boundary of the ML-IPSec. As discussed earlier, a zone consists of headers or payload, the boundaries of which may vary depending on the context. Hence the flexibility obtained in the definition of logical zone boundaries can be used for resolving the issue of accommodating IP packets with variable length headers. 43

59 IP HDR ESP HDR IP HDR Type I Zone 1 TCP HDR HTTP HDR HTTP Payload Type I Type I Type II Zone 2 Zone 3 Zone 1 (i) IP HDR TCP HDR HTTP HDR HTTP Payload (ii) IP HDR ESP HDR IP TCP HDR HDR Type I Zone 1 HTTP HTTP HDR Payload Type II Zone 1 (iii) Fig. 4.1: Different zone mappings of a HTTP Packet The DML-IPSec protocol also defines zone map as the mapping from the octets of the IP datagram to different zones of the DML-IPSec protocol. However, unlike the case of ML-IPSec, zone map of DML-IPSec does not specify any zone boundary. Unique integer numbers are used to represent the scope of each zone. In case of zones spanning over multiple protocol headers, the integer values for the corresponding zones are concatenated to represent the scope of the zone. All the zone sizes can dynamically vary according to the concerned IP datagram. As per our definition of type I zones, it is the combination of protocol headers. If any of these protocol headers have variable size (as in case of IP and TCP headers with OPTION fields), the corresponding type I zone size varies. The length of the single type II zone depends on that of the last type I zone. Moreover, the payload portion of any protocol may vary depending on application requirement. So, the length of the single type II zone also varies. The DML- IPSec protocol derives the zone lengths dynamically from the header length fields of the protocol headers. This feature of DML-IPSec zones is important for addressing the issue of variable header lengths. Another important feature of DML-IPSec zone is that the zone maps need not necessarily be constant throughout the lifespan of the DML-IPSec security association. The key sharing protocol may modify any existing 44

60 zone map for providing service to some intermediate nodes. One important feature of the zone mapping of the DML-IPSec is the ability of dynamic reorganization of the type I zones without the need of renegotiation of the cryptographic parameters for the type II zone. In other words, two DML-IPSec endpoints may configure only one type II zone without any type I zone to start the initial communication. If some intermediate node requests the access to some upper layer header, the zone maps are reorganized and the SAs for the type I zones are decided. The current cryptographic parameters used for the sole type II zone are used for the new type II zone after the reorganization of zones. If any other reorganization of the zones is required, at some later time, the current cryptographic information for the type II zone is used for the type II zone constructed after the reorganization of zones. This flexibility enables one to start a DML-IPSec session with single type II zone and update the zone information on need basis. In this way, the overhead due to unnecessary partitioning of an IP packet into zones is avoided. No_of_Zones 4 Zone 1 Type I Scope 1 Zone 2 Type I Scope 2 Zone 3 Type I Scope 3 Zone 4 Type II Scope 3 EOP No_of_Zones 2 Zone 1 Type I Scope 12 Zone 2 Type II Scope 2 EOP (ii) (i) Fig. 4.2: Zone Map Fig 4.2 depicts the entries of the zone map for the case described in fig 4.1. The zone map depicted in the fig 4.2(i) corresponds to the HTTP header packet with 3 type I zones and single type II zone as shown in fig 4.1(i). The scope of the first zone 45

61 is restricted to the inner IP header and hence represented as Scope 1. The scope field of zone 2 is specified as Scope 2 indicating that the scope of the zone is over the next header which is the TCP header. The scope of 3rd zone is represented as Scope 3 to specify the scope over the third header which is the application header. The scope of the sole type II zone begins after the application layer header and spans till the End-Of-Packet. It is represented as Scope 3-EOP. The zone map depicted as fig 4.2(ii) represents the zone map for the HTTP packet with two zones shown in the fig 4.1(iii). The single type I zone is defined over the inner IP header and transport layer header and represented as Scope 12 in the zone map. The sole zone II spans over the transport layer payload and its scope is represented as Scope 2-EOP in the figure DML-IPSec Packets The DML-IPSec supports the AH and ESP protocols of the conventional IPSec with some modifications. In case of AH, the authentication header is almost similar to IPSec. The only difference is that the authentication data for the whole packet is further divided into zone specific authentication data. The packet format of the AH is exactly similar to that of ML-IPSec. The DML-IPSec ESP payload is partitioned into zone specific segments. The data for each zone, together with padding, padding length, and next header field (applicable for the single type II zone only), are collectively referred to as the cipher text block for that zone. The size of each cipher text block can be determined by the algorithm definition. Each zone may have a separate authentication trailer. The size of the authentication trailer depends on the algorithm used for that particular zone. In DML-IPSec ESP, the authentication trailer of each zone (if present) is appended immediately after the corresponding encrypted zone data, in contrary to ML-IPSec, 46

62 where all the authentication trailers are appended together after the encrypted data of the last zone. Nxt Hdr Payload Len Reserved Security Parameter Index (SPI) Sequence Number Authentication Data for Type I zone 1 Authentication Data for Type I zone 2 Authentication Data for Type II zone (i) Security Parameter Index (SPI) Sequence Number Type I Zone 1 Pay Load (Variable length) Pad Authentication Trailer Pad Type II Zone Pay Load (Variable length) Pad Length Type I Zone 2 Pay Load (Variable length) Authentication Trailer Pad Length Pad Pad Length Next Header Authentication Trailer (ii) Fig. 4.3: DML-IPSec Packet Format (i) Authentication Header (ii) Encapsulating Security Payload Fig 4.3 depicts the layout of the AH and the ESP headers according to the DML- IPSec definition with two type I zones and one type II zone Security Associations The concept of security association (SA) is fundamental to IPSec. An SA is a relationship between two end-points of IPSec communication that describes how the entities will use security services to communicate securely. However in DML-IPSec, several intermediate nodes may participate in defining these security protections to the IP datagram. Moreover, the scope of one particular set of security protection is valid on single zone. So we define a single SA for each zone of an IP datagram. We finally combine all these individual zonal SAs to represent the security relationship of the entire IP datagram. This combined security relationship consists of one zone map and a set of zone lists. The zone map contains the common information for all zones along with the logical zone definitions, whereas the individual zone list consists of security information related to that particular zone only. For example, fields like sequence 47

63 number counter, anti-replay window, DML-IPSec protocol mode are of common interest to all the zones and are present in the zone map. The zone specific cryptographic information like encryption algorithm, encryption key, authentication algorithm and authentication key are present at corresponding zone specific lists. The DML-IPSec endpoints have the complete knowledge of the entire zone map as well as that of all zone specific lists. The intermediate nodes have the knowledge of the relevant type I zone specific information. The cryptographic information related to the type II zone is kept hidden from any intermediate node. The key sharing protocol is responsible for sharing this partial zone information with the intermediate nodes. The two endpoints of a DML-IPSec communication may re-negotiate the SA definition for providing some service to the intermediate node having the capability of partial DML-IPSec processing. No_of_Zones 3 No_of_Zones 2 Zone 1 Type I Zone 1 Type I Scope 1 Scope 1 Zone 2 Type I Zone 2 Type I Scope 2 Scope 2 Zone 3 Type II Scope 2 EOP Anti replay Window Sequence Number Mode : Tunnel SPI Value Anti replay Window Sequence Number Mode : Tunnel SPI Value Zone 1 Enc Alg0 : DES Key : K1 Auth Alg0 : A1 Key : K2 Zone 2 Enc Alg0 : DES Key : K3 Auth Alg0 : A1 Key : K4 Zone 3 Enc Alg0 : DES Key : K5 Auth Alg0 : A1 Key : K6 Zone 1 Enc Alg0 : DES Key : K1 Auth Alg0 : A1 Key : K2 Zone 2 Enc Alg0 : DES Key : K3 Auth Alg0 : A1 Key : K4 DML IPSec End Points DML IPSec Intermediate node Fig. 4.4: Security association for DML-IPSec Fig 4.4 depicts the security association both in DML-IPSec end points and intermediate nodes. This scenario corresponds to the case of ESP tunnel mode with two 48

64 type I zones, where the first type I zone spans the inner IP header and the second type I zone on transport layer header. The single type II zone spans the transport layer payload. As depicted in the Fig 4.4, the end-points of the DML-IPSec communication have the complete knowledge of the zone maps as well as the zone lists for all the zones, whereas the intermediate node has information only about the two type I zones. 4.2 THE DML-IPSEC PROTOCOL The DML-IPSec protocol has two basic components. The first one is for the processing of packets at the endpoints as well as several intermediate nodes. The second component is a protocol for sharing of cryptographic parameters to the intermediate nodes. In this section we first describe the DML-IPSec processing followed by the Key Sharing Protocol. Finally we discuss the handling of variable sized zones DML-IPSec Processing The DML-IPSec processing is different for the endpoints and intermediate nodes. The endpoints of a DML-IPSec communication involve two types of processing. The first one, called Outbound processing, is responsible for generating DML-IPSec packets from an IP datagram according to the security policy and security association. The Inbound processing is responsible for generating the original IP datagram from a DML- IPSec packet using the security policies and security associations. Outbound Processing When the source node sends out an IP datagram, the following steps take place. Derivation of Zones The very first operation at the outbound processing is the derivation of the zones and zone lengths. The number of zones and scope of each zone is derived 49

65 from the information of the zone map. This zone map and zone specific SA databases are populated either by the initial configuration of a DML-IPSec communication or by the key sharing protocol. The length of each zone may vary from IP datagram to IP datagram. In case of type I zones, the header length field of the protocol headers are used to determine the length of each zone; otherwise the implicit length definition is used to derive the zone lengths. The zone boundary of the type II zone is derived from the total length of the IP datagram and the cumulative lengths of all type I zones. Zone Specific Encryption The next step involves encryption of the relevant data in each zone. At the beginning of the encryption module, the sender adds any necessary padding to each zone s Payload Data field, to meet the encryption algorithm s block size requirement, if any, and to align it on a 4-byte boundary according to the DML- IPSec ESP format. The sender then encrypts the resulting plaintext (payload data, padding, pad length, and next header in case of single type II zone) using the key, the encryption algorithm, and the encryption mode indicated by the zonal SA and cryptographic synchronization data, if any. Zone Specific Authentication Calculation After the zone specific encryption, the sender calculates the authentication values for the zones (if required) and appends the same after the encrypted data of the corresponding zone. The cryptographic information required for the calculation is derived from the corresponding SA entry. Fig 4.5 depicts the outbound processing of an IP datagram with two type I zones followed by a type II zone for ESP protocol. As explained in the above discussion, the zone map is used to derive the zone length followed by zone wise 50

66 IP Datagram Zone Map Zone 1 Zone 2 Type II Zone Encrypt Encrypt Encrypt SA 1 Authentication Authentication SA 2 Authentication SA 3 IP HDR ESP HDR Fig. 4.5: Outbound Processing at DML-IPSec endpoint encryption. Finally the zone specific ICV s are computed on encrypted zone data. Inbound Processing On inbound processing, the receiver performs the following steps on an IP datagram. Derivation of Zone Boundary The derivation of zone boundaries is significantly different from that of outbound processing. The main difference here is that the length fields of zones remain encrypted. After receiving a DML-IPSec datagram, the receiver processes the datagram according to the zone map. The receiver starts decrypting type I zones till it decrypts the header length field of the header. In case of a type I zone spanning over multiple protocol headers, partial decryption is used till the length of all the protocol headers is derived. The length of the single type II zone is derived using the total length of the IP datagram and other type I zone lengths. The partial decryption of the type I zones are done on temporary buffers, as the encrypted data would be required in authentication verification 51

67 step of the inbound processing that follows the present step of zone boundary derivation. Authentication verification The authentication verification in DML-IPSec is zone specific. The cryptographic information regarding authentication calculation algorithm are fetched from SAs corresponding to zones. The authentication values are calculated in the same way as that of the outbound processing, and the values are then matched against the authentication values stored in the authentication field of each zone. If the match is perfect for all values, the authentication verification succeeds and the datagram is processed by next step, else the datagram is dropped. Zone Specific Decryption The final step of the inbound processing is the zone specific decryption of the IP datagram. This is almost opposite to that of zone specific encryption at the outbound processing. The zone specific decryption details are fetched from corresponding SAs. After the decryption of all the zones, the original IP datagram is re-constructed by trimming fields like pad, IV (if present) etc. The initial portions of the type I zones which are used for partial decryption for the derivation of zone boundaries are not decrypted again in this step. Rather the decrypted values from the temporary buffer position are copied and only the necessary portions of type I zones are decrypted. Fig 4.6 depicts the inbound processing of an DML-IPSec ESP packet with two type I zones followed by a type II zone. As depicted in the figure the inbound processing consists of derivation of zone boundaries using partial decryption followed by authentication verification and zone specific decryption to reconstruct 52

68 IP Datagram Decryption Decryption Decryption Authentication Verificattion Authentication Verificattion Authentication Verificattion Derivation of zone lengths Partial Decryption Partial Decryption SA 1 SA 2 SA 3 Zone Map IP HDR ESP HDR Fig. 4.6: Inbound Processing at DML-IPSec endpoint the original IP datagram. Partial Datagram Processing at Intermediate nodes The intermediate nodes process an incoming IP datagram depending on the presence of the security parameters for that particular DML-IPSec communication. In the absence of the security parameters, the IP datagrams are forwarded to the destination and at the same time the key sharing protocol gets executed. After successful execution of the key sharing protocol, all the incoming IP datagrams get partially decrypted according to the security association and zone mapping at the inbound processing module. After the inbound processing, the partially decrypted IP datagram traverses through the networking stack of the intermediate node. Before the datagram leaves the intermediate node, it is processed by the outbound module to reconstruct the DML-IPSec packet. Inbound Processing at Intermediate nodes The inbound processing module is almost similar to that of DML-IPSec endpoints. The zone boundaries of the relevant type I zones are first calculated 53

69 followed by ICV verification and decryption of the necessary type I zones. On execution of these steps the inbound module gets partially decrypted data for customized intermediate processing. The inbound module constructs a legitimate IP datagram using this partially decrypted datagram so that it can traverse TCP/IP stack of the intermediate node. This requires modification and updation of relevant fields of the newly constructed IP datagram viz., total length, checksum etc. Another point to note is that the DML-IPSec header and zone specific IV, if any, after the processing is not discarded; rather the inbound processing module appends the header after the legitimate IP payload and recomputes the length fields accordingly. IP Datagram Decryption Decryption Authentication Verificattion Authentication Verificattion Derivation of zone lengths Partial Decryption Partial Decryption SA 1 SA 2 Zone Map IP HDR ESP HDR Fig. 4.7: Partial Inbound DML-IPSec Processing at intermediate node Fig 4.7 depicts the partial inbound processing of a DML-IPSec ESP packet with two type I zones and one type II zone. Both the type I zones are decrypted to form the upper layer headers of the intermediate IP datagram, whereas the whole type II zone gets copied to the payload portion of the intermediate IP datagram as it is. 54

70 Outbound Processing at Intermediate nodes The outbound processing module is similar to that of DML-IPSec endpoints. Here the zone specific SAs are derived using the header fields and saved data of the partially decrypted datagram to regenerate the type I zones. Finally the type II zone is concatenated to reconstruct the DML-IPSec packet. IP Datagram Master Zone Map Zone 1 Zone 2 Encrypt Encrypt SA 1 Authentication Authentication SA 2 IP HDR ESP HDR Fig. node 4.8: Partial Outbound DML-IPSec Processing at intermediate Fig 4.8 depicts the partial outbound processing of a DML-IPSec ESP packet with two type I zones and one type II zone. Both of the type I zones are constructed from the upper layer headers of the intermediate IP datagram and the type II zone is constructed from the payload portion of the partially decrypted IP datagram Key sharing Protocol The key sharing protocol is responsible for dynamically providing all cryptographic information to intermediate nodes. When an intermediate node fails to process a DML-IPSec packet due to the absence of required security parameters, the key sharing protocol is invoked between the source of DML-IPSec packet and the intermediate node. At the end of successful execution of the protocol, the relevant security asso- 55

71 ciations are made available to the intermediate node. Whenever the current security parameters are changed or get expired, the corresponding action is being taken at the intermediate node also. The realization of these functionalities require the notification of the events and exchange of data using appropriate messages. We propose to use ICMP messages for all the communications required for the execution of the key sharing protocol. In the following section, we explain the working of the protocol in detail. Source Node ESP Packet Intermediate Node Forward (2) Destination Node Invocation (1) New Zone Map (3) Phase I Zone map ack (4) Auth Challenge (5) Phase II Auth Response (6) Phase III Shared Secret (7) Shared Secret Ack (8) Phase IV Zone & crypo info (9) Zone & crypo info Ack (10) ESP Packet (11) Intermediate Processing and Forward Fig. 4.9: Key Sharing Protocol Invocation of the protocol Whenever a DML-IPSec packet traverses through an intermediate node, that requires access to some of type I zones, the inbound security database is searched. If no entry is present in the database, the key sharing protocol is invoked. As 56

72 the first step of the protocol, a header inaccessible message is sent from the intermediate node to the source of the DML-IPSec packet (mentioned as 1 in fig 4.9). The intermediate node also mentions the protocol headers that it requires to access the body portion of this message. Unique integer codes are used for identifying different protocol headers according to the same format as described in the zone map related discussion of the previous section. Upon receiving this header inaccessible message, the source of the DML-IPSec communication commences the first phase of the protocol to decide whether the service to the intermediate node can be provided or not. Zone reorganization phase This first phase of the protocol is responsible for deciding the zone mapping to provide access to intermediate nodes. This phase performs the following steps. First, the source of the DML-IPSec communication decides whether the access to the requested protocol headers can be granted using the existing zone mapping of the DML-IPSec communication. If the present zone map can serve the requested access, the next phase of the protocol commences. Otherwise the subsequent steps of this current phase continue to reorganize the zone mapping. Next, the source of DML-IPSec communication decides the new zone mapping required for the requested access. If the requested access is possible according to a new zone map, the new zone map is sent to the destination of the DML-IPSec connection by the source (indicated as 3 and 4 in fig 4.9). Otherwise an error message is sent to the intermediate node and key sharing fails. After receiving this message the intermediate node may decide to request for access to a new set of headers. After this renegotiation message transfer, both the source and destination update the security association and zone mapping databases. It may also be required to update the zone map and security associations of other 57

73 existing intermediate nodes. In that case these intermediate nodes update their security databases. The cryptographic information for the new type II zone is derived from the existing security association for the type II zone. Only the new type I zone maps and cryptographic information regarding the new type I zones are communicated in this step. This ensures that the default security parameters, derived from the manual or automatic key exchange procedure are kept constant for the type II zone. Because of this particular zone re-negotiation phase, the end nodes of the DML-IPSec communication may start with initial configuration of only one zone (same as normal IPSec). Whenever a request, if any, from some intermediate node comes, the zone maps are reorganized through renegotiation. We explain the zone reorganization phase with an example. Suppose, two endpoints of a DML-IPSec session commence the communication with a single type II zone spanning over entire IP datagram using ESP in tunnel mode. The zone map and the security databases also are configured with entry for a single type II zone having scope over the entire datagram (indicated as 0-EOP in the zone map ). If some intermediate node requires access to the inner IP and transport layer header, it sends a header inaccessible message to the source node indicating the header requirement as Scope 12 to request access of the inner IP and transport layer header. Upon receiving this message, the source node checks the zone map to find out that the access is not possible according to the current zone map and decides to execute the zone reorganization. The source node reorganizes the zone map with one type I zone spanning over inner IP and transport layer header and a type II zone over transport layer payload. The cryptographic parameters used for the previous type II zone are used for the new type II zone. The source node also decides the cryptographic parameters 58

74 for the sole type I zone. After this zone reorganization, the new zone map and the cryptographic information for the sole type I zone are sent to the destination node. Upon receiving this zone reorganization message, the destination node also updates its zone map and the security databases and acknowledges to the source node. Authentication Phase This phase of the key sharing protocol commences, if the service requested by the intermediate node can be granted by the source of the DML-IPSec communication. The main responsibility of this phase is to verify the identity of the intermediate node to the source of DML-IPSec session. If required the DML-IPSec source may provide the authentication of itself to the intermediate node. We propose the usage of a simple challenge-response type protocol for the purpose of authentication. The protocol uses public key cryptography for implementing the authentication process. All the concerned nodes, DML-IPSec endpoints and intermediate nodes, are to be provided with the public keys of all others. In the first step, the source of DML-IPSec session may select some random number R, encrypt it using the public key of the concerned intermediate node and send it to the intermediate node (indicated as 5 in fig 4.9). Upon receiving this authentication request, the intermediate node decrypts R using it s private key and encrypts the same with the public key of the source node. This simple challenge-response protocol can prove identity of the intermediate node to the source node (indicated as 6 in fig 4.9). Similar challenge response protocol may be used to prove identity of source node to the intermediate node. If the identity of the intermediate node is proved to the source node, the latter signals the commencement of the next phase, else an appropriate error message is sent to the intermediate node and the key sharing fails. 59

75 Shared secret establishment phase This phase is responsible for the establishment of a temporary shared secret between the source and intermediate nodes. This shared secret is to be used as key for encrypting the actual message transfer of the DML-IPSec security parameters at the next phase of the protocol using some symmetric encryption algorithm. This shared secret depends on the symmetric encryption algorithm used in the next phase of transfer of security parameters. Both the nodes may perform some key establishment protocol like Diffie Hellman [69] to derive a shared secret. The source node may select the key and send the same to the intermediate node after encrypting with the public key of the intermediate node (indicated as 7 and 8 in fig 4.9). One point to note here is that the actual transfer of the security parameters may involve zone map and cryptographic information of varying size. So the usage of symmetric cryptographic algorithm is desirable at the final phase. Security parameter sharing phase The final phase of the protocol is solely responsible for actual transfer of the security parameters from the source to the intermediate nodes. This phase is also responsible for updation of security and policy databases of the intermediate nodes. This phase consists of the following steps: First, the source node constructs the message consisting of necessary information for the updation of the security databases of the intermediate nodes. It generates a master list M containing the zone map and other common information like protocol, mode, SPI, DML-IPSec endpoints and DML-IPSec protected network addresses. The source node also prepares individual zone lists for all relevant type I zones. This zone specific list contains cryptographic information such as encryption algorithm, encryption key, authentication algorithm, authen- 60

76 tication key etc for that particular zone. Next,the master list and zone lists are concatenated to form the actual message. This message is padded to meet the encryption algorithm block size (if required) and appended with the pad length. Finally this padded message is encrypted using the shared secret established at the previous phase. This encrypted message is sent to the intermediate node (indicated as 9 in fig 4.9). Upon receiving this message, the intermediate node decrypts this concatenated message and parses it to segregate the master zone map and zone specific lists. The policy database is updated for the processing of the DML-IPSec packets. SA entries are created for each of the zone specific lists. Both the outbound and inbound security databases are updated using these information. After successful updation of the databases, the intermediate node acknowledges the same to the source node (indicated as 10 in fig 4.9). M: {ESP,TUNNEL,gw1,gw2,nw1,nw2,spi,1}L1 {12,e1,ek1,a1,ak1} Zone List for Single type I Zone M: {ESP,TUNNEL,gw1,gw2,nw1,nw2,spi,2}L1 {1,e1,ek1,a1,ak1} L2 {2,e2,ek2,a2,ak2} Zone List for two type I Zones Fig. 4.10: Zone map and Cryptographic message format during Key Sharing Protocol We use the fig 4.10 to explain the message transfer at the final phase of the protocol. As shown in the diagram, the first case transmits zone details corresponding to ESP tunnel mode with only one type I zone. The scope of the single type I zone spans over inner IP header and TCP header and protected with encryption algorithm e1 with key ek1 and authentication algorithm a1 with key ak1. The second case corresponds to ESP tunnel mode with two type I zones. 61

77 The scope of the first type I zone spans over inner IP header with encryption algorithm e1 and key ek1 and authentication algorithm a1 along with key ak1. The second type I zone is defined over transport layer header with encryption algorithm e2 and key ek2 and authentication algorithm a2 along with key ak2. Revocation of Security Parameters One additional responsibility of the key sharing protocol is the revocation or change of the security parameters. The revocation of the security parameters is required, when the current security relationship of a DML-IPSec expires. Whenever the current security parameter expires or the existing DML-IPSec terminates, the source node communicates the same to the intermediate nodes. Special ICMP code is used to transfer the revocation message to the intermediate node. The source node constructs the message representing the DML-IPSec connection descriptor and encrypts the same with public key of the intermediate node. This connection descriptors consist of security policy related fields such as gateway addresses, mode, protocol, SPI etc. Upon receiving this message the intermediate nodes update their security databases, and all security associations related to the current connection are deleted. Zone Reorganization at the Intermediate Nodes: As described in the zone reorganization phase of the key sharing protocol, the end points of a DML-IPSec session may decide to renegotiate the existing zone map definition for providing service to a new intermediate node. In that case, the information related to these changes has to be communicated to already existing intermediate nodes. The key sharing protocol carries out this responsibility using the following steps: First, a special ICMP error message is sent to the currently existing intermediate 62

78 node to indicate this zone re-negotiation. Upon receiving this message, the intermediate node gets involved in key sharing protocol. Here the source node and the concerned intermediate node first get engaged in the establishment of a temporary shared secret. Using this shared secret, the source node securely sends the new zone map to the intermediate node. We elaborate the working of this reorganization with an example. Let us assume that the end points of DML-IPSec session initiates the communication with only one type II zone in tunnel mode ESP. Afterwords an intermediate node, say IN1 requests for access to both inner IP header and transport layer header. To serve this request, the zone maps of the DML-IPSec are modified to one type I zone spanning over inner IP header and transport header at the first phase of key sharing protocol. At the last phase of the key sharing protocol, these zone and security information are sent to the intermediate node IN1. It may happen that after some time another intermediate node, say IN2 requests for access to inner IP header only. In that case the DML-IPSec endpoints may reorganize the zone map to two type I zones, where the first type I zone covers the inner IP header and the second type I zone spans the transport layer header. This information is sent to IN2 at the last phase of the key sharing protocol. Moreover, this information about zone re-negotiation is communicated to IN1 also using the zone reorganization procedure at the intermediate node as discussed at the previous section. An Example of Key Sharing We explain the working of the key sharing protocol with an example as depicted in Fig The key sharing protocol uses currently unused ICMP type 1 for all types of communication with different code values. In our subsequent discussion, we represent ICMP message with type t and code c as <t,c>. The 63

79 ESP packet Header inaccessible 1,1 Authentication Request 1,2 Authentication Response 1,3 Shared Key (K) 1,4 Acknowledgement 1,5 Searches database and Fails to find entry Forwards the packet Security Parameter 1,6 Acknowledgement 1,7 ESP packet Searches database and decrypts the header zones Recreate the ESP packet and forwards Source IPSec Gateway Intermediate device Destination IPSec Gateway Fig. 4.11: Key Sharing Protocol Example type signifies message type, for example for key sharing between intermediate node and source node or the zone reorganization phase. The code specifies the particular operation specified by that message. As shown in the figure, after receiving the first ESP packet the intermediate node sends header inaccessible message as <1,1>. The requested header access is mentioned in the body portion of that <1,1> message. As the service requested by the intermediate node can be granted using current zone map of the source node, the next message is the authentication challenge. The source node sends the challenge message as <1,2>. Upon receiving this challenge message, the intermediate node sends the response to the challenge as <1,3> and that marks the end of second phase. It is followed by the third phase of establishment of a shared secret. Here the source node selects the encryption key K for the final phase and encrypts that with public key of the intermediate node. This information is sent as <1,4>. Next, 64

80 intermediate node acknowledges the same to source node as <1,5> and the current phase ends. In the final phase, the source node generates the necessary zone map and zone lists and encrypts the same with the key K established in the previous phase. This encrypted message is sent to the intermediate node as <1,6>. The final message is <1,7> from the intermediate node to the source to acknowledge the receipt of security parameters. After these message transfers, the intermediate node is able to handle the DML-IPSec packets for intermediate processing as shown in the case of the second ESP packet in the figure Handling of variable Zone sizes The zone size in ML-IPSec is fixed and the zone boundaries are represented by byte level definition. This restricts the access to zones with variable sizes at intermediate nodes. The lengths of the zones may vary as the length of IP and TCP headers vary between 20 bytes and 60 bytes depending upon the presence of the OPTION fields. These OPTION fields are used by the IP and TCP protocols for carrying synchronization and other messages. For example, the OPTION fields in IP header is used in the case of source routing option of IP packet routing, marking the address of traversed path at the traceroute option of ping program etc. The OPTION fields in TCP headers are used for the synchronization of TCP window, MTU etc. The access to these information carried by the OPTION fields may be required at several intermediate nodes for their functioning. Thus, providing access to these variable size zones of an IP datagram is important. In this section, we discuss the handling of variable zone size of the DML-IPSec protocol in detail using the previous discussion of the overall processing of the protocol. As discussed in previous sections, we define zone as a contiguous portion of IP datagram. Moreover, we have defined type I zones as protocol headers or combination 65

81 of continuous protocol headers. In this way, it is possible to provide access to all upper layer headers to the intermediate nodes without compromising on the end-to-end security of the actual payload. During outbound processing, we derive the lengths of the type I zones from the protocol header length fields as discussed in the previous section. During inbound processing, partial decryption of the protocol headers is employed to decide the length field of the headers. After the partial decryption of the protocol headers, the lengths of the zones are derived. For illustration purpose, we define one particular scenario, where we use ESP in tunnel mode and we define two zones. The only type I zone covers the whole of inner IP header and corresponding transport layer header, whereas the single type II zone covers the transport layer payload. We use DES algorithm for the encryption of the first zone and AES with 256 bits key for the encryption of the second zone. During inbound processing of both intermediate node and DML-IPSec endpoints, for handling the variable size header length, we first decrypt the first two DES blocks, (first 16 octets). Upon successful decryption of these two blocks we derive the actual length of IP header from the header length field, whereas the protocol field of the IP header defines the next protocol definition. In case of UDP and ICMP the transport layer header lengths are derived directly. In case of TCP we continue the block by block decryption until we decrypt the 16th octet of TCP header, where we get the TCP header length value. 4.3 SUMMARY In this chapter, we have described the details of the Dynamic Multi Layer IPSec (DML-IPSec) protocol. We have redefined some of IPSec and ML-IPSec concepts for the DML-IPSec protocol. We have redefined the concept of zone so that packets 66

82 with variable header length can be accommodated during DML-IPSec processing. In order to provide seamless access to intermediate nodes, we have classified zones as type I and type II zones. Type I zones are defined as protocol headers or proper combination of protocol headers. The type I zones are allowed to be accessed by the intermediate nodes. The other type of zone, called type II zone is defined on the payload portion and kept secure between the endpoints of the DML-IPSec sessions. We have also redefined the security association in DML-IPSec. A single IP datagram may be processed using different cryptographic parameters at different zones. We present the key sharing protocol for sharing cryptographic information and allied zone specific parameters between the DML-IPSec endpoints and intermediate nodes. This key sharing protocol is invoked, whenever a DML-IPSec protected datagram passes through an intermediate node with partial DML-IPSec processing capabilities. We also address the issue of zones with variable lengths in case of IP datagrams with OPTION fields. In the next chapter, we discuss the implementation details of the DML-IPSec protocol in Linux environment. 67

83 CHAPTER 5 Design and Implementation of DML-IPSec in Linux Environment The DML-IPSec protocol as described in the previous chapter addresses the issues of key sharing with the intermediate nodes and that of accommodating packets with variable length headers. The access to upper layer header information at the intermediate nodes is an issue when the upper layer protocol headers are encrypted as in the case of ESP. Therefore, the DML-IPSec protocol assumes significance in case of ESP protocol compared to that of the authentication only case of AH protocol. Hence, the implementation is done for the ESP protocol. In this chapter, we discuss the design issues and provide the implementation details of the DML-IPSec protocol in Linux OS. The implementation is carried out in Linux kernel version [70] of RHEL 4. The existing implementation of IPSec in Linux kernel is modified to provide the multi layer processing capability. The ICMP based socket programming is used for different message transfers required for the key sharing protocol. A user level interface in the form of a pseudo device driver is also implemented to update the kernel level security databases from the user space key sharing utilities. We first briefly mention the implementation aspects of the IPSec protocol suite along with special emphasis on the ESP protocol. Next, we present the implementation details of the DML-IPSec ESP protocol. Finally we provide the details of the test-bed setup and the results validating the design and implementation of DML-IPSec. 68

84 5.1 IMPLEMENTATION ASPECTS OF BASIC IPSEC The Linux kernel series 2.6.X has the implementation of IPSec protocols i.e. AH and ESP built in the IP stack. User space utilities (setkey, racoon) are provided to configure the kernel space configurations of IPSec [71]. The main modules of the native IPSec implementation [72 74] are described in the following sections Implementation of Protocols The ESP and AH protocols are implemented along with the implementation of IP. The data structures for representing Security Policies (SPs) and Security Association (SAs) are crucial for the implementation of IPSec. Fig 5.1 depicts the various XFRM structures used for the representation of the SPs and SAs. The Security Policy Database (SPD) is represented using xfrm-policy structure. The data structure for SPD consists of bundle of SAs implemented as xfrm-dst structures. The bundle of SAs consists of individual SA entries implemented as xfrm-state structures. This xfrm-state structure holds all necessary information for a particular transformation. This structure contains information like replay window, sequence number, and cryptographic information. The sharable information about encryption and authentication algorithm are stored in xfrm-algo structure objects, while private data e.g., key, Initialization Vector for a particular transformation are maintained as esp-data structure object of the xfrm-state structure User space utility User space utility setkey is used for updating the structures representing the SPs of the SPD. The structures representing SAs can be updated either manually by using the setkey utility or by automatic key exchange through the racoon utility. Racoon uses the IKE protocol for the automatic configuration of the SAs. 69

85 struct xfrm_algo { char alg_name[64]; int alg_key_len;... } struct xfrm_policy { struct xfrm_policy*next; u32 priority; struct dst_entry *bundles; u16 family; u8 type; u8 action; u8 xfrm_nr;... struct xfrm_tmpl xfrm_vec[xfrm_max_depth]; } struct dst_entry { struct xfrm_state*xfrm; struct dst_entry*child; } NULL struct xfrm_state { /*Cryptographic Information*/ struct xfrm_algo*aalg; struct xfrm_algo*ealg;... void*data; /*Other Information*/ struct xfrm_replay_state replay; u8 replay_window;... } struct xfrm_algo { char alg_name[64]; int alg_key_len;... } struct esp_data { /* Confidentiality */ struct { u8*... key; }conf; /* Integrity. */ struct { u8*... key; } auth; } Fig. 5.1: SPD and SA in Linux Implementation of IPSec Figure 5.2 specifies a flow until kernel applies IPSec-SA to a packet. The numbers indicated in the figure corresponding to the events are explained below. (1) The administrator sets a policy by populating the structures representing SPs using setkey. (2) The kernel refers to SPD in order to make a decision of applying IPSec to a packet. (3) If IPSec is required, then kernel gets the key for IPSec-SA from SAD. (4) If it fails, then kernel sends a request to get the key to racoon (in the case of absence of manual SA configuration). (5) The racoon exchanges the key by using IKE with the other end of the IPSec communication. (6) The racoon updates the structures representing SAs. (7) The Kernel can send a packet after providing IPSec security according to SAs. 70

86 Setkey (1) (4) Racoon (6) IKE (5) Remote IPSec Machine SPD (2) (3) Kernel SAD (7) Fig. 5.2: Illustration of interaction between user space utilities and Kernel 5.2 IMPLEMENTATION OF THE DML-IPSEC PROTOCOL We implemented the multi-layer IPSec functionalities inside the native Linux implementation of IPSec protocol. The SA structure was updated to hold the necessary security association information for multiple zones instead of a single SA of the normal IPSec. The zone mapping for different zones were implemented along-with the kernel implementation of security associations. The inbound and outbound modules of the IPSec endpoints were re-implemented to incorporate multi-layer IPSec capability. We also implemented necessary modules for providing partial IPSec processing capabilities at the intermediate nodes. The implementation details of the major modules of the DML-IPSec protocol are described next Implementation of Zones The concept of zone is not present in the native implementation of the IPSec-ESP protocol. We implemented zones along with the security associations. Each zone has a set of cryptographic parameters that may vary from zone to zone. The zone specific cryptographic information are implemented by modification of security association as explained in the following. every ESP communication. The DML-IPSec protocol also defines a zone map for This zone map contains information regarding number 71

87 of zones and the scope of each zone. This zone map is consulted during the key sharing protocol and also at the beginning of packet processing module to determine the zone boundaries of the datagrams. We implement this zone map as a DML-zonemap structure as depicted in Fig 5.3. This DML-zone-map contains the number of zones and the scope of all the zones are mentioned in the array of integer values. Finally, the xfrm-state structure corresponding to a ESP tunnel holds an entry for the DML-zone-map structure. #ifdef DML_IPSEC struct DML_zone_map{ u8* scope; // Scope for Zones #ifdef DML_IPSEC struct DML_esp_data{ struct DML_esp_data * next; /*SA for Next Zone*/ struct esp_data *value; /*Private data for that Zone*/ struct xfrm_algo * aalgo,*ealgo,*calgo; u8 no_of_zones; /*Common algo specific data for that zone*/ // Number of Zones int Scope; /*Scope of this Zone*/ }; #endif }; #endif Fig. 5.3: Zone structure and Zone specific DML-IPSec ESP SA Implementation of security association The DML-IPSec protocol defines end-to-end security policies between two endpoints as the information regarding any intermediate node is not relevant for packet processing at the endpoints. The security policies at the DML-IPSec endpoints are similar to normal IPSec. Thus the security policy definition resembles that of normal IPSec. On the other hand, the security association information is significantly different in DML- IPSec than the standard IPSec, as the zone specific cryptographic information has to be maintained along with every security association. In normal ESP implementation every IPSec communication has a set of security parameters represented by the structure xfrm-state. This structure in turn stores the 72

88 algorithm specific entries in xfrm-algo structure and the information about key, IV etc in esp-data structure. The xfrm-state structure also holds information about replay window and sequence number. In the DML-IPSec implementation, the xfrm-state structure is segregated into two parts. The first one contains common information for all zones. The other part holds zone specific information through a pointer to a new data structure, called DML-esp-data, that holds cryptographic information for a particular zone. As depicted in Fig 5.4, this structure has entries for algorithm specific xfrm-algo structures and also private data represented as esp-data structures. struct xfrm_algo { charalg_name[64]; intalg_key_len;... } struct xfrm_algo { charalg_name[64]; intalg_key_len; }... struct xfrm_policy { struct dst_entry *bundles;... } struct dst_entry{ struct xfrm_state*xfrm;... struct dst_entry*child; } struct xfrm_state /*Cryptographic Information*/ void *zonal_sa; /*Other Information*/ u8replay_window; struct xfrm_replay_state replay; struct *DML_zone_map Map;... struct DML_esp_data { struct xfrm_algo *aalgo, *calgo,*ealgo; struct DML_esp_data *next; struct esp_data *value; } struct DML_esp_data { struct xfrm_algo *aalgo, *calgo,*ealgo; struct DML_esp_data *next; struct esp_data *value; } NULL struct DML_zone_map { u8* scope; u8 no_of_zones; } struct esp_data { /* Confidentiality */ /* Integrity. */ } struct esp_data { /* Confidentiality */ /* Integrity. */ } NULL Fig. 5.4: SPD and SA structures in the DML-IPSec Fig. 5.4 shows the XFRM structures for ESP with one type I zone and one type II zone. As shown in the figure, the SPD structure xfrm-policy points to SA bundle structure dst-entry that contains SA structure xfrm-state. The xfrm-state structure holds zone map structure DML-zone-map. The zone specific cryptographic information is stored in the structure DML-esp-data. Therefore, the number of instances of this 73

89 structure is equal to the number of zones. As there are two zones, one type I and one type II zone in the case of Fig. 5.4, two instances of the structure DML-esp-data is present. Here the first one stores cryptographic information for single type I zone and the second one holds the cryptographic information for the type II zone Implementation of the datagram processing at the endpoints In DML-IPSec ESP implementation, at the outbound processing module, the xfrmpolicy structures representing the SPs are first searched linearly till a match occurs. If the policy is ESP, the SA is derived from the dst-entry SA bundle. Next, the DMLzone-map structure is scanned from the xfrm-state structure. Using the zone map definition, the outgoing IP datagram is partitioned into multiple zones. Next, the DML-esp-data list of the xfrm-state structure is linearly accessed to provide cryptographic security to zones. The common information for all the zones are fetched from the entries containing common information in xfrm-state structure. In the inbound processing of DML-IPSec ESP, first the xfrm-state structure representing SAs is derived using the selectors containing SPI and the IP address. In DML-IPSec, different cryptographic parameters are applied on different zones. Moreover, the derivation of the zone boundaries depends on the encrypted header portions. In DML-IPSec, first the zone definition is derived from the DML-zone-map structure of the xfrm-state structure and partial decryption on the type I zones is employed for the derivation of exact zone lengths. The DML-esp-data list of the xfrm-state structure is linearly accessed to provide cryptographic information specific to zones. This decryption is carried out by copying the encrypted ESP data into temporary buffer as the authentication verification has to be performed on the encrypted zone data. After the derivation of the zone boundaries, all the zones are decrypted and the original IP datagram is re-constructed back. After the decryption of the ESP packet, SPD is 74

90 referred through the selector field of the SA. On successful policy verification, the IP datagram traverses through the IP stack of the inbound machine DML-IPSec processing at the intermediate nodes The implementation of DML-IPSec processing at intermediate nodes is different from that of the endpoints. The inbound module decrypts the necessary type I zones to generate a partially decrypted IP datagram so that the upper layer headers can be examined by several networking applications of the intermediate nodes. The outbound module processes the partially decrypted IP datagram to reconstruct the original DML-IPSec packet. The security policy and association databases are implemented as XFRM structures as discussed in the previous section. The kernel level structures representing the SPs and SAs are updated by the key sharing protocol. During the inbound processing, the structures representing the SPs are searched linearly. If the policy for an incoming DML-IPSec packet is partial DML-IPSec processing, the structures representing SAs for that transformation are fetched from the SPs. The structure representing the SA has cryptographic information for all necessary type I zones represented as DML-esp-data structures as mentioned in the previous sections. Partial decryption of headers is employed to derive the zone boundaries following which the necessary type I zones are decrypted. After successful decryption of necessary type I zones, the IP datagram is constructed using these partial decrypted zones. One important point to notice is that, information like sequence number of ESP header, cryptographic synchronization information like initialization vector of different zones varies from IP datagram to datagram. So, these information need to be saved per packet basis at the inbound processing module of the intermediate node. The DML-IPSec implementation saves these information in the newly generated partially decrypted IP datagram itself. After decrypting necessary type I zones, the ESP header 75

91 and IVs of the decrypted zones are appended after the partially decrypted IP datagram and the length field and checksums are re-computed. The partially decrypted ESP packets are encrypted back to reconstruct the DML- IPSec ESP packet at the outbound module of the intermediate nodes. Similar to the inbound module, the policy database is searched to find out the policy. In case of partial DML-IPSec processing, the security association entry is fetched. Unlike the DML-IPSec endpoints, where cryptographic synchronization data and ESP header sequence numbers are derived from kernel variables and random numbers, the outbound module of intermediate nodes need to use the values used by the source of the packet. The appended ESP header and synchronization values from the partially decrypted IP datagram are used along with the cryptographic information saved at the zonal SAs of the outbound module to reconstruct the original DML-IPSec ESP packet. The intermediate nodes have to process an ESP packet which is defined between two different DML-IPSec endpoints. Hence, the security policy database is defined for two other machines. The key sharing protocol is responsible for updating the security databases accordingly. Another important point is that both the inbound and outbound security policy and association database entries have to be created by the key sharing protocol itself. The security association databases of both the inbound and outbound modules have to be populated with same cryptographic information. However, the policy databases may vary considerably. For example, ESP tunnel mode datagrams with type I zone spanning over inner IP header may have different entries at the outbound policy database than the inbound policy database. 76

92 5.2.5 Security Databases configuration utility The security policies of DML-IPSec communication are dependent only on the DML- IPSec endpoints and not on the intermediate nodes. The security association on the contrary is dependent on the information about intermediate processing as it decides the cryptographic parameters for different portions of the IP datagram. The DML- IPSec ESP implementation uses the default IPSec utility setkey for the updation of the xfrm-policy structures representing the SPs. The default IPSec configuration file is used for updating the SPD at the time of defining secure ESP communication between two DML-IPSec endpoints. However, the updation of the SA entries are different from that of native IPSec implementation, as DML-IPSec require to create zone specific SA entries at the xfrmstate structure. The type II zone is secured between the endpoints, whereas the type I zones might be accessed by the intermediate nodes. Thus, the intermediate nodes do not participate in the establishment of SA corresponding to type II zone. The DML- IPSec protocol also uses the default IPSec mechanisms (setkey and racoon utilities) for defining the SA between two endpoints, i.e. the SA for the type II zone. However, the SA for type I zones which are specifically introduced in DML-IPSec processing needs to be updated through a separate configuration file and an interface. The configuration file contains the security parameters corresponding to type I zone SAs. The information in the configuration file is communicated to the kernel space through a pseudo character device driver [75]. This device driver is also used by the key sharing protocol for updating zone specific SA configuration at the xfrm-state structures, representing SA. The esp-init-state function of the native kernel implementation, invoked by the default IPSec configuration utilities, is modified to create necessary entries for all type I zones and sole type II zone at the xfrm-state structure representing SA. Figure 5.5 shows the steps involved when kernel applies zonal SA according to 77

93 Setkey DML IPSec utility Key Sharing Protocol Racoon IKE Remote IPSec Machine (6) (2) (10) (5) (1) Pseudo Character (11) Device deriver (8) (7) SPD (3) Kernel (9) (12) (4) SAD Fig. 5.5: Illustration of interaction between user space utilities and Kernel in DML-IPSec DML-IPSec definition. The numbers indicated in the figure shows the sequence of events that are described below: 1. The administrator sets a policy to structures representing SPs by using setkey. 2. The DML-IPSec user space utility updates the type I zone specific information to the pseudo character device driver. 3. Kernel refers to SPD in order to make a decision of applying IPSec to a packet. 4. If DML-IPSec is required, then kernel get the Key for zonal SAs from SAD. 5. If it fails to get the key, then kernel sends a request to get the zone II Key to racoon (in the case of absence of manual SA configuration). 6. The racoon exchanges the Key by using IKE with the other end of the IPSec communication. 7. The racoon updates the structures representing SAs. 8. The pseudo character device driver is consulted by the SA updation function and zonal SAs are created. 9. The kernel can send a packet after providing DML-IPSec security according to SAs. 78

94 10. Key sharing protocol sends the new zone specific information to the pseudo character driver 11. Pseudo device driver updates the SAs according to new zonal information 12. The kernel can send a packet after providing DML-IPSec security according to SAs negotiated by key sharing protocol Key Sharing Protocol The key sharing protocol is one of the major components of the DML-IPSec protocol. In the following discussion, we present the implementation details of the key sharing protocol. The key sharing protocol consists of some user space utilities, corresponding kernel space components and a mechanism for communication between the two. The user space utilities carry out the invocation of the protocol, updation of the security association databases and ensure the consistency of zone mapping and zone specific cryptographic information through all concerned nodes of the DML-IPSec communication. At the kernel level, pseudo character device driver is implemented to populate the kernel space data structures with the data received from the user space. The main goal of the key sharing protocol is to share the zone mapping and cryptographic information from the source of DML-IPSec communication to an intermediate nodes. In this regard, the key sharing protocol implements a series of message transfers between the source and intermediate node of DML-IPSec communication. The messages are transferred using ICMP packets. The protocol employs currently unused type and code field of the ICMP protocol [5,76] to carry out the communication. The payload carries the actual message corresponding to the <type,code> pair of the ICMP packet. The receiver of the ICMP packet decodes the message according to the <type,code> pair of the ICMP header. The payload of the ICMP messages are of varying size as it may contain encrypted zone map, encrypted authenticated data etc. 79

95 The sender module has to update necessary header fields like length, checksum etc for constructing a legitimate ICMP packet. Apart from sharing the zone mapping and cryptographic information between DML-IPSec source and intermediate nodes, the key sharing protocol also communicates the same between the source and destination nodes during the zone reorganization phase. The key sharing protocol implements the zone reorganization messages using ICMP packets. For authentication, the protocol uses pari library implementation of RSA encryption algorithm [77, 78]. Linux operating system default PRNG rand is used for the generation of PRNG used in the protocol. We have used DSA encryption algorithm for the encryption of the zone specific cryptographic information at the final phase of key sharing. However all these cryptography related methods are implemented in a modular way so that replacement by user-specific routines can be made seamlessly. After successful key transfer, the key sharing protocol needs to update the security databases of the Linux kernel. In the case of end nodes, Security Association Database has to be modified in accordance with the zone map definition configuration files. Here the pseudo character device driver is used to update kernel level data structure as discussed in the previous discussion. However, in the case of intermediate nodes, the security association as well as Security Policy Database need to be updated. The security parameter information is first parsed to segregate the policy database and association database information. The key sharing protocol has to update both the inbound and outbound security databases. All the relevant information for updating these databases are communicated at the final phase of the key sharing protocol itself. Fig 5.6 depicts the overall high level interaction of the DML-IPSec implementation. As shown in the diagram, the user space key sharing protocol uses the pseudo character device driver [75] for communicating to the kernel level implementation of DML-IPSec 80

96 KERNEL SPACE SA Bundle SA SPD Zonal SA Zonal SA Pseudo Character Device Driver NULL NULL DML IPSec Configuration and Key sharing Protocol Setkey and Racoon utility USER SPACE Fig. 5.6: High level Interaction of DML-IPSec implementation processing. 5.3 EXPERIMENTAL VALIDATION OF THE DML-IPSEC PROTO- COL This section presents experimental validation of the DML-IPSec protocol. We study several intermediate applications that require access to different fields of the IP, TCP/UDP headers. The standard IPSec protocols-ah and ESP-restrict the functioning of these applications at intermediate nodes as they require access to the transport layer and upper layer headers. For example, in case of tunnel mode ESP, access to the inner IP header is difficult as it remains encrypted. The access to the fields of the TCP and UDP headers is also difficult because of similar reasons. The details of the conflicts between intermediate processing and IPSec security is discussed in chapter 3. We will briefly mention the header fields required for them in the Table 5.1. Next, we present 81

97 three zone mappings according to DML-IPSec ESP definition and show that the problem of accessing the headers at intermediate nodes can be overcome by using suitable zone mapping. Table 5.1: Applications, their use and the headers of the IP datagram accessed by them Application Responsibility Header Fields use Performance enhancement proxy Performance Enhancement for TCP IP, TCP Hdr Appl. Proxy Performance gain for Web IP, TCP and HTTP Hdr Routers with Traffic Eng. Providing QoS based service IP, TCP or UDP Hdr Packet filtering Firewall Firewalling IP,TCP,UDP Hdr Application layer Firewall Firewalling IP,TCP, UDP,application Hdr Traffic analysis Load/traffic control IP,TCP, UDP,application Hdr We consider three different zone mappings for ESP tunnel mode, designated by different cases as follows: Case I : Single type II Zone. Type I zone : Nil Type II zone : Spans entire inner IP datagram Case II: Two zones with one type I and one type II zones Type I zone: Single type I zone spans inner IP header and transport header. Type II zone : Spans entire transport layer payload. Case III: Four zones with maximum of three type I zones and one type II zone First type I zone spans the inner IP header. Second type I zone spans the transport layer header. Third type I zone spans the application layer header.(for standard applications otherwise void) 82

98 Type II zone : Spans entire application layer payload for standard application or the entire transport layer payload. In the table we mention about the accessibility of header fields and thus working of different intermediate applications for different zone mapping mentioned above. Table 5.2: Working of different intermediate application in different zone mappings Header Fields Application that can function Case I No access No application can function Case II Inner IP and Transport hdr PEP,Routers with QoS, Packet Filter FW Case III Inner IP,transport and application hdr PEP,Appl Proxy,Routers, Firewall,Traffic analysis From table 5.1 we observe that all of the intermediate services require to access original IP header and transport layer header and some of them require access to application layer header too. Table 5.2 shows that all these requirements can be met by one of the three typical zone mapping listed above as type II and III. It is to be noted that all these services are capable of processing packets with variable size TCP and IP header. But in the presence of the existing ML-IPSec implementation, they fail to get access to the OPTION fields. In the next section, we provide experimental verification of the claims of the DML- IPSec protocol with three different applications running in the intermediate nodes. First, we use packet filtering firewall to show the accessibility of the inner IP and transport layer header followed by application level firewall, which requires access to IP, TCP and HTTP header. Next, we validate our claim of handling sessions with variable zone sizes by providing access to OPTION fields of IP packets. The IP packets having option fields have variable sized zones. We demonstrate it using a ping program with record routing feature. The presence of the IP address of the intermediate node at 83

99 the record route output validates our claim of accessibility of OPTION field of inner IP header at intermediate node. In the absence of the DML-IPSec protocol, the firewall used to drop packets for not being able to retrieve the required headers. Similarly, the record route output did not show the IP addresses of the intermediate nodes that demonstrated the inaccessibility of the OPTION fields of the IP datagram Test bed setup Client (C11) IPSec Gateway (GW1) Intermediate Device ( IN ) IPSec Gateway (GW2) Client (C21) (eth0) (eth1) (eth0) (eth0) (eth1) (eth0) (eth1) (eth0) Fig. 5.7: Test bed Set up Figure 5.7 shows the testbed setup for the implementation of DML-IPSec. We have configured two Linux servers as the ESP gateway (labeled as GW1 and GW2 in figure). We have configured another Linux server (labeled as IN) as the intermediate node in between GW1 and GW2 that run the different intermediate applications. All these Linux servers are installed with RHEL-4 with the kernel version The gateway machines GW1 and GW2 have the DML-IPSec implementation for ESP protocol, whereas the intermediate node IN have the capabilities for partial DML- IPSec processing. We have connected two client machines at the gateway machines (labeled as C11 and C21). The IP addresses of the clients and servers are shown in Fig Validation with respect to intermediate services In this section, we provide the details of the experiments on DML-IPSec protocol and the corresponding results in the presence of the following intermediate applications. For all these subsequent experiments, we configure a DML-IPSec ESP tunnel between 84

100 GW1 and GW2. The tunnel is defined for the entire subnet of the GW1 and GW2 that also covers the clients C11 and C21. The relevant applications described next are run in the intermediate node IN. Packet Filtering Firewall We carried out experiments for validating our solution with respect to stateful packet filtering using iptables firewall [79, 80] at IN for FTP session between C11 and C21. We have chosen FTP as it uses TCP protocol in its transport layer. The FORWARD chain of the firewall is configured to allow only FTP packets between C11 and C21. The default policy is set to DROP packets implying that in the event of the firewall not being to access the FTP port information encoded in the port fields of the TCP header, the packet will be dropped. We have also configured the iptables firewall to log all the traffic flowing through the forward chain. The GW1 and GW2 are configured with two zone DML-IPSec ESP in tunnel mode, whereas the single type I zone spans the inner IP header and transport layer header. The single type II zone spans over the transport layer payload. The first zone is protected with DES algorithm with HMAC-MD5 authentication and second zone is protected with AES encryption and HMAC-MD5 authentication. At the first phase of our experimentation, we disable the execution of the user level module of the key sharing protocol at IN. Now we initiate a FTP request from C21 to C11. The FTP session fails to establish. At the next phase, we start the key sharing protocol with the request for the type I zone spanning over IP and Transport layer header. After successful execution of the key sharing protocol, we again initiate a FTP session from C21 to C11. Here the session is established. In the first phase, the FTP session could not establish as the iptables firewall module is not able to access the inner IP and TCP headers of the FTP packet. Fig- 85

101 ure 5.10 depicts the screendump of the relevant kernel log message entries at the node IN corresponding to the ESP packets seen at the intermediate node. We can notice SRC, DST and PROTO fields in all the three packets. The SRC and DST represent IP addresses of GW2 and GW1 respectively. ESP value at the PROTO field signifies that these packets are of ESP protocol from GW2 to GW1. From the SRC and DST fields, it can be observed that all the packets are sent only from GW2 to GW1. These packets corresponds to the ESP encapsulated TCP SYN packets from C21 to C11. These packets are retransmitted a number of times due to the non-receipt of TCP acknowledgment packets corresponding to the TCP SYN packets. The acknowledgment packet not received as the firewall could not decrypt the ESP encapsulated TCP SYN packets, resulting in dropping the SYN packets at IN itself. In the second case, we configure the key sharing module to request the parameters for zone request up to transport layer header. The FTP access is granted as the access to the inner IP and TCP header could now be possible at the iptables firewall module of IN. Figure 5.9 depicts the screendump of the relevant kernel log message entries at the node IN. We can see TCP packets flowing between C11 and C21 in both directions as the intermediate node can decrypt the type I zone. The first three packets correspond to the 3-way TCP handshake between C21 and C11, whereas last two packets represent FTP traffic transfer(port No 21). Fig. 5.8: ESP packet corresponding to TCP request at the forwarding chain of firewall at IN Application layer firewall 86

102 Fig. 5.9: Partially decrypted TCP packet corresponding to FTP request at the forwarding chain of firewall at IN The following experiment validates our claim of accessibility of application layer headers at the intermediate nodes. We configure string match extension module of the iptables firewall for allowing application layer header access at the intermediate node. We configure a web server in the C11 with address c11.org. We initially configure the policy as drop all packets at IN and then add required rules for allowing only HTTP traffic from c11.org. In the first case, with the key sharing module disabled, the access to C11 from C21 is denied. Figure 5.10 depicts the screendump of the kernel log message entries at IN corresponding to this case. Three ESP packets can be seen at the intermediate node. These messages correspond to the ESP encapsulated SYN packets of the 3-way TCP handshake from C21 to C11 that are executed prior to the GET packet of the HTTP protocol. Since the ESP packets can t be partially decrypted, the firewall module DROPs these packets. In the second case, we configure the key sharing module to request parameters for zones up to application layer header for HTTP traffic. The web access is granted as the access to the HTTP header (carrying the web address c11.org) is possible at the iptables firewall module of IN. Figure 5.11 depicts the screendump of the kernel log message entries relevant to this case. Here we can see TCP packets flowing between 87

103 C11 and C21 as the intermediate node can decrypt the type I zone. The first three packets correspond to the TCP handshake prior to the HTTP GET message transfer, whereas last two packets represent web traffic transfer (Port No 80) containing the web access as a part of the HTTP header. Fig. 5.10: ESP packet corresponding to Web request at the forwarding chain of firewall at IN Fig. 5.11: Partially decrypted TCP packet corresponding to Web request at the forwarding chain of firewall at IN Sessions with variable zone sizes Our next experiment validates the ability of the DML-IPSec protocol to handle variable zone size datagrams. One scenario in which an IP datagram can have variable zone size is when the IP header has the OPTION fields present. Depending on the number of such OPTIONs, the size of zone corresponding to the IP header also varies. We use ping application with the traceroute option (ping -R ip-addr) between C21 and C11 to demonstrate the capability of handling variable zone sizes. The traceroute option when enabled inserts the IP addresses of the intermediate nodes through which 88

104 Fig. 5.12: Ping Traceroute Output the packet passes through before reaching its destination. This requires access to the OPTION fields of the IP headers of the ICMP packets as the addresses are inserted in the OPTION fields. We initialize tunnel mode ESP communication between GW1 and GW2 with two zones where the single type I zone spans inner IP header and transport layer header and type II zone covers transport layer payload. We execute the ping application from C21 for C11. The result of the execution is depicted in the Fig At every line, the round trip path for the packet is displayed. As seen in the Fig 5.12, the first output does not have the IP address of the intermediate node IN, i.e., in the list of IP addresses traced in the route of the ping packet. But, second packet onwards the entries for IN are present in the output of the ping application, as the key sharing protocol gets executed immediately after receiving the first ESP packet at IN. We further explain the scenario with the help of Fig This is the screen dump of wireshark packet capturing utility [81] running at the intermediate node during the execution of the ping application discussed above. The first two ESP packets correspond to the first output of the ping application when the intermediate node IN 89

105 Fig. 5.13: Wireshark output for the Ping Application on eth1 interface does not have the cryptographic information for processing the upper layer headers for making entry for own IP address. The IP addresses displayed at the start node are carried through the OPTION field of the inner IP header of the DML-IPSec ESP packet in tunnel mode. The ICMP messages 3-9 in Fig 5.13 correspond to key sharing protocol execution. These messages are ICMP type 1 messages (used in the key sharing protocol) that are not defined in the Wireshark application. Hence, they are marked as obsolete or malformed ICMP packets. On completion of the key sharing protocol, between IN and GW1 the cryptographic parameters are loaded in the intermediate node IN. The packet number 13 in Fig 5.13 is an ICMP message generated after partial decryption of an ESP message generated between GW1 to GW2 corresponding to a ping reply from C11 to C21. As we are capturing the IP packets on the eth1 interface of IN, we can see the ESP packets coming from the GW2 corresponding to the ping request from C21 as seen in packet number 12 in Fig But, the ESP 90

106 packet from GW1 corresponding to the ping reply from C11 gets partially decrypted by the DML-IPSec processing module before being captured on the eth1 interface. Thus, we can observe the partially decrypted ping reply as seen in packet number 13 in Fig Fig. 5.14: Layout of captured ESP Packet on eth0 interface of IN We use the same ping application for describing the layout of the partially decrypted IP packets at the intermediate node IN. We execute a ping application at C11 for C12. The figure 5.14 depicts the output of wireshark application at the eth0 interface of IN, whereas the figure 5.15 depicts the output of wireshark application at the eth1 interface. The screenshot is taken after the execution of the key sharing protocol. The DML-IPSec is configured for ESP in tunnel mode with two zones same as the previous experiment of traceroute. The first zone spans over inner IP header and transport header and secured with DES algorithm. The second zone spans the entire transfer layer payload and encrypted with AES algorithm with 128 bits key 91

107 Fig. 5.15: Layout of partially decrypted ESP packet on eth1 interface of IN length. Both the zones are secured with encryption only mode without the presence of authentication. We executed the ping application from C11 with 32 bytes of ICMP payload. This makes a 60 byte IP packet (20 bytes IP header + 8 bytes ICMP header + 32 bytes of ICMP payload). This ICMP packet is processed by GW1 and produces a two zone DML-IPSec ESP packet in tunnel mode as an IP packet of 132 bytes. The single type I zone (zone1) spans the inner IP header and transport layer header and the type II zone (zone 2) spans the transport layer payload. The ESP packet thus formed consists of 132 bytes of data. The ESP packet consists of outer IP header of 20 bytes followed by 8 bytes of ESP header, 40 bytes of zone1 data and 64 bytes of zone 2 data. The zone1 data is partitioned as 8 bytes of IV and 32 bytes of encrypted data.(28 bytes of inner IP header and ICMP header is padded to meet 8 byte block size requirement of DES algorithm ). The zone2 is partitioned as 16 bytes of IV and 48 bytes of encrypted 92