One document matched: draft-kasera-esvp-00.txt
Internet Engineering Task Force
INTERNET-DRAFT
draft-kasera-esvp-00.txt
Date: October 28, 2002 S. Kasera, Editor
Expires: May 2003
IP Encapsulating Security Variable Payload (ESVP)
Status of this memo
Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF),
its areas, and its working groups. Note that other groups may
also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt The list of
Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.
Abstract
This note describes a new IPsec option called Encapsulating
Security Variable Payload (ESVP) that allows a variable but
contiguous portion of the payload received from upper protocol
layers to be encrypted/authenticated between the two end-points of
a security association. The remaining portion of the payload is
left in the clear. The upper layer payload contains the upper
layer protocol headers and data. The decision about which
portions of the payload should be available as cleartext is taken
only by the end-points of the security association. By leaving a
certain portion of the payload as cleartext, ESVP provides the
option of encrypting and decrypting an IPsec ESVP datagram at
other protocol layers to allow limited and secure access to the
Kasera et al. Expires 05/03 [Page 1]
INTERNET-DRAFT draft-kasera-esvp-00.txt 10/02
cleartext data at these protocol layers. These layers could be
terminated inside the network for providing network-based value
added services and performance optimizations. These network-based
value added services and performance optimizations include policy
implementation and QoS based on packet classification, TCP
performance enhancement in the case of wireless networks and
firewall services.
Contents
1 Introduction 2
2 Terminology 3
3 ESVP - Encapsulating Security Variable Payload 3
4 Applications of ESVP 7
4.1 Performance enhancements ................................. 7
4.2 Firewall-based Denial of Service Protection .............. 8
4.3 Enhancing SSL ............................................ 9
4.4 Priority Assignment Based on Transport Protocol .......... 9
5 Comparison of ESVP with Other Approaches 10
6 Security Considerations 11
1 Introduction
The current standard for IP level security (IPsec) enforces the
encryption/authentication of the entire payload that is received
from the upper layers. Such a function ensures the security of
the entire payload, including the transport headers and even
network layer headers in some cases, between two end-points that
have established a security association [1]. Unfortunately, the
current IPsec architecture prevents even trusted intermediaries
from examining the payload for providing value added services and
performance optimizations including packet classification and
policy execution, TCP performance enhancements in case of wireless
networks, and firewall services.
In this document we propose a new IPsec option called
Encapsulating Security Variable Payload (ESVP) that allows a
variable but contiguous portion of the payload to be
encrypted/authenticated between the two end-points of a security
association and leaves the remaining portion of the payload in the
clear. The decision about which portions of the payload should be
Kasera et al. Expires 05/03 [Page 2]
INTERNET-DRAFT draft-kasera-esvp-00.txt 10/02
available as cleartext is taken only by the end-points of the
security association. This option allows IPsec to accommodate the
tussle between the end-points and the service providers [2], i.e.,
the service providers want to peek into visible information of the
packets for providing value-added services while the end-points
decide, based on the benefits they receive, what portion of the
information is available to the service providers.
While the ESVP security association determines what portion of the
payload is cleartext, this does not necessarily mean that the
cleartext is exposed to every intermediary. For example, the
cleartext in the IP ESVP packet could be potentially
encrypted/decrypted by other protocol layers including another
IPsec ESP or IPsec ESVP layer. The termination points of these
layers are trusted intermediaries that are allowed to examine or
in some special cases even modify the cleartext for enabling value
added services and performance enhancements. In Section 4, we
describe several examples where ESVP is essential and does not
expose the negotiated cleartext to anyone other than the trusted
intermediaries.
It is assumed that ESVP will be used when an end-point (e.g.
enterprise VPN gateway) desires to allow a portion of the upper
layer payload to be examined (or altered) by only a trusted
intermediary (e.g. network service provider node, overlay network
node), but protected from any other party. This is done by design
and there is a ``trust'' between the endpoint and the
intermediary. The end-points have complete control over what is
allowed in the cleartext. The end-points also control whether or
not the cleartext is authenticated end-to-end. The trust model
between the end-points and the intermediary requires that the
intermediary would not use the information in cleartext to attack
the end-points or play ``end-to-end'' games. Trusting the
intermediary does not imply that the end-points do not detect and
respond to inappropriate actions of the intermediary.
2 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in [3].
3 ESVP - Encapsulating Security Variable Payload
ESVP extends ESP to obtain more flexibility by leaving out certain
Kasera et al. Expires 05/03 [Page 3]
INTERNET-DRAFT draft-kasera-esvp-00.txt 10/02
portion of the payload in the clear. The cleartext must be a
contiguous block from the head or tail of the payload. An ESVP
packet has four additional octets in comparison to an ESP packet.
All the fields of the ESVP packet are described below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
A=0 ^ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |A|T| Reserved | Proto | Cleartext Length |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Cleartext (variable) |
A ~ ~
A=1 U | |
^ T +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H | Security Parameter Index (SPI) |
| E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A N | Sequence Number |
^ U T +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T I | Encrypted Payload (variable) |
E H C ~ ~
N . A | |
C | T + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | E | | Padding (0-255 octets) |
. | D +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | Pad Length | Next Header |
v v v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Data (Variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A
This is a one bit field, called the A-bit. When the A-bit
is set to 0 the cleartext is authenticated end-to-end.
Otherwise, the cleartext is not authenticated end-to-end.
T
This is a one bit field, called the T-bit. It indicates
whether the head or tail of the payload is encrypted. When
the tail of the payload is encrypted, the T-bit is set to
zero to indicate that the cleartext is placed before the SPI
field. When the head of the payload is encrypted, the T-bit
is set to 1 and the cleartext follows the Authentication
Data field.
Kasera et al. Expires 05/03 [Page 4]
INTERNET-DRAFT draft-kasera-esvp-00.txt 10/02
Reserved
These six bits are reserved for indicating any other
properties of the cleartext in the future.
Proto
This is a one octet field that indicates the next protocol.
Cleartext Length
This field contains the length in octets of the cleartext.
This field is two octets long.
Cleartext
This is the part of the payload received from the upper
layers that is left out in the clear.
Security Parameter Index (SPI)
As defined in [4], the SPI is an arbitrary 32-bit value
that, in combination with the destination IP address and
security protocol (ESPV), uniquely identifies the Security
Association used in this datagram.
Sequence Number
As defined in [4], the sequence number is an unsigned 32 bit
field containing a monotonically increasing counter value.
This field is useful against replay attacks.
Encrypted Payload
This is a variable length field that contains the payload
passed from the upper protocol layers minus the cleartext.
As in the case of the Payload Data field of ESP, the
Encrypted Payload Data field may also explicitly carry an
Initialization Vector (IV) if required by the encryption
algorithm.
Kasera et al. Expires 05/03 [Page 5]
INTERNET-DRAFT draft-kasera-esvp-00.txt 10/02
Padding
Same as the Padding field in ESP.
Pad Length
Same as the Pad Length field in ESP.
Next Header
Same as the Next Header field in ESP.
Authentication Data
The Authentication Data is a variable-length field
containing an Integrity Check Value (ICV) computed over the
ESVP packet starting from the Security Parameter Index (SPI)
field until the end of the datagram minus the Authentication
Data. The rules that apply to the Authentication Data field
of ESP also apply to this field.
ESVP must be supported in both transport and tunnel mode. We now
show the ESVP transport mode positioning for a typical IPv4 packet
when the TCP header is left in the clear.
BEFORE APPLYING ESVP
-------------
|IP|TCP|Data|
-------------
AFTER APPLYING ESVP
---------------------------------------------------------
|IP|A|T| |Proto|Cleartext|TCP|SPI|Seq|Data|ESVP |ESVP|
| |0|0| | |Length=20| | | # | |trailer|Auth|
---------------------------------------------------------
<--> <--Encrypted->
Reserved
<--------------------Authenticated-------------->
We now show the ESVP tunnel mode positioning for a typical IPv4
packet when the inner IP and TCP headers are left in the clear.
Kasera et al. Expires 05/03 [Page 6]
INTERNET-DRAFT draft-kasera-esvp-00.txt 10/02
BEFORE APPLYING ESVP
-------------
|IP|TCP|Data|
-------------
AFTER APPLYING ESVP
------------------------------------------------------------
|Outer|A|T| |Proto|Cleartext|IP |SPI|Seq|Data|ESVP |ESVP|
| IP |1|0| | |Length=40|TCP| | # | |trailer|Auth|
------------------------------------------------------------
<--> <--Encrypted->
Reserved <----Authenticated--->
In both the transport and the tunnel mode the Proto field of the
outer IP header should have a new value indicating that the next
protocol is ESVP.
4 Applications of ESVP
In this section, we present four examples where the flexibility
offered by ESVP is essential for providing value-added services.
The first exposes protocol headers to the service provider in
order to improve performance. The second involves deploying a
network-based firewall that prevents denial of service attacks.
The third involves enhancing the security of Secure Sockets
Layer(SSL). The fourth example demonstrates how a priority policy
could be implemented by examining the transport protocol field.
4.1 Performance enhancements
We first present a scenario where two end-points are
communicating using an IPsec security association but wish to
expose the IP/TCP headers to a trusted intermediary. In the
figure below, end-point E1 establishes a security association
with end-point E2. E1 also establishes a security association
with trusted intermediary TI and TI establishes a security
association with E2. E1 uses ESVP in tunnel mode to encrypt
the TCP data using the security parameters exchanged with E2
but leaves the inner IP and TCP headers in cleartext. The
A-bit is set to 1 only if E1 wants TI to change the TCP headers
for performance enhancement. Next, E1 sends the resulting ESVP
packet over the other ESVP tunnel (terminating at TI) that
leaves the encrypted part from the first ESVP operation
Kasera et al. Expires 05/03 [Page 7]
INTERNET-DRAFT draft-kasera-esvp-00.txt 10/02
including the encrypted TCP data in the cleartext but encrypts
the rest of the first ESVP packet. The T-bit of the outer ESVP
packet is set to 1. The second ESVP tunnel ensures that inner
IP and TCP headers are not visible to any node in the path
between E1 and TI. It also ensures the authenticity of these
headers. On receiving the ESVP packet on its tunnel from E1,
TI decrypts the outer ESVP packet and hence the IP/TCP header
and further sends the inner ESVP packet to E2 through another
ESVP tunnel.
ESVP Tunnel for TCP data
--------------------------------------
--------------------------------------
E1 TI E2
(End-Host) (Trusted Intermediary) (End-Host)
------------------ ------------------
------------------ ------------------
ESVP Tunnel for ESVP Tunnel for
IP/TCP header IP/TCP header
This approach of securing payload and headers independently
results in a simple and scalable deployment. Consider a
specific case where E2 is a VPN gateway, TI is the wireless
service provider and E1's are mobile hosts accessing the
enterprise Intranet through the gateway, E2. In this case, E1
negotiates with E2 for allowing the TCP/IP headers in the open
in the upper tunnel. The lower left ESVP tunnel is not even
necessary since the wireless link layer's privacy and message
integrity mechanism could be used to secure the headers between
the mobile host and the intermediary. In the case of the lower
right tunnel, the security association can be established
independently of the host to gateway security association and
can be common to all the hosts accessing the gateway. This
approach is simple and scalable since it preserves the
one-to-one nature of security association establishment and
requires only one extra security association between TI and E2
for enabling header-based services to all users communicating
with E2.
4.2 Firewall-based Denial of Service Protection
ESVP could be used to provide firewall-based denial-of-service
protection. This is demonstrated in the following example.
Kasera et al. Expires 05/03 [Page 8]
INTERNET-DRAFT draft-kasera-esvp-00.txt 10/02
Consider a scenario where an enterprise user is communicating
with an enterprise VPN gateway using an IPsec ESP tunnel. Let
there be a network based firewall between the enterprise user
and the VPN gateway that blocks all the packets toward the user
with source address other than that of the enterprise or
destination address that is different from the user's
destination address. The problem is that a malicious user
could spoof the addresses of the VPN gateway and the user and
send IPsec packets that would be allowed in by the firewall.
The user would eventually drop the IPsec packets it cannot
authenticate but before it does that some precious last
hop/access network bandwidth and potentially processing
resources get wasted. This problem is more severe in the case
of mobile users communicating over wireless links. Using ESVP
tunnels for encrypting IP/TCP headers between the VPN gateway
and the firewall and between the firewall and the user, in
addition to an ESVP tunnel between the user and the VPN gateway
for protecting data, firewall-based denial-of-service
protection could be provided to the enterprise user.
Note that an ESP or an AH tunnel could also be used between the
VPN gateway and the firewall instead of an ESVP tunnel. The
ESVP tunnel saves the overhead of double
encryption/authentication.
4.3 Enhancing SSL
Using ESVP, we could efficiently secure the IP/TCP headers left
in the clear by applications using SSL. This could be done by
encrypting the IP/TCP headers and leaving the encrypted TCP
payload part in cleartext. ESVP allows the headers to be
protected without the overhead of doubly encrypting the TCP
payload that is already encrypted by SSL. The ESVP layer could
terminate at the SSL server or at a network intermediary (for
example, a Virtual Private Network, VPN, gateway), depending on
how the security association has been set up.
4.4 Priority Assignment Based on Transport Protocol
ESVP allows trusted intermediaries to deploy QoS mechanisms and
policy implementations using five-tuple-based (IP source and
destination addresses, source and destination port numbers,
type of protocol) packet classification even for encrypted
Kasera et al. Expires 05/03 [Page 9]
INTERNET-DRAFT draft-kasera-esvp-00.txt 10/02
traffic. For e.g., ESVP could be used to allow a trusted
intermediary (possibly a router) to examine what transport
protocol is being used by packets between two end-points. The
trusted intermediary could assign a lower priority to the
``non-conforming'' UDP traffic and a higher priority to TCP
traffic during link congestion. classification techniques for
encrypted traffic also.
5 Comparison of ESVP with Other Approaches
We now compare the performance of ESVP with two existing
extensions to IPsec that allows intermediaries, partial access to
the payload.
In [5], Bellovin proposed a variant of ESP called
Transport-Friendly ESP (TF-ESP) which allowed for leaving out
certain portions of the payload in the clear. He also suggested
that the cleartext be integrity protected with the rest of the ESP
header. The problem with this approach is that when the ESP
header is integrity protected with keys known only to end-points,
the intermediaries cannot verify if the information is correct.
Also, the end-to-end integrity protection does not allow an
intermediary to enable those services or performance enhancements
that require modification of the cleartext. In ESVP, the A-bit
allows the flexibility of deciding whether or not the cleartext
should be authenticated end-to-end. The A-bit allows the
end-point to selectively grant the trusted intermediary, read-only
or read/write access to the cleartext. We propose to address the
problem of verification of cleartext (whether authenticated
end-to-end or not) at the trusted intermediary by using another
ESVP tunnel between the end-point and the trusted intermediary.
ESVP also allows the flexibility of having the head or tail of the
payload in the clear which prevents double encryption for certain
applications e.g., SSL over ESVP mentioned above.
Bellovin proposed another variant of ESP called ``Disclosure''
Header where all fields of interest are copied from the payload
into an unencrypted portion of the ESP header [5]. Although
cleaner, this approach requires pre-defined header formats to be
known to the trusted intermediaries and end-points, making it less
flexible. The trusted intermediaries also need to be informed
about which ``disclosure'' header format is being used. This
approach also increases the length of the packet which might be
prohibitive for bandwidth limited scenarios.
Kasera et al. Expires 05/03 [Page 10]
INTERNET-DRAFT draft-kasera-esvp-00.txt 10/02
In [6, 7], Zhang et al have proposed a very generic approach
called Multi-Layer IPsec (ML-IPsec) that divides the payload into
multiple zones such that each zone could be encrypted with a
different key. Composite security associations involving
intermediaries are established and intermediaries with the keys to
encrypt/decrypt certain zones are allowed access to those zones.
The fine-granular control provided by this approach makes it very
complex. Especially, ML-IPsec changes the nature of the security
associations from one-to-one to one-to-many. We retain the
security association as one-to-one. We believe that ESVP will
address most of the needs of offering network based services and
performance enhancements without the complexity of ML-IPsec. It
is possible to provide a simpler version of ML-IPsec with ESVP by
encrypting/authenticating the cleartext with keys exchanged with
the intermediaries and indicating this in the flags field of the
ESVP header. Further discussion on this issue is beyond the scope
of this document.
6 Security Considerations
ESVP relies on ESP for handling the encrypted portion of the
payload. Furthermore, it relies on IKE for setting up and
managing the keys required to perform encryption and
authentication. Therefore, the security properties of ESVP with
respect to the encrypted portion of the payload should derive
directly from the properties of IKE and ESP.
Conversely, the security properties of the portion of the packets
that ESVP leaves unencrypted (the cleartext) derive from the
properties of the additional mechanism used to secure that portion
of the packets. For example, in case ESVP is used to secure the
unencrypted portion of the packets between the end points and a
trusted intermediary, as with the IP/TCP headers in the case of
the example of Section 4.1, the security properties of ESP will
also apply to the IP/TCP headers, albeit allowing a trusted
intermediary to have access to them. In this case, no end-to-end
security property applies to the unencrypted portion of the
packets, since the handling of such portion of the payload is left
to security associations which are not end-to-end.
However, it must be noted that with ESVP the end points have
complete control over which portion of the packets, if at all, is
not encrypted or authenticated. Therefore security policies can
be implemented by system administrators who can decide, even on a
Kasera et al. Expires 05/03 [Page 11]
INTERNET-DRAFT draft-kasera-esvp-00.txt 10/02
per-packet basis, to what extent of the packets ESVP should be
applied, depending on the trust relationship that they have
established with their service providers, as well as on the
additional security mechanisms that are available to protect the
unencrypted portions of the packets.
Acknowledgments
We would like to thank Milind Buddhikot, Juan Garay, Semyon
Mizikovsky and Sanjoy Paul from Lucent Technologies for useful
discussions on this topic and comments on this draft.
References
[1] S. Kent and R. Atkinson. Security Architecture for the Internet
Protocol. RFC 2401, IETF, November 1998.
[2] D. Clark, J. Wroclawski, K. Sollins, and Robert Braden. Tussle
in cyberspace: Defining tomorrow's internet. In Proc. ACM
SICOMM Conference, Aug. 2002.
[3] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. RFC 2119, IETF, March 1997.
[4] S. Kent and R. Atkinson. IP Encapsulating Security Payload
(ESP). RFC 2406, IETF, November 1998.
[5] S. Bellovin. Transport-friendly esp (or layer violation for fun
and profit). IETF-44 TF-ESP BOF, Mar. 1999.
[6] Y. Zhang. Multi-Layer Protection Scheme for IPSEC. Work in
progress - Internet Draft, IETF, May 1999.
draft-zhang-ipsec-mlipsec-00.txt.
[7] Y. Zhang and B. Singh. A multi-layer ipsec protocol. In Proc.
9th Usenix Security Symposium, Aug. 2000.
Authors' Addresses
Sneha Kasera, Ramachandran Ramjee, Luca Salgarelli, Scott Miller,
Ganesh Sundaram, Eric Grosse
Bell Laboratories - Lucent Technologies
101 Crawfords Corner Rd.
Holmdel, NJ 07733, USA
Voice: +1-732-949-1660
Fax: +1-732-949-7397
E-mail: {kasera,ramjee,salga,scm,ganeshs,ehg}@lucent.com
Kasera et al. Expires 05/03 [Page 12]
INTERNET-DRAFT draft-kasera-esvp-00.txt 10/02
Full Copyright Statement
"Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Kasera et al. Expires 05/03 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-23 00:15:16 |