ITE4001 - NETWORK INFORMATION AND SECURITY

Lab Assessment - 5
NAME: VEDANT POPLE
REG NO: 18BIT0156
FACULTY: Dr. ASWANI KUMAR CHERUKURI
SLOT: F2+TF2 

The Encapsulating Security Payload (ESP) protocol provides data confidentiality, and also
optionally provides data origin authentication, data integrity checking, and replay protection.

The ESP header is inserted after the IP header and before the next layer protocol header
(transport mode) or before an encapsulated IP header (tunnel mode). These modes are
described in more detail below. ESP can be used to provide confidentiality, data origin
authentication, connectionless integrity, an anti-replay service (a form of partial sequence
integrity), and (limited) traffic flow confidentiality. The set of services provided depends on
options selected at the time of Security Association (SA) establishment and on the location of
the implementation in a network topology.Using encryption-only for confidentiality is allowed by
ESP.However, it should be noted that in general, this will provide defense only against passive
attackers. Using encryption without a strong integrity mechanism on top of it (either in ESP or
separately via AH) may render the confidentiality service insecure against some forms of
active attacks. Moreover, an underlying integrity service, such as AH, applied before
encryption does not necessarily protect the encryption-only confidentiality against active
attackers. ESP allows encryption-only SAs because this may offer considerably better
performance and still provideIf you decide to use both encryption and authentication, then the
responding system first authenticates the packet and then, if the first step succeeds, the system
proceeds with decryption. This type of configuration reduces processing overhead, as well as
reduces your vulnerability to denial-of-service attacks.

What algorithms does ESP use to protect information?

ESP uses a symmetric key that both communicating parties use to encrypt and decrypt the data
they exchange. The sender and the receiver must agree on the key before secure
communication takes place between them. VPN uses Data Encryption Standard (DES),
triple-DES (3DES), Advanced Encryption Standard (AES), or AES-CBC and AES-CTR for
encryption.

If you choose the AES algorithm for encryption then you might want to enable Extended
Sequence Number (ESN). ESN allows you to transmit large volumes of data at a high speed.
The VPN connection uses 64-bit sequence numbers instead of 32-bit numbers over IPSec.
Using 64-bit sequence numbers allows more time before re-keying, which prevents sequence
number exhaustion and minimizes the use of system resources.
The Internet Engineering Task Force (IETF) formally defines the algorithms in the following
Request for Comments (RFC):

● DES in Request for Comment (RFC) 1829, The ESP DES-CBC Transform
● 3DES in RFC 1851, The ESP Triple DES Transform
● AES-CBC in RFC 3602, The AES-CBC Cipher Algorithm and Its Use with IPsec
● AES-CTR in RFC 3686, Using Advanced Encryption Standard (AES) Counter Mode
with IPSec Encapsulating Security Payload (ESP)

It also specifies that ESP can provide data confidentiality and data integrity services.Data
integrity without data confidentiality ("integrity-only ESP") is possible via the ESP-NULL
encryption algorithm [RFC2410] or via combined-mode algorithms such as AES-GMAC
[RFC4543]. The exact encapsulation and algorithms employed are negotiated out of band
using, for example,Internet Key Exchange Protocol version 2 (IKEv2) [RFC4306] and based on
policy.

ESP encapsulation uses protocol number 141.Accordingly, the (outer) protocol header (IPv4,
IPv6, or Extension)that immediately precedes the WESP header SHALL contain the value (141)
in its Protocol (IPv4) or Next Header (IPv6, Extension) field.WESP provides additional attributes
in each packet to assist in differentiating between encrypted and unencrypted data, and to aid in
parsing of the packet. WESP follows RFC 4303 for all IPv6 and IPv4 considerations (e.g.,
alignment considerations).This extension essentially acts as a wrapper to the existing ESP
protocol and provides an additional 4 octets at the front of the existing ESP packet for IPv4.

Two ways of using ESP

You can apply ESP in two ways: transport mode or tunnel mode. In transport mode, the ESP
header follows the IP header of the original IP datagram. If the datagram already has an IPSec
header, then the ESP header goes before it. The ESP trailer and the optional authentication
data follow the payload.

