Ipsec implementation

Ipsec implementation There are many methods to IP Security. In the Microsofts Windows 2003 the server version, there are many such techniques and tweaks which are useful to help provide a secure base to the system. The operating system is very good in protecting the system from attacks which may be active attacks or in some cases passive attacks. The procedures for IPSec are placed properly into the system which helps it tackle such attacks. This is possible by providing a secure packet filter for packet transport and also using cryptography. This technology is very in high use for communication types like host to host, router to router, gateway to gateway, site to site and also in virtual private networks. Some other places for successful implementation are secure servers. The IPSec comes as a basic Group Policy controlled by Dos Prompt commands and it also has user interface with custom programs installed. The implementation of IPSec involves these steps: Overview of IPSec Deployment Determining Our Internet Protocol Security targets Preparing a Internet Protocol Security Policy Implementation of the designed policies Overview of IPSec Deployment: There are many techniques such as usage of cryptography and authentication software to secure the communication in a network. The connection may be between two parties or between a group of users. Security is to make sure that the communication is not broken, the communication is not intervened and the data is not altered. The Internet Protocol Security has some features which help running a secure transmission. IPSec has set procedures which help achieve these ends. Today there are many companies and it is getting harder day by day to ensure the security of such humungous networks with a heavy workload on the networks. It is also very hard to track any attacks on the network in millions and millions of request. Using firewalls to protect a network did work for some days but it has proved to be impractical as it has no proper rules to detect intrusions or attacks. The advent of IPSec is a leap in computer and network security. This protocol has a wide spectrum of features which are strong enough to contain such high volume of network requests and also handle intrusions. The Internet Protocol for Security is not a versatile detection protocol. It is capable of managing most of the policies to grant or reject, block and negotiate the traffic in a network. This can also be permitted to a specific set of addresses or in some cases protocol and also a different policy to each port. It is recommended that we use ICF (Internet Connection Firewall) when we are in need of a firewall which is capable of providing a network interface for very big networks. This is because the internet protocol for Security has a very strict and a very stern strategy which is based on static filtering based on IP addresses. But this is it is totally different in the case of the Internet Connection Firewall. The ICF has policies which has a set of filter for all the addresses which are capable of being accessed. The Internet Protocol for Security can be used when the restriction is only to a particular set of addresses or the communication between a group of computers. There are many ways to use IPSec in a network but the best way is bye using a directory with all the domains and also a GP when needed. Some areas of interest when implementing IPSecurity: The decision of where we must secure computers and how on our network which can be done by running a group of systems in a directory which is also called as the Active Directory Organisational Units or OUs. The next step is to determine the strength of the policies we assign. Determining Our Internet Protocol Security targets: The first step in deploying IPSec on our server or the network can be done properly by deciding which set of systems are in dire need of security. There are surely some places on the network which are in a need of higher security than the other sections. It is for sure that IPSec is capable of providing optimal security but the problems starts when the network slows down due to the excessive data to be processed and also a large number of systems for IPSec to follow and maintain. In some cases, there are systems which are not upgraded to be able to support the IPSecurity. Determining Your IPsec Needs In beginning of the protocol design procedure, proper planning should be done to make sure that our current network environment available for use. It is always helpful to have a set of the network topology with all of its hardware and software components. This procedure is of high importance mainly in the designing procedure. IPSecurity is highly vulnerable to a network topology. There are many network topologies in which IPSec is not well suited. Preparing a Internet Protocol Security Policy: As said earlier, there are many network topologies which are not suitable to the default structure of the IPSec policies. There is a need to develop a custom IPSec set of policies well suited for the current network. Some organisations can run their network with a small set of policies. But in companies with a very huge network, there are many policies which are to be implemented properly and also a stringent structure is to be maintained. Steps below shows how IP Sec policies work. Designing IPsec Policies There might be some cases where the company or the organisation is interested in implementing a policy which sets a secure communication between two specified computers. This can be done by restricting all traffic and adding exceptions which relates to these two systems. This method can be done vice versa. A network can be setup with policies to allow all requests and block specific ports or computers. To implement such exceptions, a thorough analysis of the network is clearly needed. Computer roles: Security for Data Transmission: Security needs are different from each and every data packet transmitted. The security policies are also very different. There are many levels in this instance. When considering encryption, there are many types such as AES, DE5, RSA and many more. RSA is the best encryption software available presently. These programs can be used to secure files on transmission, on a network or even in the system. Operating System Computers: IPSecurity is a very unique technique used to implement security in a network. There are many operating systems which are not so advanced to implement IPSec. There is no support for IPSec. But there are many operating systems which are capable of running IPSec in transport mode. Some other cases, the policies are stored locally which makes it easier to decide as the implementation doesnt take long enough. In some cases, IPSec policies are implemented through the Group Policy. General IPSec Policy Settings General IPSec policy settings must be specified whether we want the policy to provide packet filtering or end-to-end networks. IPSec Rules IPSec rules determine which traffic is affected by an IPSec policy and which actions take place when that type of traffic is encountered. Table6.5 describes the contents of IPSec rules that two computers use to establish a secure, authenticated channel. Specifies a named list of filters. Each filter in the filter list specifies the types of traffic to which the filter action is applied. Filters can be defined to match specific IP protocols, source and destination TCP and UDP ports, and source and destination IP addresses. The filter list name might include the version number, the last update time, and the administrative owner. Each computer discards the filter list name during policy processing. Filter action Specifies whether a packet is permitted, blocked, or secured. If packets are to be secured, specifies how they are secured. A list of security methods specifies the security protocol, cryptographic algorithm, and session key regeneration frequency. Request Security Authentication methods One or more authentication methods, which are specified in order of preference. Available options are KerberosV5, certificate, or preshared key. Specifies whether to use tunnel mode and, if so, the tunnels endpoint. Specifies whether the rule applies to LAN connections, remote access connections, or both. Assigning IPSec Policies: As a domain administrator, we can configure IPSec policies to meet the security requirements of a user, group, application, domain, site, or global enterprise from a domain controller. IPSec policy can also be implemented in a non-Windows2000-based domain environment by using local IPSec policies. Deploying Our IPSec Solution: After scoping our needs, building IPSec policies, and determining our strategy for assigning the policies to specific OUs, test the IPSec policies in a lab environment and conduct a pilot project before rolling them out for production use. To ensure that IPSec policy functions as expected and provides the appropriate level of security, test specific IPSec policy configurations on clients and servers in a lab environment, and then conduct pilot or beta tests in a limited operational environment before conducting a full-scale deployment. A Cryptographic Evaluation of IPsec: Even with all the serious critisisms that we have on IPsec, it is probably the best IP security protocol available at the moment. We have looked at other, functionally similar, protocols in the past (including PPTP [SM98, SM99]) in much the same manner as we have looked at IPsec. None of these protocols come anywhere near their target, but the others manage to miss the mark by a wider margin than IPsec. This difference is less significant from a security point of view; there are no points for getting security nearly right. From a marketing point of view, this is important. IPsec is the current best practice, no matter how badly that reects on our ability to create a good security standard. Our main criticism of IPsec is its complexity. IPsec contains too many options and too much exibility; there are often several ways of doing the same or similar things. This is a typical committee efiect. Committees are notorious for adding features, options, and additional exibility to satisfy various factions within the committee. As we all know, this additional complexity and bloat is seriously detrimental to a normal (functional) standard. However, it has a devastating efiect on a security standard. It is instructive to compare this to the approach taken by NIST for the development of AES [NIST97a, NIST97b]. Instead of a committee, NIST organized a contest. Several small groups each created their own proposal, and the process is limited to picking one of them. At the time of writing there has been one stage of elimination, and any one of the five remaining candidates will make a much better standard than any committee could ever have made. The Complexity Trap: Securitys worst enemy is complexity. Complexity of IPsec In our opinion, IPsec is too complex to be secure. The design obviously tries to support many difierent situations with difierent options. We feel very strongly that the resulting system is well beyond the level of complexity that can be analysed or properly implemented with current methodologies. Thus, no IPsec system will achieve the goal of providing a high level of security. IPsec has two modes of operation: transport mode and tunnel mode. There are two protocols: AH and ESP. AH provides authentication, ESP provides authentication, encryption, or both. This creates a lot of extra complexity: two machines that wish to authenticate a packet can use a total of four difierent modes: transport/AH, tunnel/AH, transport/ESP with NULL encryption, and tunnel/ESP with NULL encryption. The difierences between these options, both in functionality and performance, are minor. The documentation also makes it clear that under some circumstances it is envisioned to use two protocols: AH for the authentication and ESP for the encryption. Modes As far as we can determine, the functionality of tunnel mode is a superset of the functionality of transport mode. (From a network point of view, one can view tunnel mode as a special case of transport mode, but from a security point of view this is not the case.) The only advantage that we can see to transport mode is that it results in a somewhat smaller bandwidth overhead. However, the tunnel mode could be extended in a straightforward way with a specialized header-compression scheme that we will explain shortly. This would achieve virtually the same performance as transport mode without introducing an entirely new mode. We therefore recommend that transport mode be eliminated. Recommendation 1 Eliminate transport mode. Without any documented rationale, we do not know why IPsec has two modes. In our opinion it would require a very compelling argument to introduce a second major mode of operation. The extra cost of a second mode (in terms of added complexity and resulting loss of security) is huge, and it certainly should not be introduced without clearly documented reasons. Eliminating transport mode also eliminates the need to separate the machines on the network into the two categories of hosts and security gateways. The main distinction seems to be that security gateways may not use transport mode; without transport mode the distinction is no longer necessary. Protocols The functionality provided by the two protocols overlaps somewhat. AH provides authentication of the payload and the packet header, while ESP provides authentication and confidentiality of the payload. In transport mode, AH provides a stronger authentication than ESP can provide, as it also authenticates the IP header fields. One of the standard modes of operation would seem to be to use both AH and ESP in transport mode. In tunnel mode, ESP provides the same level of authentication (as the payload includes the original IP header), and AH is typically not combined with ESP [KA98c, section 4.5]. (Implementations are not required to support nested tunnels that would allow ESP and AH to both be used in tunnel mode.) One can question why the IP header fields are being authenticated at all. The authentication of the payload proves that it came from someone who knows the proper authentication key. That by itself should provide adequate information. The IP header fields are only used to get the data to the recipient, and should not afiect the interpretation of the packet. There might be a very good reason why the IP header fields need to be authenticated, but until somebody provides that reason the rationale remains unclear to us. The AH protocol [KA98a] authenticates the IP headers of the loour layers. This is a clear violation of the modularization of the protocol stack. It creates all kind of problems, as some header fields change in transit. As a result, the AH protocol needs to be aware of all data formats used at loour layers so that these mutable fields can be avoided. This is a very ugly construction, and one that will create more problems when future extensions to the IP protocol are made that create new fields that the AH protocol is not aware of. Also, as some header fields are not authenticated, the receiving application still cannot rely on the entire packet. To fully understand the authentication provided by AH, an application needs to take into account the same complex IP header parsing rules that AH uses. The complex definition of the functionality that AH provides can easily lead to security-relevant errors. The tunnel/ESP authentication avoids this problem, but uses more bandwidth. The extra bandwidth requirement can be reduced by a simple specialized compression scheme: for some suitably chosen set of IP header fields X, a single bit in the ESP header indicates whether the X fields in the inner IP header are identical to the corresponding fields in the outer header.2 The fields in question are then removed to reduce the payload size. This compression should be applied after computing the authentication but before any encryption. The authentication is thus still computed on the entire original packet. The receiver reconstitutes the original packet using the outer header fields, and verifies the authentication. A suitable choice of the set of header fields X allows tunnel/ESP to achieve virtually the same low message expansion as transport/AH. We conclude that eliminating transport mode allows the elimination of the AH protocol as well, without loss of functionality. We therefore recommend that the AH protocol be eliminated. IPSEC methodology using different operating systems: IPSEC is a framework for security that operates at the Network Layer by extending the IP packet header. This gives it the ability to encrypt any higher layer protocol, including TCP and UDP sessions, so it offers the greatest flexibility of all the existing TCP/IP cryptosystems. While conceptually simple, setting up IPSEC is much more complex that installing SSH, for example. IPSEC also has the disadvantage of requiring operating system support, since most O/S kernels dont allow direct manipulation of IP headers. Linux IPSEC support (the FreeS/WAN project), for example, isnt included in the standard kernel distribution for this reason, and has to be applied as an add-on. Furthermore, putting the cryptography in the kernel isolates it from the application, making it more difficult to code crypto-aware software. Using SSL, for example, simply requires linking a library into the application and allows the application to easily query what certificates have been used to authenticate a client. IPSEC defines a Security Association (SA) as its primitive means of protecting IP packets. An SA is defined by the packets destination IP address and a 32-bit Security Parameter Index (SPI), that functions somewhat like a TCP or UDP port number. SAs can operate in transport mode, where the IPSEC data field begins with upper level packet headers (usually TCP, UDP, or ICMP), or in tunnel mode, where the IPSEC data field begins with an entirely new IP packet header, ala RFC 2003. Furthermore, SAs can be encapsulated within SAs, forming SA bundles, allowing layered IPSEC protection. For example, one SA might protect all traffic through a gateway, while another SA would protect all traffic to a particular host. The packets finally routed across the network would be encapsulated in an SA bundle consisting of both SAs. A common use of IPSEC is the construction of a Virtual Private Network (VPN), where multiple segments of a private network are linked over a public network using encrypted tunnels. This allows applications on the private network to communicate securely without any local cryptographic support, since the VPN routers perform the encryption and decryption. IPSEC is well suited for this environment, more so than tunneling PPP over SSL or SSH, since it operates directly on the IP packets and preserves a one-to-one correspondence between packets inside and outside the network. In the case of tunneling PPP over an encrypted TCP connection, any packet loss in the public network would trigger a TCP retransmission, stalling the link until the packet was delivered. In particular, running Voice Over IP (VoIP) traffic through a TCP/PPP tunnel would largely defeat the RTP protocol used for VoIP; IPSEC is better suited in this case. IPsec Development for Linux: In the Linux IPv4 IPsec world, a lot of people use FreeS/WAN projects implementation. It consists of an inkernel IPsec processing part, Key Exchange daemon Pluto and some utility commands/scripts. To run Pluto with small changes on our IPsec kernel implementation and reduce impact for user who use FreeS/WAN implementation, we have decided to keep compatibility with FreeS/WANs IPsec programming interface between kernel and userland. For this, we use the same PF KEY interface which FreeS/WAN project extended. In kernel IPsec packet processing part, we developed AH, ESP, SAD and SPD from scratch. PF KEY interface PF KEY(v2), which is described in RFC2367, is key management API mainly for IPsec. PF KEY is used for handling the IPsec Security Association Database. Additionally we have to handle the IPsec Security Policy Database, but there is no standard for the IPsec Security Policy management API. In FreeS/WAN implementation, PF KEY interface is extended to manage the IPsec Security Policy Database. Our kernel 2.4 IPsec implementation also uses the same PF KEY interface as FreeS/WANs one. It is important to be able to run the FreeS/WANs userland application (e.g., Pluto) with small changes. Encryption and Authentication algorithm We provide HMAC-SHA1 and HMAC-MD5 for authentication, NULL, DES-CBC, 3DES-CBS and AES for encryption. We thought encryption and authentication algorithm is not only used by IPsec and there are many algorithms so that we consider encryption and authentication algorithm and those interface should have good modularity. We adopted cipher modules which provided by CryptoAPI Project. Security Association and Security Policy SA and SP themselves dont depend substantially on the IP version. FreeS/WAN project architecture depends on their special virtual network interface for IPsec because it might focus on IPv4 tunnel mode (Their implementation also provides IPv4 transport mode). Their SA, SP, SAD and SPD also depend on their special virtual network interface. We considered and decided it was not suit to IPv6 because the IPv6 stack needed the neighbor discovery and the auto address configuration in its basic specification. If we had implemented IPv6 IPsec stack with their architecture, we had to implement those basic specification in their special virtual network interface. Therefore we implemented our own SAD and SPD in order to handle both IPv4 and IPv6. To improve the system performance, Each database will be locked by smallest granularity. And in many cases we use the read lock. SA and SP are managed by the reference counter to prevent used SA from removing by accident. IPsec Packet Processing Output There are various packet output paths from the IP(v4/6) layer to the network driver layer in Linux kernel networking stack (TCP, UDP/ICMP, and NDP[10] for IPv6). The packets which may be applied IPsec will go through these paths. We had to add IPsec functionality for these output paths, e.g, in IPv6 ip6 xmit() for TCP, ip6 build xmit() for UDP/ICMP and ndisc send ns()/ndisc send rs() for neighbor discovery packets. Output process is as follows): check IPsec SP lookup the IPsec SA by the IPsec SP apply IPsec processing to the packet output the packet to the network driver layer To reduce SA searhing time, we link the SP and the found SA after lookup from the first time. Input At input, there is only path for IP packets. We added IPsec processing part in ip6 input finish. Input process is as follows: receive the packet lookup the IPsec SA by SPI(which resides in AH/ESP header) check integrity and decrypt check IPsec Policy. IPsec Tunnel mode We are using IPv6-over-IPv6(and IPv4-over-IPv4) virtual tunnel device to implement IPsec tunnel mode. This implementation can avoid to duplication code of encapsulation/ decapsulation outer IP header compairing with having these code in the IPsec processing part itself. The virtual tunnel device is not different from the normal IP-over-IP virtual tunnel device in Linux. 4 IPsec implementation for kernel 2.6 The most important difference between ours and them is SAD/SPD part. They thought the whole SPD/SAD mechanic should be flow cache based lookup system shared by IPv4 and IPv6. One month later, they introduced the new network architecture called XFRM to Linux kernel 2.5. At first their developing code lacked IPv6 IPsec only for IPv4 IPsec. In order to suport IPv6 IPsec, we have implemented IPv6 IPsec code based on XFRM (and discarded our original code). PF KEY interface The PF KEY interface of Linux kernel 2.6(and 2.5) is compatible with KAME[3] PF KEY interface. We can use setkey command for configuring SA and SP and Racoon for IKE. Additionally we can add IPsec Policy each socket via Netlink3. They have suported only IPv4 in their first code, we have added IPv6 support. Security Association and Security Policy On the XFRM architecture, IPsec SP, which is represented as xfrm policy structure, will be bound to the routing flow cache (and IPsec policy will point IPsec SA bundle) and IPsec SA, which is represented as xfrm state structure, is included in destination cache, dst entry structure. The chaining destination cache means IPsec SA bundle. IPsec Packet Processing Output The output part of the XFRM architecture is placed between the IP layer and the network driver layer. In general, non IPsec packet will be passed to the network driver layer by a single destination output function, which is resolved routing lookup. But IPsec packet will be need to apply some IPsec processing (e.g., encryption, hash). XFRM functions make a chain of destination output functions (We call Stackable Destination, as shown in Figure3). Each function match each IPsec processing (AH, ESP and IPcomp[11]). To be more specific, in order to pass a packet to the network driver layer we have to do as follows. lookup routing table to decide output function by ip6 route output lookup IPsec Security Policy lookup IPsec Security Association(s) suitable for IPsec Security Policy and create destination chain to apply IPsec, pass a packet to the destination chain Input The input part of the XFRM architecture is simpler than output. The XFRM input function is handled as same as upper layer protocols like TCP, UDP, etc. In IPv6, IPsec headers are defined as IPv6 extension header but IPsec input functions are handled as an upper layer protocol handler. As the result of introducing IPv6 IPsec input processing in Linux. kernel, inconsistencies existed between IPsec headers and other IPv6 extension headers. In order to resolve this, we moved to the other IPv6 extension header handler functions to upper layer protocol handler. In detail, we registered IPsec header (both AH and ESP) handler functions with upper layer protocol handler array inet6 protos. Incoming IPsec packet processing flow is as follows: process IP packet from IP header in sequence process IPsec part (check integrity and decrypt) if founded check IPsec Security Policy pass IP packet next handler IPsec Tunnel mode Linux kernel 2.6 IPsec tunnel mode doesnt use the virtual tunnel device to create tunnel. The IPsec stack builds the outer IP header during IPsec processing by itself. IPSec Best practices Best practices IPSEC in transport mode has some serious advantages over other solutions. Compared to other technologies, IPSEC is built into to the Linux kernel. In other words there is nodaemonrunning in the background. Better yet, IPSEC does not require port-forwarding; some people elect to useSSH, stunnel, and other technologies that rely onport forwarding. With IPSEC, you simply have to run a program and its configuration file. After running it,encryptionbetween hosts is mandatory. Connections will be refused if the other connection does not have the appropriate keys. Groups of computers can share the same key, and it can even be done on a per-port setting (for example securing VNC, etc). Downsides? IPSEC in transport mode does have a couple draw backs. In transport mode you cannot have any dynamic setups where the IP addresses change from time to time. In other words, IPSEC is usually insufficient for workstation environments or dynamically assigned networks. Also, if you want to do a per-port setup the configuration becomes harder. Security Implications A very astute user can use IPSEC to bypass firewalls and other security measures. Since IPSEC uses cryptography, information is passed between machines in encrypted format. If the keys are not known, there is no practical way to decrypt the information (it is virtual impossible due to the sheer amount of time it would take). Machine-to-Machine IPSEC installations should be considered as Virtual Private Networks (VPNs) for security considerations. Please check with yoursystem administrator, business policies, and laws and regulations of your locality in order to establish whether or not to institute IPSEC. Requirements ipsec-tools package static IP addresses for each machine Configuration file The configuration file, /etc/setkey.conf, contains the information about the IPSECpolicy. Below is a sampleconfiguration policy(i.e. dont implement this policy because it is insecure). These lines are the actual keys and the encryption that will be used. The first block has the keys that will be used for authentication. In this case, it is the hmac-md5algorithm. The second block contains the keys that will be used for privacy, and the method of encryption. In the example, AES-CBC will be used, which is probably stronger than should be required; the key that we will be using is 194bits, meaning that it is good enough for US Government Secret and below classifications. The final block includes the actual policy. This is where you can put port numbers and even define whether it will be TCP orUDP. Generating the keys The more random the key, the better. Obviously, the example above is insufficient to secure a network. The following command will generate a random key. While running this command, youll need to wiggle the mouse to make it run faster. Or, if you are using a terminal use/dev/urandom instead. dd if=/dev/random count=16 bs=1| xxd -ps Depending on the size of the key that you want, adjust the count (16 will produce a 128 bit key, 24 will produce a 196 bit key, and 32 will produce a 512 bit key) The size of the key is important. If you really paranoid or just haveCPUcycles to