IP Security

The IP security (IPSec) is an Internet Engineering Task Force (IETF) standard suite of protocols between 2 communication points across the IP network that provide data authentication, integrity, and confidentiality. It also defines the encrypted, decrypted and authenticated packets. The protocols needed for secure key exchange and key management are defined in it.

Uses of IP Security –
IPsec can be used to do the following things:

• To encrypt application layer data.
• To provide security for routers sending routing data across the public internet.
• To provide authentication without encryption, like to authenticate that the data originates from a known sender.
• To protect network data by setting up circuits using IPsec tunneling in which all data is being sent between the two endpoints is encrypted, as with a Virtual Private Network(VPN) connection.
• Any scheme that is developed for providing network security needs to be implemented at some layer in protocol stack as depicted in the diagram below −

  Layer	Communication Protocols	Security Protocols
  Application Layer	HTTP FTP SMTP	PGP. S/MIME, HTTPS
  Transport Layer	TCP /UDP	SSL, TLS, SSH
  Network Layer	IP	IPsec

  The popular framework developed for ensuring security at network layer is Internet Protocol Security (IPsec).

Virtual Private Network

Ideally, any institution would want its own private network for communication to ensure security. However, it may be very costly to establish and maintain such private network over geographically dispersed area. It would require to manage complex infrastructure of communication links, routers, DNS, etc.

IPsec provides an easy mechanism for implementing Virtual Private Network (VPN) for such institutions. VPN technology allows institution’s inter-office traffic to be sent over public Internet by encrypting traffic before entering the public Internet and logically separating it from other traffic. 

The simplified working of VPN is shown in the following diagram −

IP Security Architecture

Overview of IPsec

IPsec is a framework/suite of protocols for providing security at the IP layer.

Origin

In early 1990s, Internet was used by few institutions, mostly for academic purposes. But in later decades, the growth of Internet became exponential due to expansion of network and several organizations using it for communication and other purposes.

With the massive growth of Internet, combined with the inherent security weaknesses of the TCP/IP protocol, the need was felt for a technology that can provide network security on the Internet. A report entitled "Security in the Internet Architecture” was issued by the Internet Architecture Board (IAB) in 1994. It identified the key areas for security mechanisms.

The IAB included authentication and encryption as essential security features in the IPv6, the next-generation IP. Fortunately, these security capabilities were defined such that they can be implemented with both the current IPv4 and futuristic IPv6.

Security framework, IPsec has been defined in several ‘Requests for comments’ (RFCs). Some RFCs specify some portions of the protocol, while others address the solution as a whole.

Operations Within IPsec

The IPsec suite can be considered to have two separate operations, when performed in unison, providing a complete set of security services. These two operations are IPsec Communication and Internet Key Exchange.

• IPsec Communication
  • It is typically associated with standard IPsec functionality. It involves encapsulation, encryption, and hashing the IP datagrams and handling all packet processes.
  • It is responsible for managing the communication according to the available Security Associations (SAs) established between communicating parties.
  • It uses security protocols such as Authentication Header (AH) and Encapsulated SP (ESP).
  • IPsec communication is not involved in the creation of keys or their management.
  • IPsec communication operation itself is commonly referred to as IPsec.
• Internet Key Exchange (IKE)
  • IKE is the automatic key management protocol used for IPsec.
  • Technically, key management is not essential for IPsec communication and the keys can be manually managed. However, manual key management is not desirable for large networks.
  • IKE is responsible for creation of keys for IPsec and providing authentication during key establishment process. Though, IPsec can be used for any other key management protocols, IKE is used by default.
  • IKE can be used with already defined key management framework Internet Security Association Key Management Protocol (ISAKMP).
  • ISAKMP is not IPsec specific, but provides the framework for creating SAs for any protocol.

This chapter mainly discusses the IPsec communication and associated protocol employed to achieve security.

IPsec Communication Modes

IPsec Communication has two modes of functioning; transport and tunnel modes. These modes can be used in combination or used individually depending upon the type of communication desired.

Transport Mode

• IPsec does not encapsulate a packet received from upper layer.
• The original IP header is maintained and the data is forwarded based on the original attributes set by the upper layer protocol.
• The following diagram shows the data flow in the protocol stack.

• The limitation of transport mode is that no gateway services can be provided. It is reserved for point-to-point communications as depicted in the following image.

Tunnel Mode

