109 lines
7.3 KiB
HTML
109 lines
7.3 KiB
HTML
|
<?xml version="1.0" encoding="UTF-8"?>
|
||
|
|
<!DOCTYPE html
|
||
|
|
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
|
|
<html lang="en-us" xml:lang="en-us">
|
||
|
|
<head>
|
||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
|
<meta name="security" content="public" />
|
||
|
|
<meta name="Robots" content="index,follow" />
|
||
|
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
||
|
|
<meta name="DC.Type" content="concept" />
|
||
|
|
<meta name="DC.Title" content="Encapsulating Security Payload" />
|
||
|
|
<meta name="abstract" content="The Encapsulating Security Payload (ESP) protocol provides data confidentiality, and also optionally provides data origin authentication, data integrity checking, and replay protection." />
|
||
|
|
<meta name="description" content="The Encapsulating Security Payload (ESP) protocol provides data confidentiality, and also optionally provides data origin authentication, data integrity checking, and replay protection." />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzajaipsec.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzajaahheader.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzajaahheader.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="http://www.rfc-editor.org" />
|
||
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 2000, 2006" />
|
||
|
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2000, 2006" />
|
||
|
|
<meta name="DC.Format" content="XHTML" />
|
||
|
|
<meta name="DC.Identifier" content="rzajaesp" />
|
||
|
|
<meta name="DC.Language" content="en-us" />
|
||
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
|
|
<!-- US Government Users Restricted Rights -->
|
||
|
|
<!-- Use, duplication or disclosure restricted by -->
|
||
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
||
|
|
<title>Encapsulating Security Payload</title>
|
||
|
|
</head>
|
||
|
|
<body id="rzajaesp"><a name="rzajaesp"><!-- --></a>
|
||
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
<h1 class="topictitle1">Encapsulating Security Payload</h1>
|
||
|
|
<div><p>The Encapsulating Security Payload (ESP) protocol provides data
|
||
|
|
confidentiality, and also optionally provides data origin authentication,
|
||
|
|
data integrity checking, and replay protection.</p>
|
||
|
|
<p>The difference between ESP and the Authentication Header (AH) protocol
|
||
|
|
is that ESP provides encryption, while both protocols provide authentication,
|
||
|
|
integrity checking, and replay protection. With ESP, both communicating systems
|
||
|
|
use a shared key for encrypting and decrypting the data they exchange.</p>
|
||
|
|
<p>If 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.</p>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Two ways of using ESP</h4><p>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.</p>
|
||
|
|
<p>Transport mode does not authenticate
|
||
|
|
or encrypt the IP header, which might expose your addressing information to
|
||
|
|
potential attackers while the datagram is in transit. Transport mode requires
|
||
|
|
less processing overhead than tunnel mode, but does not provide as much security.
|
||
|
|
In most cases, hosts use ESP in transport mode.</p>
|
||
|
|
<p>Tunnel mode creates
|
||
|
|
a new IP header and uses it as the outermost IP header of the datagram, followed
|
||
|
|
by the ESP header and then the original datagram (both the IP header and the
|
||
|
|
original payload). The ESP trailer and the optional authentication data are
|
||
|
|
appended to the payload. When you use both encryption and authentication,
|
||
|
|
ESP completely protects the original datagram because it is now the payload
|
||
|
|
data for the new ESP packet. ESP, however, does not protect the new IP header.
|
||
|
|
Gateways must use ESP in tunnel mode.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">What algorithms does ESP use to protect my information?</h4><p>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), RC5, RC4, or Advanced Encryption Standard
|
||
|
|
(AES) for encryption.</p>
|
||
|
|
<p><img src="./delta.gif" alt="Start of change" />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 a 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. <img src="./deltaend.gif" alt="End of change" /></p>
|
||
|
|
<p>The
|
||
|
|
Internet Engineering Task Force (IETF) formally defines DES in Request for
|
||
|
|
Comment (RFC) 1829, <cite>The ESP DES-CBC Transform</cite>. The Internet Engineering
|
||
|
|
Task Force (IETF) formally defines 3DES in RFC 1851, <cite>The ESP Triple
|
||
|
|
DES Transform</cite>. You can view these and other RFCs on the Internet at
|
||
|
|
the following Web address: http://www.rfc-editor.org.</p>
|
||
|
|
<p>ESP uses HMAC-MD5
|
||
|
|
and HMAC-SHA algorithms to provide authentication functions. Both MD5 and
|
||
|
|
SHA take variable-length input data and a secret key to produce fixed-length
|
||
|
|
output data (called a hash value). If the hashes of two messages match, then
|
||
|
|
it is very likely that the messages are the same. Both MD5 and SHA encode
|
||
|
|
the message length in their output, but SHA is regarded as more secure because
|
||
|
|
it produces larger hashes.</p>
|
||
|
|
<p>The Internet Engineering Task Force (IETF)
|
||
|
|
formally defines HMAC-MD5 in Request for Comments (RFC) 2085, <cite>HMAC-MD5
|
||
|
|
IP Authentication with Replay Prevention</cite>. The Internet Engineering
|
||
|
|
Task Force (IETF) formally defines HMAC-SHA in Request for Comments (RFC)
|
||
|
|
2404, <cite>The Use of HMAC-SHA-1-96 within ESP and AH</cite>. You can view
|
||
|
|
these and other RFCs on the Internet at the following Web address: http://www.rfc-editor.org.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div>
|
||
|
|
<div class="familylinks">
|
||
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzajaipsec.htm" title="IPSec provides a stable, long lasting base for providing network layer security.">IP Security (IPSec) protocols</a></div>
|
||
|
|
</div>
|
||
|
|
<div class="relconcepts"><strong>Related concepts</strong><br />
|
||
|
|
<div><a href="rzajaahheader.htm" title="The Authentication Header (AH) protocol provides data origin authentication, data integrity, and replay protection. However, AH does not provide data confidentiality, which means that all of your data is sent in the clear.">Authentication Header</a></div>
|
||
|
|
</div>
|
||
|
|
<div class="relinfo"><strong>Related information</strong><br />
|
||
|
|
<div><a href="http://www.rfc-editor.org" target="_blank">http://www.rfc-editor.org</a></div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</body>
|
||
|
|
</html>
|