Internet Engineering Task Force                    M. MOSTAFA
INTERNET-DRAFT                                     A. ABOU EL KALAM
draft-mostafa-qesp-00.txt                          C. FRABOUL
Date: December 2, 2009                             INPT-ENSEEIHT, IRIT-CNRS
Expires: June, 2010

        QoS-friendly Encapsulating Security Payload (Q-ESP)

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with
   the provisions of BCP 78 and BCP 79.

   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-

   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

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document   authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.


   This document describes a new IPSec protocol called QoS-friendly
   Encapsulating Security Payload (Q-ESP).  Q-ESP provides
   confidentiality, data origin authentication, anti-reply,
   connection less integrity, and facilitates QoS active admission
   control. The currently implemented IPSec Encapsulating Security
   Payload (ESP) protocol is not QoS friendly as it encrypts the upper
   layer transmission protocol and prevents network control devices
   such as routers and switches from utilizing this information in
   performing classification appropriately. In this document we provide
   the specification of Q-ESP which gives the same security services
   provided by ESP, in addition to strong source and destination
   addresses authentication and its ability to facilitate QoS

Mostafa, et al.                 Expires 06/10                      [Page 1]

INTERNET-DRAFT                draft-mostafa-qesp-00.txt               12/09

Table of Contents

   1 Introduction ......................................................2

   2 Terminology........................................................3

   3 Q-ESP: QoS-friendly Encapsulating Security Payload.................3
     3.1.Q-ESP Packet Format............................................3
     3.2.Q-ESP Mode of operations.......................................6
     3.3.Q-ESP Protocol Processing......................................6

   4  QoS classification batch..........................................8

   5  Possible applications of Q-ESP....................................8


Authors Information....................................................10

1. Introduction

   The Internet has become essential for information exchange. Various
   activities are carried out via the Internet: between companies (B2B),
   among businesses and consumers (B2C), or between individuals who
   create their own virtual communities (e.g., P2P). This clearly causes
   a huge demand for the network bandwidth. Moreover, many real-time
   applications such as video conferencing and Voice over Internet
   Protocol (VoIP) have been developed. These types of traffic-demanding
   applications suffer greatly from congestion and delay. Thus, there is
   a great need to find methods and mechanisms to manipulate traffic more
   efficiently according to their needs. Quality of service (QoS) has
   emerged to deal with this kind of problem. Basically, it refers to the
   nature of packet delivery service provided, as described by parameters
   such as bandwidth, delay, jitter, and packet loss [Shenker and
   Wroclawski, 1997]. The way of classifying traffic and providing QoS
   levels defines different QoS architectures [Nguyen, 2003]. Mainly, we
   distinguish two standard QoS architectures: Integrated service [Braden,
   Clark and Shenker, 1994] and Differentiated service [Blake, Black,
   Carlson, Davies, Wang and Weiss, 1998].

   Actually, in the QoS field, the "Class of Service"concept divides the
   network traffic into different classes and provides a class-dependent
   service to each packet (depending on which class it belongs to).
   To classify packets, each packet is assigned a priority value. The
   latter is stored in the "Type of Service" (ToS)[Postel, 1981] field
   in the IPv4 header (also called "Traffic Class" in IPv6) [Deering and
   Hinden, 1998]. In the differentiated service architecture, this priority
   value is called Differentiated service code point (DSCP) [Nichols, Blake,
   Baker and Black, 1998].However, it is obvious that allowing the sending
   device to classify traffic or to set traffic priorities may be subject
   to threats, as the sender may classify his traffic in a way that gives
   him upper priorities. This is clearly the disadvantage of what is
   called passive admission control. Conversely, service providers perform
   active admission control by allowing edge routers (neither users nor the
   sending devices) to inspect the incoming traffic and classify it.
   Note that in both architectures (the differentiated service and
   integrated service), the packet classifier component inspects incoming
   packets and classifies them. As the classifier inspects multiple fields
   in the packet, it is called Multi-Field (MF) classifier [Borg, Savanberg
   and Schelen, 1999].

Mostafa, et al.                 Expires 06/10                      [Page 2]

