IPsec

 IPSec is a bundle of protocols and algorithms defining a flexible framework in which it is the user who selects the actual parameters of the algorithms and methods to be used. As a result, one should assume that two IPSec implementation instances are not necessarily identical.

IPsec is defined in RFC 2401 to 2411 and 2451.

 In a communications network, security has a few different aspects, the most important being:

Authentication	Making sure that the data received is indeed coming from the expected partner (avoiding unauthorized sources to transmit data to a station)
Integrity	Making sure that the data received is indeed what was transmitted by the source (avoiding modifications to the data by unknown parties, executed while the data traveled from source to destination)
Rejection of replayed data	Making sure that receivers identify and discard packets that have been already received (avoiding multiple executions of same command, generated by unknown parties)
Confidentiality	Making sure that nobody “listens and understands” the data on its way from source to destination

 IPsec addresses all the above services and defines the necessary tools for their provision.

The basic idea of IPsec is to “mark” packets before being injected into the communications network, and use this “mark” at the receiving side in order to decide whether the packet arrived from the correct source (authentication), whether the packet content is exactly the one generated by the source, without any modifications (integrity) and whether the packet is not a replay of one of the previous packets, already received (rejection of replayed data).

In addition, IPsec also defines a framework for data encryption ensuring that potential “listeners” in the network would not be able to understand the information carried in the packet (confidentiality).

The “marking” process results in new fields being added to the packet to be protected.

The "marking" of the packets before their transmission may be executed by:

- the user computer (client), or by

- the ingress edge router (the first router met by the transmitted packet, the router connecting the user to the communications network)

When the user computer is the one marking the transmitted packets, it is said that IPsec is used in “transport mode”.

When the ingress router is doing the job on behalf of the user (acting as a proxy IPsec entity), it is said that IPsec is used in “tunnel mode”.

Authentication / Integrity Check Principles

Authentication and integrity check processes are based on the addition to the packet to be protected of an Integrity Check Value (ICV) field allowing the receiving party to be sure that:

a.- The packet was indeed sent by the expected partner (authentication)

b.- The packet has not been modified (tampered with) during its trip through the network (integrity check)

Generating and Using the ICV

Observations:

1.- Messages encrypted with a specific key can be correctly decoded ONLY by using the same key.

2.- A decoding process using a specific key, applied to a message encrypted with a different key, results in a message different than the original one.

Generic Authentication Process  Transmission

ICV is the result of two consecutive processes executed to the packet to be protected.

- step 1 - A hash value is calculated for the packet to be protected.

- step 2 - The hash value obtained in step 1 is encrypted using a secret key, generating the ICV value to be added to the packet.

IP Sec Marking Location and Protection Areas

Depending on the specific IP Sec protocol used, and the selected mode (transport or tunnel), IP Sec marking appears in different locations in the protected packet.

When authentication is used, the marking protects the whole packet.

When confidentiality marking is used, the transport and tunnel mode provide different types of services.

In transport mode the encryption process is executed by the end station, and routers in the network are expected to route the encrypted packet toward its destination.

As a result, the encrypting station cannot encrypt the IP header, as it includes the vital information needed by routers for correct operation. The only part that can be protected in this case is the payload itself (the upper layers).

In tunnel mode the encryption process is executed by the ingress router, and the resulting packet is sent via the network to another router (the other end of the tunnel) as indicated in a NEW IP header, added by the ingress router.

As a result, the ingress router can encrypt the whole original packet (payload and original IP addresses). Both authentication and confidentiality services are based on packet marking executed at transmission site, followed by decoding executed at the receiving site.

Security Associations (SA)

Obviously, the receiving party should be aware of the marking executed by the transmitting party. The two parties, have to enter into a logical relationship, known as a “Security Association (SA)”, where the actual parameters regarding the algorithms and keys to be used are agreed.

Security Associations are unidirectional.

In a bi-directional link in which both directions have to be protected by IPsec, there will be two Security Associations: A-to-B and B-to-A.