• This mode of IPsec provides encapsulation services along with other security services.
• In tunnel mode operations, the entire packet from upper layer is encapsulated before applying security protocol. New IP header is added.
• The following diagram shows the data flow in the protocol stack.

• Tunnel mode is typically associated with gateway activities. The encapsulation provides the ability to send several sessions through a single gateway.
• The typical tunnel mode communication is as depicted in the following diagram.

• As far as the endpoints are concerned, they have a direct transport layer connection. The datagram from one system forwarded to the gateway is encapsulated and then forwarded to the remote gateway. The remote associated gateway de-encapsulates the data and forwards it to the destination endpoint on the internal network.
• Using IPsec, the tunneling mode can be established between the gateway and individual end system as well.

IPsec Protocols

IPsec uses the security protocols to provide desired security services. These protocols are the heart of IPsec operations and everything else is designed to support these protocol in IPsec.

Security associations between the communicating entities are established and maintained by the security protocol used.

There are two security protocols defined by IPsec — Authentication Header (AH) and Encapsulating Security Payload (ESP).

Authentication Header

The AH protocol provides service of data integrity and origin authentication. It optionally caters for message replay resistance. However, it does not provide any form of confidentiality.

AH is a protocol that provides authentication of either all or part of the contents of a datagram by the addition of a header. The header is calculated based on the values in the datagram. What parts of the datagram are used for the calculation, and where to place the header, depends on the mode cooperation (tunnel or transport).

The operation of the AH protocol is surprisingly simple. It can be considered similar to the algorithms used to calculate checksums or perform CRC checks for error detection.

The concept behind AH is the same, except that instead of using a simple algorithm, AH uses special hashing algorithm and a secret key known only to the communicating parties. A security association between two devices is set up that specifies these particulars.

Encapsulation Security Protocol (ESP)

ESP provides security services such as confidentiality, integrity, origin authentication, and optional replay resistance. The set of services provided depends on options selected at the time of Security Association (SA) establishment.

In ESP, algorithms used for encryption and generating authenticator are determined by the attributes used to create the SA.

Security Associations in IPsec

Security Association (SA) is the foundation of an IPsec communication. The features of SA are −

• Before sending data, a virtual connection is established between the sending entity and the receiving entity, called “Security Association (SA)”.
• IPsec provides many options for performing network encryption and authentication. Each IPsec connection can provide encryption, integrity, authenticity, or all three services. When the security service is determined, the two IPsec peer entities must determine exactly which algorithms to use (for example, DES or 3DES for encryption; MD5 or SHA-1 for integrity). After deciding on the algorithms, the two devices must share session keys.
• SA is a set of above communication parameters that provides a relationship between two or more systems to build an IPsec session.
• SA is simple in nature and hence two SAs are required for bi-directional communications.
• SAs are identified by a Security Parameter Index (SPI) number that exists in the security protocol header.
• Both sending and receiving entities maintain state information about the SA. It is similar to TCP endpoints which also maintain state information. IPsec is connection-oriented like TCP.

Parameters of SA

Any SA is uniquely identified by the following three parameters −

• Security Parameters Index (SPI).
  • It is a 32-bit value assigned to SA. It is used to distinguish among different SAs terminating at the same destination and using the same IPsec protocol.
  • Every packet of IPsec carries a header containing SPI field. The SPI is provided to map the incoming packet to an SA.
  • The SPI is a random number generated by the sender to identify the SA to the recipient.
• Destination IP Address − It can be IP address of end router.
• Security Protocol Identifier − It indicates whether the association is an AH or ESP SA.

Example of SA between two router involved in IPsec communication is shown in the following diagram.

• 
  

Virtual Private Network

Virtual private network technology is based on the concept of tunneling. Just like a water pipe contains the liquid flowing inside of it, a VPN tunnel insulates and encapsulates internet traffic—usually with some type of encryption—to create a private tunnel of data as it flows inside an unsecured network.

As your internet traffic flows inside the VPN tunnel, it provides a secure, private connection between your computer and a different computer or server at another site. When paired with strong encryption, tunneling makes it virtually impossible for your data to viewed or hacked by others.

How Does VPN Tunneling Work?

It helps to think of VPN tunneling as a two-fold process of data encapsulation and data encryption.

• Data encapsulation: Encapsulation is the process of wrapping an internet data packet inside of another packet. You can think of this as the outer tunnel structure, like putting a letter inside of an envelope for sending.
• Data encryption: However, just having a tunnel isn't enough. Encryption scrambles and locks the contents of the letter, i.e. your data, so that it can't be open and read by anyone except the intended receiver.