INTERNET-DRAFT                draft-mostafa-qesp-00.txt               12/09

   Actually, the fields needed to be inspected belong to different network
   layer headers [Gupta, 2000]:

        _Transport Layer Protocol Header: the MF packet classifier inspects
   two fields of the transport layer protocol (TCP/UDP) header, the source
   and destination port numbers; these fields naturally help to identify
   the applications running over TCP/UDP.

        _Network Layer Protocol Header: three fields are inspected at this
   layer, the source host IP address that helps to identify the sending
   host, the destination host IP address, which helps to identify the
   end-system receiving the data, and the protocol identifier that is used
   to identify the transport-layer protocol in use.

   The previously mentioned five fields are used to define the traffic flow
   [Huston, 2000]. However, even if these fields are required for QoS
   processing, some of them are unfortunately hidden (encrypted) when
   using security protocols such as IPSec [Kent and Atkinson, 1998] ESP
   [Kent, 2005].

   To solve this problem, we propose a new security protocol the
   "QoS-friendly Encapsulated Security Payload (Q-ESP)". Not only Q-ESP
   provides stronger security protection but also supports QoS active
   admission control.

2. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [Bradner, 1997].

3  Q-ESP: QoS-friendly Encapsulating Security Payload

3.1. QoS friendly Encapsulating Security Payload(Q-ESP) packet format

   The major aim of the Q-ESP protocol is to construct packets that are QoS
   controllable according to active admission control.

   In addition to security services provided by the IPSec ESP (i.e. Data
   origin authentication, Anti-reply integrity, connectionless integrity and
   confidentiality), Q-ESP supports QoS by providing the necessary and
   sufficient information for the controlling devices to enable them
   performing active admission control.

   Besides that, Q-ESP prevents replay attacks. In fact, while the anti-reply
   function is optional in ESP and AH [Kent and Atkinson, 1998], it is
   mandatory in Q-ESP. In addition, while authentication is optional in ESP,
   it is mandatory in Q-ESP as it prevents against attacks that form malicious
   packet from valid IP and ESP headers but with invalid payload (which will
   be discarded later after doing the most resource intensive process of
   decryption). Moreover, Q-ESP authentication provides data origin
   authentication (as it covers the source and destination addresses fields
   of the outer IP-header).

   Figure 1 depicts the structures of Q-ESP in IP versions 4 and 6.
   An Q-ESP packet contains eight additional octets. Like ESP, the structure
   of Q-ESP is composed of the header, the payload, the trailer, and the
   authentication data area. All the fields of the Q-ESP packet are described

Mostafa, et al.                 Expires 06/10                      [Page 3]

INTERNET-DRAFT              draft-mostafa-qesp-00.txt                 12/09

|                               IP Header                       |
~                                                               ~
|               IP header       Source IP Address               |  ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|  |
|               IP header  Destination IP Address               |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|  |
|                                                               |  |
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 |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| Authent-
|               Source Port     |      Destination Port         |  ication
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| Coverage
|       TLP     |                       Reserved                |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|  |
|              Security Parameters Index (SPI)                  |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|  |
|                      Sequence Number                          |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|  | -------
|                    Payload Data* (variable)                   |  |    ^
~                                                               ~  |    |
|                                                               |  | Confid-
+                 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ |  | entiality
|                 |     Padding (0-255 bytes)                   |  | Coverage
+-+-+-+-+-+-+-+-+-+                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-|  |    |
|                                   |  Pad Length  | Next Header|  v    v
|                      Authentication Data (variable)           |

                        Figure 1: Q-ESP packet format

3.1.1 The Q-ESP header

   The Q-ESP header contains a Security Parameters Index and a Sequence Number.

   In addition, to cope with QoS requirements, we copy the first two fields
   (source and destination ports) of the upper layer transfer protocols and
   place them in clear (without encryption) in the Q-ESP header. Also, the
   value of the transport layer protocol is recorded in the TLP field; This
   clearly allows MF packet classifier to perform efficient packet
   classification. In this respect, the Q-ESP header includes the following
   six fields:   Source Port

   This is a 16-bit fixed-length field; it contains the first field of the
   upper layer transport protocol (TCP/UDP) source port number; this field is
   needed to be in clear to enable network edge routers to check traffic and
   set priorities.   Destination Port

   This is also a 16-bit fixed-length field; it contains the second field of
   the upper layer transport protocol (TCP/UDP) destination Port number; as
   the source port, this field is also needed to be in clear to enable network
   edge routers to check traffics and set priorities. Transmission Layer Protocol (TLP)

   This is an 8-bit fixed-length field that indicates the protocol of the
   transport layer.

Mostafa, et al.                 Expires 06/10                      [Page 4]