Security Associations are uniquely identified by fields present in the protected packet, allowing the receiving party to associate a received packet to a specific Security Association and (as a result) to activate the correct algorithms for its processing.

IPSec consists of 3 major parts:

1.- AH - Authentication Header protocol (RFC 2402): Provides marking for authentication, integrity and replay protection

2.- ESP - Encapsulating Security Payload (RFC 2406): Provides marking for authentication, integrity and replay protection as well as for confidentiality. As both authentication and encryption algorithms imply the use of encryption keys, one more element is needed; a protocol to handle the encryption key selection and other administrative issues related to the creation and maintenance of a Security Association between nodes.

3.- IKE - Internet Key Exchange (RFC 2409) : Establishes and maintains Security Associations.

AH - Authentication Header protocol (RFC 2402)

- Next header - type of next payload

- Payload length

- SPI - Arbitrary value that, together with the IP DA of the packet, identifies the actual Security Association (SA) to which the packet belongs.

- Stations identify the SA to be used for the processing of an incoming packet, based on:

- IP DA

- SPI

- security service (as indicated by the "protocol” value in the field preceding the security header – AH or ESP)

- Sequence number - avoids replay of the packet

- Authentication data - includes Integrity Check Value (ICV), used to authenticate the packet

ESP - Encapsulating Security Payload (RFC 2406)

- SPI - Arbitrary value that, together with the IP DA of the packet, identifies the actual Security Association (SA) to which the packet belongs.

- Stations identify the SA to be used for the processing of an incoming packet, based on:

- IP DA

- SPI

- security service (as indicated by the ‘protocol” value in the field preceding the security header - AH or ESP)

- Sequence number - avoids replay of the packet .

- Pad length

- Next header - type of payload in the packet .

- Authentication data - includes Integrity Check Value (ICV), used to authenticate the packet.

IKE - Internet Key Exchange protocol (RFC 2409)

The purpose of the IKE protocol is to negotiate the protection parameters (protocols, keys, keys life time, etc.) to be used by the partners.

IKE is a protocol built as a combination of

- ISAKMP (Internet Security Association and Key Management Protocol) defined by NSA (National Security Agency) for the negotiation of the SA parameters, and

- OAKLEY protocol, based on Diffie-Hellman, for the selection of the encryption keys

For an effective protection of the data, the parameters negotiation should be itself protected.

IKE defines therefore two different phases:

- Phase 1 - Creates a protected environment (an SA) between the partners, to protect the negotiation of the authentication and encryption parameters to be used in the actual data transfer phase.

Phase 1 can be executed either via the Main Mode protocol (MM) or via the Aggressive Mode protocol (AM).

- Phase 2 - Partners negotiate the protection parameters to be used in the data transfer phase. The negotiation is protected by the elements defined in phase 1.

Phase 2 is executed through the protocol known as the Quick Mode.

Phase 1 Main Mode concept:

- Step a - One party sends an offer including all the parameters needed to define a Security Association (SA), EXCEPT the keys.

Receiving party answers with the selected parameters.

- Step b - Parties exchange their public keys and some random sequences (nonce) to be used in step c.

- Step c - Using the keys and nonces exchanged in step b, parties authenticate each other.

At the end of these three steps, the two partners have been authenticated, and keys have been generated for the protection of the messages to be exchanged in Phase 2.

At the end of Phase 2, all the parameters and the keys necessary for operation are defined, and partners can start the actual data transfer phase, generating AH or ESP protected packets.

Source :

www.sorin-schwartz.com   by Sorin M. SCHWARTZ

Paul Asadoorian

Interpeak

http://www.openbsd.org/faq/faq13.html – OpenBSD Doc

http://www.freeswan.org/ – Linux IPsec Support

http://www.ietf.org/html.charters/ipsec-charter.html – All RFC's &

Drafts

http://www.cisco.com/warp/public/105/IPSECpart1.html – Intro from

Cisco

http://www.counterpane.com/ipsec.pdf – An eval of IPsec