IP SECURITY
Introduction
IPsec (IP security) is a standardized framework for securing Internet Protocol (IP)
communication...
mechanisms for security, such as authentication or encryption. As usage of the Internet
and TCP/IP protocols increases, th...
A TCP connection is identified by the 4-tuple ((destination-ip-address,
destination-port), (source-ip-address, source-port...
End Host Implementation
Putting IPSec into all host devices provides the most flexibility and
security. It enables “end-to...
IPsec is implemented by a set of cryptographic protocols for (1) securing packet flows
and (2) Internet key exchange. Of t...
It is unusual to see any product that offers RFC1825–1829 support. "ESP" generally
refers to 2406, while ESPbis refers to ...
Technical details
Authentication Header (AH)
One of the two core security protocols in IPSec is the Authentication
Header ...
presence of the AH header allows us to verify the integrity of the message, but doesn't
encrypt it. Thus, AH provides auth...
Authentication Data
Contains the data necessary to authenticate the packet.
Encapsulated Security Payload (ESP)
The Encaps...
An ESP packet diagram:
0 1 2 3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
Security Parameters Index (...
Authentication Data
Contains the data used to authenticate the packet.
Implementations
IPsec support is usually implemente...
project, racoon from the KAME project or without any ISAKMP/IKE daemon (using
manual keying).
There are a number of implem...
To accomplish this, they must perform (at least) the following tasks:
1. They must agree on a set of security protocols to...
IKE Overview and Relationship to Other Key Exchange Methods
The purpose of IKE is to allow devices to exchange information...
Conclusion
IPsec (IP security) is a standardized framework for securing Internet Protocol (IP)
communications by encryptin...
Upcoming SlideShare
Loading in …5
×

Ip sec

615 views

Published on

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
615
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
14
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Ip sec

  1. 1. IP SECURITY Introduction IPsec (IP security) is a standardized framework for securing Internet Protocol (IP) communications by encrypting and/or authenticating each IP packet in data stream. IPsec supports two encryption modes: Transport and Tunnel. Transport mode encrypts only the data portion (payload) of each packet, but leaves the header untouched. The more secure Tunnel mode encrypts both the header and the payload. On the receiving side, an IPSec- compliant device decrypts each packet. For IPsec to work, the sending and receiving devices must share a public key. This is accomplished through a protocol known as Internet Security Association and Key Management Protocol/Oakley (ISAKMP/Oakley), which allows the receiver to obtain a public key and authenticate the sender using digital certificates. In the early 1980's, specifications were finished for the TCP and IP protocols. These two protocols could be considered the most important in the world today - they are the basis of the Internet. Over the past decade, the Internet has grown from a small network connecting a small community of researchers to its present state - a gigantic global network connecting people of all types. The huge success of the Internet has, for the most part, been quite beneficial. The Internet has evolved from a specialized project to a general-purpose tool. TCP and IP protocols were designed when the Internet was small, and users generally trusted each other. The protocols lack many features that are desirable or needed on an insecure network. However, the growth of the Internet has created problems with security. The TCP and IP protocols were designed when the Internet was small, and users generally trusted each other. The protocols lack many features that are desirable or needed on an insecure network. TCP/IP is the backbone of the internet today. Comprised of two protocols, TCP and IP, the TCP/IP protocol suite is one of the most widely used. The TCP/IP protocols, the basis for today's Internet, lack even the most basic
  2. 2. mechanisms for security, such as authentication or encryption. As usage of the Internet and TCP/IP protocols increases, their lack of built-in security has become more and more problematic. Internet Protocol The Internet Protocol (or IP as it generally known), is the network layer of the Internet. IP provides a connection-less service. The job of IP is to route and send a packet to the packet's destination. IP provides no guarantee whatever, for the packets it tries to deliver. The IP packets are usually termed datagrams. The datagrams go through a series of routers before they reach the destination. At each node that the datagram passes through, the node determines the next hop for the datagram and routes it to the next hop. Since the network is dynamic, it is possible that two datagrams from the same source take different paths to make it to the destination. Since the network has variable delays, it is not guaranteed that the datagrams will be received in sequence. IP only tries for a best- effort delivery. It does not take care of lost packets; this is left to the higher layer protocols. There is no state maintained between two datagrams; in other words, IP is connection-less. Transmission Control Protocol Transmission Control Protocol (TCP) runs on top of IP, and provides a connection oriented service between the sender and the receiver. TCP provides guaranteed delivery, and ensures that the packets are delivered in sequence. The underlying network IP, is highly unreliable and does not provide any guarantee for TCP. In order to provide reliability between the sender and the receiver, TCP uses various mechanisms, such as sequence numbers, acknowledgments, 3-way handshakes and timers.
  3. 3. A TCP connection is identified by the 4-tuple ((destination-ip-address, destination-port), (source-ip-address, source-port)). Ports are the actual end-points of the TCP connection. The working of TCP could be described using a TCP state machine. Transitions to different states are based on events received in the form of TCP segments. The TCP states are very closely associated with timers. There are various timers associated with connection establishment (or termination), flow control, and retransmission. In order to understand the security problems associated with TCP, it is necessary that we look at the state-machine in detail. It is also important to get an overview of TCP implementations, and how they implement the TCP state-machine, the state-transitions and the associated timers. The TCP layer on either end maintains table entries corresponding to the 4-tuple (remote-ip-address, remote-port, source-ip-address, source-port). This 4-tuple uniquely identifies a connection. For every connection, the end-systems implementing TCP need to keep the TCP state information for the duration of the connection. IPSec Implementation Methods Three different implementation architectures are defined for IPSec in RFC 2401. Which one we use depends on various factors including the version of IP used, the requirements of the application and other factors. These in turn rest on a primary implementation decision: whether IPSec should be programmed into all hosts on a network, or just into certain routers or other “intermediate devices”. This implementation decision is one that must be based on the requirements of the network. There are two options: to implement IPSec in end hosts, or in routers.
  4. 4. End Host Implementation Putting IPSec into all host devices provides the most flexibility and security. It enables “end-to-end” security between any two devices on the network. However, there are many hosts on a typical network, so this means far more work than just implementing IPSec in routers. Router Implementation This option is much less work because it means we only make changes to a few routers instead of hundreds or thousands of clients. It only provides protection between pairs of routers that implement IPSec, but this may be sufficient for certain applications such as virtual private networks (VPNs). The routers can be used to provide protection only for the portion of the route that datagrams take outside the organization, leaving connections between routers and local hosts unsecured (or possibly, secured by other means). Modes of IPsec operation There are two modes of IPsec operation: transport mode and tunnel mode. In transport mode only the payload (message) of the IP packet is encrypted. It is fully-routable since the IP header is sent as plain text; however, it can not cross NAT interfaces, as this will invalidate its hash value. Transport mode is used for host-to-host communications over a LAN. In tunnel mode, the entire IP packet is encrypted. It must then be encapsulated into a new IP packet for routing to work. Tunnel mode is used for network-to-network communications (secure tunnels between routers) or host-to-network and host-to-host communications over the Internet.
  5. 5. IPsec is implemented by a set of cryptographic protocols for (1) securing packet flows and (2) Internet key exchange. Of the former, there are two: Authentication Header (AH) :which provides authentication, payload (message) and IP header integrity and with some cryptography algorithm also non-repudiation , but does not offer confidentiality Encapsulating Security Payload (ESP) :which provides data confidentiality, payload (message) integrity and with some cryptography algorithm also authentication. In some countries message encryption is prohibited by law and ESP protocol can not be used. In this case AH provides entire IPsec functionality without confidentiality. Originally AH was only used for integrity and ESP was used only for encryption; authentication functionality was added subsequently to ESP. Currently only one key exchange protocol is defined, the IKE (Internet Key Exchange) protocol. IPsec protocols operate at the network layer, layer 3 of the OSI model. Other Internet security protocols in widespread use, such as SSL and TLS, operate from the transport layer up (OSI layers 4 - 7). This makes IPsec more flexible, as it can be used for protecting both TCP and UDP-based protocols, but increases its complexity and processing overhead, as it cannot rely on TCP (layer 4 OSI model) to manage reliability and fragmentation. Current status as a standard IPsec is an obligatory part of IPv6, and is optional for use with IPv4. While the standard is designed to be agnostic to IP versions, current widespread deployment and experience concerns IPv4 implementations. IPsec protocols were originally defined by RFCs 1825–1829, published in 1995. In 1998, these documents were obsoleted by RFCs 2401–2412. 2401–2412 are not compatible with 1825–1829, although they are conceptually identical. In December 2005 a third generation documents RFCs 4301– 4309, were produced. They are largely a superset of 2401–2412.
  6. 6. It is unusual to see any product that offers RFC1825–1829 support. "ESP" generally refers to 2406, while ESPbis refers to 4303. Design intent IPsec was intended to provide either transport mode: end-to-end security of packet traffic in which the end-point computers do the security processing, or tunnel mode: portal-to-portal communications security in which security of packet traffic is provided to several machines even to whole LANs by a single node. IPsec can be used to create Virtual Private Networks (VPN) in either mode, and this is the dominant use. Note, however, that the security implications are quite different between the two operational modes. End-to-end communication security on an Internet-wide scale has been slower to develop than many had expected. Part of the reason is that no universal, or universally trusted, Public Key Infrastructure (PKI) has emerged (DNSSEC was originally envisioned for this); part is that many users understand neither their needs nor the available options well enough to promote inclusion in vendors' products. Since the Internet Protocol does not inherently provide any security capabilities, IPsec was introduced to provide security services such as: 1. Encrypting traffic (So it can not be read in its transmission) 2. Integrity validation (Ensuring traffic has not been modified along its path) 3. Authenticating the Peers (Both ends are sure they are communicating with a trusted entity the traffic is intended for) 4. Anti-Replay (Protect against session replay)
  7. 7. Technical details Authentication Header (AH) One of the two core security protocols in IPSec is the Authentication Header (AH). This is another protocol whose name has been well chosen: AH is a protocol that provides authentication of either all or part of the contents of a datagram through the addition of a header that is calculated based on the values in the datagram. What parts of the datagram are used for the calculation, and the placement of the header, depends on the mode (tunnel or transport) and the version of IP (IPv4 or IPv6). The operation of the AH protocol is surprisingly simple—especially for any protocol that has anything to do with network security. It can be considered analogous to the algorithms used to calculate checksums or perform CRC checks for error detection. In those cases, a standard algorithm is used by the sender to compute a checksum or CRC code based on the contents of a message. This computed result is transmitted along with the original data to the destination, which repeats the calculation and discards the message if any discrepancy is found between its calculation and the one done by the source. This is the same idea behind AH, except that instead of using a simple algorithm known to everyone, we use a special hashing algorithm and a specific key known only to the source and the destination. A security association between two devices is set up that specifies these particulars so that the source and destination know how to perform the computation but nobody else can. On the source device, AH performs the computation and puts the result (called the Integrity Check Value or ICV) into a special header with other fields for transmission. The destination device does the same calculation using the key the two devices share, which enables it to see immediately if any of the fields in the original datagram were modified (either due to error or malice). It's important that I point out explicitly that just as a checksum doesn't change the original data, neither does the ICV calculation change the original data. The
  8. 8. presence of the AH header allows us to verify the integrity of the message, but doesn't encrypt it. Thus, AH provides authentication but not privacy. An AH packet diagram: 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 Next Header Payload Length RESERVED Security Parameters Index (SPI) Sequence Number Authentication Data (variable) Field meanings: Next Header Identifies the protocol of the transferred data. Payload Length Size of AH packet. RESERVED Reserved for future use (all zero until then). Security Parameters Index (SPI) Identifies the security parameters in combination with IP address. Sequence Number A monotonically increasing number, used to prevent replay attacks.
  9. 9. Authentication Data Contains the data necessary to authenticate the packet. Encapsulated Security Payload (ESP) The Encapsulating Security Payload (ESP) extension header provides origin authenticity, integrity, and confidentiality of a packet. Unlike the AH header, the IP packet header is not accounted for. ESP operates directly on top of IP using IP protocol number 50. The IPSec Authentication Header (AH) provides integrity authentication services to IPSec-capable devices, so they can verify that messages are received intact from other devices. For many applications, however, this is only one piece of the puzzle. We want to not only protect against intermediate devices changing our datagrams, we want to protect against them examining their contents as well. For this level of private communication, AH is not enough; we need to use the Encapsulating Security Payload (ESP) protocol. The main job of ESP is to provide the privacy we seek for IP datagrams by encrypting them. An encryption algorithm combines the data in the datagram with a key to transform it into an encrypted form. This is then repackaged using a special format that we will see shortly, and transmitted to the destination, which decrypts it using the same algorithm. ESP also supports its own authentication scheme like that used in AH, or can be used in conjunction with AH. ESP has several fields that are the same as those used in AH, but packages its fields in a very different way
  10. 10. An ESP packet diagram: 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 Security Parameters Index (SPI) Sequence Number Payload * (variable) Padding (0-255 bytes) Pad Length Next Header Authentication Data (variable) Field meanings: Security Parameters Index (SPI) Identifies the security parameters in combination with IP address Sequence Number A monotonically increasing number, used to prevent replay attacks. Payload Data The data to be transferred. Padding Used with some block ciphers to pad the data to the full length of a block. Pad Length Size of padding in bytes. Next Header Identifies the protocol of the transferred data.
  11. 11. Authentication Data Contains the data used to authenticate the packet. Implementations IPsec support is usually implemented in the kernel with key management and ISAKMP/IKE negotiation carried out from user-space. Existing IPsec implementations tend to include both of these functionalities. However, as there is a standard interface for key management, it is possible to control one kernel IPsec stack using key management tools from a different implementation. Because of this, there is confusion as to the origins of the IPsec implementation that is in the Linux kernel. The FreeS/WAN project made the first complete and open source implementation of IPsec for Linux. It consists of a kernel IPsec stack (KLIPS), as well as a key management daemon (pluto) and many shell scripts. The FreeS/WAN project was disbanded in March 2004. Openswan and strongSwan are continuations of FreeS/WAN. The KAME project also implemented complete IPsec support for NetBSD, FreeBSD. Its key management daemon is called racoon. OpenBSD made its own ISAKMP/IKE daemon, simply named isakmpd (that was also ported to other systems, including Linux). However, none of these kernel IPsec stacks were integrated into the Linux kernel. Alexey Kuznetsov and David S. Miller wrote a kernel IPsec implementation from scratch for the Linux kernel around the end of 2002. This stack was subsequently released as part of Linux 2.6, and is referred variously as "native" or "NETKEY". Therefore, contrary to popular belief, the Linux IPsec stack did not originate from the KAME project. As it supports the standard PF_KEY protocol (RFC 2367) and the native XFRM interface for key management, the Linux IPsec stack can be used in conjunction with either pluto from Openswan/strongSwan, isakmpd from OpenBSD
  12. 12. project, racoon from the KAME project or without any ISAKMP/IKE daemon (using manual keying). There are a number of implementations of IPsec and ISAKMP/IKE protocols. These include: 1. NRL IPsec, one of the original sources of IPsec code 2. OpenBSD, with its own code derived from NRL IPsec 3. the KAME stack, that is included in Mac OS X, NetBSD and FreeBSD 4. "IPsec" in Cisco IOS Software 5. "IPsec" in Microsoft Windows, including Windows XP, Windows 2000, and Windows 2003 6. SSH Sentinel provides toolkits 7. IPsec in Solaris 8. IBM AIX operating system 9. IBM z/OS 10. IPsec and IKE in HP-UX (HP-UX IPSec) 11. "IPsec and IKE" in VxWorks IPSec General Operation, Components and Protocols IPSec provides the tools that devices on a TCP/IP network need in order to communicate securely. When two devices (either end user hosts or intermediate devices such as routers or firewalls) want to engage in secure communications, they set up a secure path between themselves that may traverse across many insecure intermediate systems.
  13. 13. To accomplish this, they must perform (at least) the following tasks: 1. They must agree on a set of security protocols to use, so that each one sends data in a format the other can understand. 2. They must decide on a specific encryption algorithm to use in encoding data. 3. They must exchange keys that are used to “unlock” data that has been cryptographically encoded. 4. Once this background work is completed, each device must use the protocols, methods and keys previously agreed upon to encode data and send it across the network. IPSec Key Exchange (IKE) IPSec, like many secure networking protocol sets, is based on the concept of a “shared secret”. Two devices that want to send information securely encode and decode it using a piece of information that only they know. Anyone who isn't “in” on the secret is able to intercept the information but is prevented either from reading it (if ESP is used to encrypt the payload) or from tampering with it undetected (if AH is used). Before either AH or ESP can be used, however, it is necessary for the two devices to exchange the “secret” that the security protocols themselves will use. The primary support protocol used for this purpose in IPSec is called Internet Key Exchange (IKE). IKE is defined in RFC 2409, and is one of the more complicated of the IPSec protocols to comprehend. In fact, it is simply impossible to truly understand more than a real simplification of its operation without significant background in cryptography.
  14. 14. IKE Overview and Relationship to Other Key Exchange Methods The purpose of IKE is to allow devices to exchange information required for secure communication. As the title suggests, this includes cryptographic keys used for encoding authentication information and performing payload encryption. IKE works by allowing IPSec-capable devices to exchange security associations (SAs), to populate their security association databases (SADs). These are then used for the actual exchange of secured datagrams with the AH and ESP protocols. IKE is considered a “hybrid” protocol because it combines (and supplements) the functions of three other protocols. The first of these is the Internet Security Association and Key Management Protocol (ISAKMP). This protocol provides a framework for exchanging encryption keys and security association information. It operates by allowing security associations to be negotiated through a series of phases. ISAKMP is a generic protocol that supports many different key exchange methods. In IKE, the ISAKMP framework is used as the basis for a specific key exchange method that combines features from two key exchange protocols: (1) OAKLEY: Describes a specific mechanism for exchanging keys through the definition of various key exchange “modes”. Most of the IKE key exchange process is based on OAKLEY. (2) SKEME: Describes a different key exchange mechanism than OAKLEY. IKE uses some features from SKEME, including its method of public key encryption and its fast re-keying feature.
  15. 15. Conclusion IPsec (IP security) is a standardized framework for securing Internet Protocol (IP) communications by encrypting and/or authenticating each IP packet in data stream. IPsec supports two encryption modes: Transport and Tunnel. Transport mode encrypts only the data portion (payload) of each packet, but leaves the header untouched. The more secure Tunnel mode encrypts both the header and the payload. On the receiving side, an IPSec- compliant device decrypts each packet. IPsec was intended to provide either transport mode: end-to-end security of packet traffic in which the end-point computers do the security processing, or tunnel mode: portal-to-portal communications security in which security of packet traffic is provided to several machines even to whole LANs by a single node.

×