INTERNET-DRAFT              draft-mostafa-qesp-00.txt                 12/09

   The previously mentioned three fields (Source Port, Destination Port and
   TLP) are used with IP source and destination addresses to identify traffic
   flow.   Reserved

   This is a 24-bit fixed-length field that is not used (reserved for future
   uses) and must be set to zero.   Security Parameters Index

   This is an arbitrary 32-bit fixed length identifier that in combination with
   the destination address and security protocol (Q-ESP) uniquely identifies the
   security association (SA) in use.   Sequence Number

   This is an unsigned 32 bit field. It is a monotonically increasing ID that is
   used to detect replay attacks. This value is authenticated, so that malicious
   or accidental modifications could be detected.

3.1.2 The Q-ESP payload

   The payload encrypts the upper layer transport protocol and its payload data
   in transport mode, while in tunnel mode it encrypts the entire original IP
   packet including its header.

3.1.3 The Q-ESP trailer

   The Q-ESP trailer includes the Padding, the pad length field and the Next
   Header field. Padding

   This is provided to allow block-oriented encryption algorithms area for
   multiples of their block size. Pad length

   This is an 8-bit fixed-length field that indicates the length of the
   included pad. Next Header

   This is a mandatory, 8-bit fixed-length field that points backward to refer
   to the type of the protocol (IP, TCP, UDP, etc.) in the encrypted payload.

3.1.4. Authentication data area

   It is a variable length area that is used to store the Integrity check
   value (ICV). The Integrity Check Value (ICV) is calculated over the
   Q-ESP headers and the Payload. In Q-ESP, to inherit the capability of AH,
   we also apply the authentication algorithm over the source IP address
   and destination IP address fields of the IP header.
   However, unlike AH, we think that authenticating the rest of the IP header
   fields is meaningless as they will be used before the packet reaches the
   IPSec layer (i.e. before verifying their integrity); therefore, any change
   in their values will not affect the IPSec processing.
   Besides, in Q-ESP, both authentication and encryption are mandatory.
   Actually,authentication helps to prevent DoS attacks [Nikov, 2006].
   Moreover,implementing authentication with encryption provides in
   depth-defense if the encryption secret key is corrupted; in fact even
   if the attacker succeeds in reading the content of the payload,
   he will not be able to alter its content.

Mostafa, et al.                 Expires 06/10                      [Page 5]

INTERNET-DRAFT              draft-mostafa-qesp-00.txt                 12/09

3.2. Q-ESP Mode of operations

   Q-ESP must be supported in both transport and tunnel mode.  We now
   Show the Q-ESP transport mode for a typical IPv4 packet.


                                |  IP  |  TCP  |    Data   |


                   <-----Q-ESP header------>
  |  IP  ~ Src|Dst |Src |Dst |TLP| |SPI|Seq|TCP|Data| Q-ESP | Q-ESP |
  |header| IP@|IP@ |Port|Port|   | |   | # |   |    |trailer| Auth  |
                                 <->       <---Encrypted---->

                        Figure 2: Q-ESP in transport mode

   We now show the Q-ESP tunnel mode for a typical Ipv4 packet.


                      <-----Q-ESP header------>
  |Outer IP ~ Src|Dst |Src |Dst |TLP| |SPI|Seq|inner|TCP|Data| Q-ESP | Q-ESP |
  | header  | IP@|IP@ |Port|Port|   | |   | # |  IP |   |    |trailer|  Auth |
                                    <->       <-------Encrypted------>

                        Figure 3: Q-ESP in tunnel mode

   In both the transport and the tunnel mode, the Protocol field of the  outer
   IP header should have a new value indicating that the next protocol is Q-ESP.
   Thus, we should assign a new protocol identifier to Q-ESP protocol.

3.3 Q-ESP Processing

   The same processing steps performed for ESP are performed for Q-ESP, however
   there are some differences. In this draft, we only mention these differences.

3.3.1. Outbound processing

   In the outbound processing, the differences between Q-ESP and ESP processing
   are concerned with Q-ESP header construction and Integrity Check Value (ICV)

Mostafa, et al.                 Expires 06/10                      [Page 6]