Transport mode​ :
In transport mode, ESP is inserted after the IP header and before a next layer protocol, e.g.,
TCP, UDP, ICMP, etc. In the context of IPv4, this translates to placing ESP after the IP header
(and any options that it contains), but before the next layer protocol. (If AH is also applied to a
packet, it is applied to the ESP header, Payload, ESP trailer, and ICV, if present.) (Note that
the term "transport" mode should not be misconstrued as restricting its use to TCP and UDP.)
The following diagram illustrates ESP transport mode positioning for a typical IPv4 packet, on
a "before and after" basis. (This and subsequent diagrams in this section show the ICV field,
the presence of which is a function of the security services and the algorithm/mode selected.)
In the IPv6 context, ESP is viewed as an end-to-end payload, and thus should appear after
hop-by-hop, routing, and fragmentation extension headers. Destination options extension
header(s) could appear before, after, or both before and after the ESP header depending on
the semantics desired. However, because ESP protects only fields after the ESP header, it
generally will be desirable to place the destination options header(s) after the ESP header.
The following diagram illustrates ESP transport mode positioning for a typical IPv6 packet.
Tunnel mode:
In tunnel mode, the "inner" IP header carries the ultimate (IP) source and destination addresses,
while an "outer" IP header contains the addresses of the IPsec "peers", e.g., addresses of
security gateways. Mixed inner and outer IP versions are allowed, i.e., IPv6 over IPv4 and
IPv4 over IPv6. In tunnel mode, ESP protects the entire inner IP packet, including the entire
inner IP header. The position of ESP in tunnel mode, relative to the outer IP header, is the
same as for ESP in transport mode. The following diagram illustrates ESP tunnel mode
positioning for typical IPv4 and IPv6 packets.
Encryption :
The encryption algorithm employed to protect an ESP packet is specified by the SA via which
the packet is transmitted/received. Because IP packets may arrive out of order, and not all
packets may arrive (packet loss), each packet must carry any data required to allow the
receiver to establish cryptographic synchronization for decryption. This data may be carried
explicitly in the payload field, e.g., as an IV (as described above), or the data may be derived
from the plaintext portions of the (outer IP or ESP) packet header. (Note that if plaintext
header information is used to derive an IV, that information may become security critical and
thus the protection boundary associated with the encryption process may grow.

Integrity:
The integrity algorithm employed for the ICV computation is specified by the SA via which the
packet is transmitted/received. As was the case for encryption algorithms, any integrity
algorithm employed with ESP must make provisions to permit processing of packets that arrive
out of order and to accommodate packet loss. The same admonition noted above applies to
use of any plaintext data to facilitate receiver synchronization of integrity algorithms. To allow
an ESP implementation to compute any implicit integrity algorithm padding required, the RFC
for each algorithm used with ESP must specify the padding modulus for the algorithm.

Auditing :
If ESP is incorporated into a system that supports auditing, then the ESP implementation must
also support auditing and must allow a system administrator to enable or disable auditing for
ESP. For the most part, the granularity of auditing is a local matter. However, several
auditable events are identified in this specification and for each of these events a minimum set
of information that should be included in an audit log is defined.
Conformance Requirements:
Implementations that claim conformance or compliance with this specification must implement
the ESP syntax and processing described here for unicast traffic, and must comply with all
additional packet processing requirements levied by the Security Architecture document.
Additionally, if an implementation claims to support multicast traffic, it must comply with the
additional requirements specified for support of such traffic. If the key used to compute an
ICV is manually distributed, correct provision of the anti-replay service requires correct
maintenance of the counter state at the sender (across local reboots, etc.), until the key is
replaced, and there likely would be no automated recovery provision if counter overflow were
imminent. Thus, a compliant implementation should not provide anti-replay service in
conjunction with SAs that are manually keyed. Because use of encryption in ESP is optional,
support for the "NULL" encryption algorithm also is required to maintain consistency with the
way ESP services are negotiated. Support for the confidentiality-only service version of ESP is
optional. If an implementation offers this service, it must also support the negotiation of the
"NULL" integrity algorithm.

Security Considerations:
Security is central to the design of this protocol, and thus security considerations permeate the
specification. Additional security relevant aspects of using the IPsec protocol are discussed in
the Security Architecture document.

Backward-Compatibility Considerations:
There is no version number in ESP and no mechanism enabling IPsec peers to discover or
negotiate which version of ESP each is using or should use. This section discusses consequent
backward-compatibility issues. First, if none of the new features available in ESP v3 are
employed, then the format of an ESP packet is identical in ESP v2 and v3. If a combined
mode encryption algorithm is employed, a feature supported only in ESP v3, then the resulting
packet format may differ from the ESP v2 spec.

In the new ESP (v3), we make two provisions to better support traffic flow confidentiality (TFC):
- arbitrary padding after the end of an IP packet
- a discard convention using Next Header = 59

The first feature is one that should not cause problems for a receiver, since the IP total length
field indicates where the IP packet ends. Thus, any TFC padding bytes after the end of the
packet should be removed at some point during IP packet processing, after ESP processing,
even if the IPsec software does not remove such padding.

The second feature allows a sender to send a payload that is an arbitrary string of bytes that do
not necessarily constitute a well formed IP packet, inside of a tunnel, for TFC purposes. It is an
open question as to what an ESP v2 receiver will do when the next Header field in an ESP
packet contains the value "59". It might discard the packet when it finds an ill-formed IP header,
and log this event, but it certainly ought not to crash, because such behavior would constitute a
DoS vulnerability relative to traffic received from authenticated peers.

Fragmentation:
Fragmentation is performed after ESP processing within an IPsec implementation. Thus,
transport mode ESP is applied only to whole IP datagrams (not to IP fragments). An IP packet
to which ESP has been applied may itself be fragmented by routers en route, and such
fragments must be reassembled prior to ESP processing at a receiver. In tunnel mode, ESP is
applied to an IP packet, which may be a fragment of an IP datagram. For example, a security
gateway or a "bump-in-the-stack" or "bump-in-the-wire" IPsec implementation (as defined in the
Security Architecture document) may apply tunnel mode ESP to such fragments.

Fragmentation, whether performed by an IPsec implementation or by routers along the path

between IPsec peers, significantly reduces performance. Moreover, the requirement for an ESP
receiver to accept fragments for reassembly creates denial of service vulnerabilities.