While a VPN tunnel can be created without encryption, VPN tunnels are not generally considered secure unless they're protected with some type of encryption. 

Several encryption protocols have been created specifically for use with VPN tunnels. The most common types of VPN encryption protocols include IPSec, PPTP,  OpenVPN etc.

Network Based Intrusion Detection System

Network-based intrusion detection systems offer a different approach. “These systems collect information from the network itself,”  rather than from each separate host. They operate essentially based on a “wiretapping concept,” information is collected from the network traffic stream, as data travels on the network segment . The intrusion detection system checks for attacks or irregular behavior by inspecting the contents and header information of all the packets moving across the network. The network sensors come equipped with “attack signatures” that are rules on what will constitute an attack  and most network-based systems allow advanced users to define their own signatures. This offers a way to customize the sensors based on an individual network’s needs and types of usage. The sensors then compare these signatures to the traffic that they capture, this method is also known as packet sniffing  and allows the sensor to identify hostile traffic.
Network-based systems are also extremely portable. They only monitor traffic over a specific network segment, and are independent of the operating systems that they are installed on. “Deployed network-based intrusion detection sensors will listen for all attacks, regardless of the destination operating system type”. This offers more options for businesses that run specialized software or software they have developed inhouse, which will become increasingly attractive as the newer UNIX-based operating systems continue to increase in popularity. Adding to their convenience, network-based sensors can be inserted easily on part of a network and data can be collected with minimal work. In many cases, all that is required to collect information for analysis is the configuration of a network card . This is beneficial in situations where network topology changes or where system resources have been moved, the intrusion detection system monitors can be moved and used as needed.
However, network-based solutions have their share of problems. As discussed earlier, the sensors spot attacks based on their attack signatures. These signatures are written based on data collected from known and previous attacks, and this unfortunately ensures that these signatures “will always be a step behind the latest underground exploits”.
The second major issue with network-based intrusion detection approaches is scalability. Network monitors must inspect every packet that is passed through the segment they are placed on. It has been demonstrated that network-based systems have difficulty keeping up on 100 Mbps environments , they simply can’t handle it.
Encryption and switching represent two further limitations of network-based approaches. First, if network traffic is encrypted, an agent cannot scan the protocols or the content of these packets . Second, the nature of switches makes network monitoring extremely difficult. 

Host based intrusion detection system

Host-based intrusion detection systems are aimed at collecting information about activity on a particular single system, or host. These host-based agents, which are sometimes referred to as sensors, would typically be installed on a machine that is deemed to be susceptible to possible attacks. The term “host” refers to an individual computer, thus a separate sensor would be needed for every machine. Sensors work by collecting data about events taking place on the system being monitored. This data is recorded by operating system mechanisms called audit trails .
Other sources from which a host-based sensor can obtain data, “include system logs, other logs generated by operating system processes, and contents of objects not reflected in standard operating system audit and logging mechanisms” . These logs are for the most part simple text files, which are written a few lines at a time, as events occur and operations on a system take place. As host-based systems rely heavily on audit trails, they become limited by these audit trails, which are not provided by the manufacturers who design the intrusion detection system itself. As a result, theses trails may not necessarily support the needs of the intrusion detection system, leading some to conclude that having more effective hostbased systems, “may require the developer to amend the operating system kernel code to generate event information. This approach extracts a cost in performance, which might be unacceptable for customers running computationally greedy applications” . Despite this limitation, audit trails are still considered to be the source of choice for host-based intrusion detection information.
 A common criticism of host-based systems lies with the amount of data they can offer. The configuration of the sensors must obviously collect detailed enough information to identify abnormalities on a host, so the more refined the data captured, the better the sensor should work. The problem is that, as the sensors gather finer levels of detail, they accumulate large amounts of data that take up significant storage . In addition, because, “both the volume and complexity of the data rise with greater detail … it makes it difficult for an adversary to circumvent the audit process entirely, the greater volume and complexity of the data make it easier in practice for intruders to hide their footprints”
Host-based intrusion detection systems are desirable for several reasons. As briefly mentioned above, because host-based systems can monitor access to information in terms of “who accessed what,” these systems can trace malicious or improper activities to a specific user ID.
Host-based sensors are also useful in that they can keep track of the behavior of individual users . This can help catch attacks while they are happening or possibly stop a potential attack before it affect the system.