INTERNET-DRAFT               draft-mostafa-qesp-00.txt                12/09 Constructing the Q-ESP header

   To construct Q-ESP header, we will copy the first two fields (source and
   destination ports) of the upper layer header protocol (TCP/UDP) at the
   beginning of Q-ESP header. Then, we will put the protocol number of the
   upper layer transmission protocol in the TLP field. Next we set the value
   of the reserved field to zero. After that, we place the security parameter
   index (SPI) obtained from the SA in its field (to tell the receiver how to
   react with this packet); and finally, we increment the sequence number and
   place it at the last field of the header. In this respect, the Q-ESP header
   will contain the following fields: source port number, destination port
   number, TLP, reserved, security parameter index (SPI) and sequence number. Computing the authentication value

   Recall that Q-ESP must authenticate the source and the destination IP
   addresses, to achieve this goal:
   We use the standard authentication algorithm (specified by the SA) such as
   SHA-1 and its associated key to compute the integrity check value according
   to equation 1. Then, we store the computed ICV value in the Q-ESP
   authentication data area.

         ICV = H(MH || P || Src IP || Dst IP, KA)    (1)

   Where, ICV is the integrity check value, H is the keyed-authentication
   algorithm, MH is the Q-ESP header, P is the Q-ESP encrypted payload, and
   the  "Src IP" and "Dst IP" are the the source IP address and the destination
   IP address fields of the external IP header respectively, KA is the
   authentication key, and || is the concatenation symbol.

3.3.2. Inbound processing

   In the inbound processing, the differences between Q-ESP and ESP processing
   exist in sequence number checking and Integrity Check Value (ICV)
   calculation. Checking sequence number

   In Q-ESP, this step is mandatory to prevent replay attacks. If the sequence
   number of the packet is valid (i.e., it is not a duplicate and is not to
   the right of the sequence number window contained in the SA), proceed to
   the next step, otherwise the packet is dropped.

   It is important to note that the window must not be advanced until the
   packet that would cause its advancement has been authenticated. Otherwise,
   an attacker can generate bogus packets with large sequence numbers that
   would move the window outside the range of valid sequence numbers and
   causes valid packets dropping [Dowaswamy and Harkins, 2003]. Verifying the authentication value

   Again, the difference here is in the authentication coverage; use the
   standard authentication algorithm specified by the SA such as SHA-1 and
   its associated key to re-compute the integrity check value (ICV)(using
   equation 1) for the Q-EPS header and its payload, the protocol identifier,
   the source IP address, and the destination IP address fields of the external
   IP header. Then, the result is compared with the value stored in the
   Authentication data area; if they are equal, proceed to the next step, if
   not, drop the packet.

Mostafa, et al.                 Expires 06/10                      [Page 7]

INTERNET-DRAFT               draft-mostafa-qesp-00.txt                12/09

   Actually, we have modified the IPSec kernel implementation of NetBSD version
   5 to implement Q-ESP protocol [Mostafa, Abou El Kalam and Fraboul, 2008;
   2009; 2010]. We tested our implementation and compared its performance with
   ESP protocol. We built two different testbeds and used different scenarios.
   The test results show that, in best effort environment both ESP and Q-ESP
   have almost the same throughput for the same packet size; While in QoS
   managed environment, Q-ESP has the advantage of allowing network control
   devices to perform QoS classification adequately.

4. QoS classification batch

   In order to deploy Q-ESP protocol, a slight software batch is needed to
   be implemented and installed in the currently used network control devices
   (such as routes) that perform QoS classification. The goal of this batch
   is to tell classification algorithm where to find the needed fields to
   perform classification. Actually, the position of these fields differs from
   normal IP packet to Q-ESP protected packet. While the positions of IP source
   and destination addresses are not changed, the position of source and
   destination port numbers are moved to the beginning of the Q-ESP header.
   In addition, the transport layer transfer protocol identifier is placed in
   the TLP field in the Q-ESP header.

5. Possible applications of Q-ESP

   Generally speaking, Q-ESP can be used, instead of  ESP, in all applications
   that need both security and QoS such as VoIP, VoD, satellite data, etc.
   Moreover, Q-ESP can be used on top of MPLS to guarantee the confidentiality
   of client data (as regards ISPs) while ensuring the other security and QoS

   Basically, Q-ESP has the added benefits of facilitating QoS classification,
   allowing active admission control and separating security administrative
   tasks from QoS administrative tasks.
   Now, we could control the security of our data and let internet service
   providers (ISPs) mange only QoS aspects. A Q-ESP packet can be handled
   within different types of QoS domains. It can enter an integrated service
   domain and exit it to enter another differentiated service or MPLS domain.
   The needed information to perform classification is available and the
   security of the packet is guaranteed. Clearly, the priority value of the
   packet could be changed from domain to another depending on the QoS policy
   defined in each domain.

   Current solutions must classify packets and set each packet' priority before
   encrypting it with ESP. Using Q-ESP, we encrypt our packets first before
   sending it to ISPs QoS managed domains; in this way, the packets could be
   easily classified and handled in all domains without any fear regarding its

   Clinet1       Integrated       Differentiated                  Clinet2
   Security --->  service  ----->  service   ----->  MPLS  -----> Security
   Gateway         domain           domain          domain        Gateway

   In addition, if a packet filtering firewall is installed before the VPN
   module (which is common architecture), the packet filtering firewall could
   easily manipulate the packet as the needed fields to perform filtering
   policy is available. In this way we could minimize the possibility of DoS
   attack to the VPN module, as unconcerned packets will be filtered by the

Mostafa, et al.                 Expires 06/10                      [Page 8]

INTERNET-DRAFT              draft-mostafa-qesp-00.txt                 12/09


   Blake, S., Black, D. Carlson, M. Davies, E. Wang, Z. and Weiss, W. (1998)
   'An Architecture for Differentiated Services', RFC 2475.

   Borg, N., Savanberg, E. and Schelen, O. (1999) 'Efficient Multi-Field
   Packet Classification for QoS Purposes', International Workshop on Quality
   of Service, p. 109-118.

   Braden, R., Clark, D. and Shenker, S. (1994) 'Integrated Services in the
   Internet Architecture: an Overview', RFC 1633.

   Bradner, S. (1997) Key words for use in RFCs to Indicate Requirement
   Levels.  RFC 2119.

   Deering, S., Hinden, R. (1998) Internet Protocol, Version 6 (IPv6)
   Specification , RFC 2460.

   Dowaswamy, N. and Harkins, D. (2003) IPSec, 'The New Security Standard
   for the Internet, Intranets, and Virtual Private Networks', Prentice
   Hall PTR.

   Ferguson, N., Schneier, B. (2003) A Cryptographic Evaluation of IPsec,
   Technical report.

   Gupta, P. (2000) 'Algorithms for routing lookups and packet
   classification,'. PhD. Thesis, Stanford University, Stanford, CA.

   Huston, G. (2000) 'Next Steps for the IP QoS Architecture', RFC 2990.

   Kent, S. and Atkinson, R. (1998) 'IP authentication header', RFC 2402.

   Kent, S.  (2005) 'IP Encapsulating security Payload (ESP)', RFC 4303.

   Kent, S. and Atkinson, R. (1998) 'Security architecture for the Internet
   protocol', RFC 2401.

   Mostafa, M., Abou El Kalam, A., Fraboul, C. (2009)   'Q-ESP:
   a QoS-compliant Security Protocol to enrich IPSec Framework'.
   IFIP / IEEE, The Third International Conference on New Technologies,
   Mobility and Security, Cairo, Egypt, 20-23 December 2009.

   Mostafa, M., Abou El Kalam, A., Fraboul, C. (2010)   'A New Protocol
   for Security and QoS in IP Networks',to appear in Int. J. Information
   and Computer Security, Inderscience Publishers, 15 PP.

   Mostafa, M., Abou El Kalam, A., Fraboul, C. (2008) 'EESP: A Security
   Protocol that Supports QoS Management',IEEE  International Conference
   on Risks and Security of Internet and Systems, Tunisie, 28-30 october 2008.

   Nichols, K., Blake, S. Baker, F. and Black, D. (1998) 'Definition of
   the Differentiated Services Field in the IPv4 and IPv6 Headers', RFC 2474.

   Nikov, V. (2006) 'A DoS Attack Against the Integrity-Less ESP (IPSEC)',
   International Conference on Security and Cryptograph, p. 192-199

   Postel, J. (1981) 'Internet Protocol Darpa Internet Program Protocol
   Specification', RFC 791.

   Shenker, S., Wroclawski, J. (1997) 'Network Element Service Specification
   Template', RFC 2216.

   Thi Mai Trang Nguyen T.M. (2003), 'Service Level Negotiation for
   Heterogeneous IP-Based Networks,'. PhD. Thesis, ENST, Paris, France.

Mostafa, et al.                 Expires 06/10                      [Page 9]

INTERNET-DRAFT              draft-mostafa-qesp-00.txt                 12/09

Authors' Addresses

   Mahmoud MOSTAFA, Anas ABOU EL KALAM, Christian FRABOUL
   2 rue Charles Camichel
   B.P. 7122
   F-31071 TOULOUSE Cedex 7
   Voice : +33 5 61 58 80 12
   fax :   +33 5 61 58 83 06
   E-mail: {firstname.lastname}

Mostafa, et al.                 Expires 06/10                     [Page 10]