idnits 2.17.1 draft-mostafa-qesp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 3) being 70 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 162 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There are 29 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 35 has weird spacing: '...ocument auth...' == Line 352 has weird spacing: '... of the outer...' == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'Nguyen' on line 98 looks like a reference -- Missing reference section? '2003' on line 98 looks like a reference -- Missing reference section? 'Postel' on line 107 looks like a reference -- Missing reference section? '1981' on line 107 looks like a reference -- Missing reference section? 'Gupta' on line 125 looks like a reference -- Missing reference section? '2000' on line 139 looks like a reference -- Missing reference section? 'Huston' on line 139 looks like a reference -- Missing reference section? 'Kent' on line 142 looks like a reference -- Missing reference section? '2005' on line 142 looks like a reference -- Missing reference section? 'Bradner' on line 154 looks like a reference -- Missing reference section? '1997' on line 154 looks like a reference -- Missing reference section? 'Nikov' on line 307 looks like a reference -- Missing reference section? '2006' on line 307 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. MOSTAFA 3 INTERNET-DRAFT A. ABOU EL KALAM 4 draft-mostafa-qesp-00.txt C. FRABOUL 5 Date: December 2, 2009 INPT-ENSEEIHT, IRIT-CNRS 6 Expires: June, 2010 8 QoS-friendly Encapsulating Security Payload (Q-ESP) 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with 13 the provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF),its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (c) 2009 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the BSD License. 47 Abstract 49 This document describes a new IPSec protocol called QoS-friendly 50 Encapsulating Security Payload (Q-ESP). Q-ESP provides 51 confidentiality, data origin authentication, anti-reply, 52 connection less integrity, and facilitates QoS active admission 53 control. The currently implemented IPSec Encapsulating Security 54 Payload (ESP) protocol is not QoS friendly as it encrypts the upper 55 layer transmission protocol and prevents network control devices 56 such as routers and switches from utilizing this information in 57 performing classification appropriately. In this document we provide 58 the specification of Q-ESP which gives the same security services 59 provided by ESP, in addition to strong source and destination 60 addresses authentication and its ability to facilitate QoS 61 classification. 63 Table of Contents 65 1 Introduction ......................................................2 67 2 Terminology........................................................3 69 3 Q-ESP: QoS-friendly Encapsulating Security Payload.................3 70 3.1.Q-ESP Packet Format............................................3 71 3.2.Q-ESP Mode of operations.......................................6 72 3.3.Q-ESP Protocol Processing......................................6 74 4 QoS classification batch..........................................8 76 5 Possible applications of Q-ESP....................................8 78 References..............................................................9 80 Authors Information....................................................10 82 1. Introduction 84 The Internet has become essential for information exchange. Various 85 activities are carried out via the Internet: between companies (B2B), 86 among businesses and consumers (B2C), or between individuals who 87 create their own virtual communities (e.g., P2P). This clearly causes 88 a huge demand for the network bandwidth. Moreover, many real-time 89 applications such as video conferencing and Voice over Internet 90 Protocol (VoIP) have been developed. These types of traffic-demanding 91 applications suffer greatly from congestion and delay. Thus, there is 92 a great need to find methods and mechanisms to manipulate traffic more 93 efficiently according to their needs. Quality of service (QoS) has 94 emerged to deal with this kind of problem. Basically, it refers to the 95 nature of packet delivery service provided, as described by parameters 96 such as bandwidth, delay, jitter, and packet loss [Shenker and 97 Wroclawski, 1997]. The way of classifying traffic and providing QoS 98 levels defines different QoS architectures [Nguyen, 2003]. Mainly, we 99 distinguish two standard QoS architectures: Integrated service [Braden, 100 Clark and Shenker, 1994] and Differentiated service [Blake, Black, 101 Carlson, Davies, Wang and Weiss, 1998]. 103 Actually, in the QoS field, the "Class of Service"concept divides the 104 network traffic into different classes and provides a class-dependent 105 service to each packet (depending on which class it belongs to). 106 To classify packets, each packet is assigned a priority value. The 107 latter is stored in the "Type of Service" (ToS)[Postel, 1981] field 108 in the IPv4 header (also called "Traffic Class" in IPv6) [Deering and 109 Hinden, 1998]. In the differentiated service architecture, this priority 110 value is called Differentiated service code point (DSCP) [Nichols, Blake, 111 Baker and Black, 1998].However, it is obvious that allowing the sending 112 device to classify traffic or to set traffic priorities may be subject 113 to threats, as the sender may classify his traffic in a way that gives 114 him upper priorities. This is clearly the disadvantage of what is 115 called passive admission control. Conversely, service providers perform 116 active admission control by allowing edge routers (neither users nor the 117 sending devices) to inspect the incoming traffic and classify it. 118 Note that in both architectures (the differentiated service and 119 integrated service), the packet classifier component inspects incoming 120 packets and classifies them. As the classifier inspects multiple fields 121 in the packet, it is called Multi-Field (MF) classifier [Borg, Savanberg 122 and Schelen, 1999]. 124 Actually, the fields needed to be inspected belong to different network 125 layer headers [Gupta, 2000]: 127 _Transport Layer Protocol Header: the MF packet classifier inspects 128 two fields of the transport layer protocol (TCP/UDP) header, the source 129 and destination port numbers; these fields naturally help to identify 130 the applications running over TCP/UDP. 132 _Network Layer Protocol Header: three fields are inspected at this 133 layer, the source host IP address that helps to identify the sending 134 host, the destination host IP address, which helps to identify the 135 end-system receiving the data, and the protocol identifier that is used 136 to identify the transport-layer protocol in use. 138 The previously mentioned five fields are used to define the traffic flow 139 [Huston, 2000]. However, even if these fields are required for QoS 140 processing, some of them are unfortunately hidden (encrypted) when 141 using security protocols such as IPSec [Kent and Atkinson, 1998] ESP 142 [Kent, 2005]. 144 To solve this problem, we propose a new security protocol the 145 "QoS-friendly Encapsulated Security Payload (Q-ESP)". Not only Q-ESP 146 provides stronger security protection but also supports QoS active 147 admission control. 149 2. Terminology 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in [Bradner, 1997]. 155 3 Q-ESP: QoS-friendly Encapsulating Security Payload 157 3.1. QoS friendly Encapsulating Security Payload(Q-ESP) packet format 159 The major aim of the Q-ESP protocol is to construct packets that are QoS 160 controllable according to active admission control. 162 In addition to security services provided by the IPSec ESP (i.e. Data 163 origin authentication, Anti-reply integrity, connectionless integrity and 164 confidentiality), Q-ESP supports QoS by providing the necessary and 165 sufficient information for the controlling devices to enable them 166 performing active admission control. 168 Besides that, Q-ESP prevents replay attacks. In fact, while the anti-reply 169 function is optional in ESP and AH [Kent and Atkinson, 1998], it is 170 mandatory in Q-ESP. In addition, while authentication is optional in ESP, 171 it is mandatory in Q-ESP as it prevents against attacks that form malicious 172 packet from valid IP and ESP headers but with invalid payload (which will 173 be discarded later after doing the most resource intensive process of 174 decryption). Moreover, Q-ESP authentication provides data origin 175 authentication (as it covers the source and destination addresses fields 176 of the outer IP-header). 178 Figure 1 depicts the structures of Q-ESP in IP versions 4 and 6. 179 An Q-ESP packet contains eight additional octets. Like ESP, the structure 180 of Q-ESP is composed of the header, the payload, the trailer, and the 181 authentication data area. All the fields of the Q-ESP packet are described 182 below. 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | IP Header | 186 ~ ~ 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----- 188 | IP header Source IP Address | ^ 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | 190 | IP header Destination IP Address | | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | 192 | | | 193 0 1 2 3 | | 194 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 | | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| Authent- 196 | Source Port | Destination Port | ication 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| Coverage 198 | TLP | Reserved | | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | 200 | Security Parameters Index (SPI) | | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | 202 | Sequence Number | | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | ------- 204 | Payload Data* (variable) | | ^ 205 ~ ~ | | 206 | | | Confid- 207 + -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ | | entiality 208 | | Padding (0-255 bytes) | | Coverage 209 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | 210 | | Pad Length | Next Header| v v 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|----------- 212 | Authentication Data (variable) | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 Figure 1: Q-ESP packet format 217 3.1.1 The Q-ESP header 219 The Q-ESP header contains a Security Parameters Index and a Sequence Number. 221 In addition, to cope with QoS requirements, we copy the first two fields 222 (source and destination ports) of the upper layer transfer protocols and 223 place them in clear (without encryption) in the Q-ESP header. Also, the 224 value of the transport layer protocol is recorded in the TLP field; This 225 clearly allows MF packet classifier to perform efficient packet 226 classification. In this respect, the Q-ESP header includes the following 227 six fields: 229 3.1.1.1 Source Port 231 This is a 16-bit fixed-length field; it contains the first field of the 232 upper layer transport protocol (TCP/UDP) source port number; this field is 233 needed to be in clear to enable network edge routers to check traffic and 234 set priorities. 236 3.1.1.2 Destination Port 238 This is also a 16-bit fixed-length field; it contains the second field of 239 the upper layer transport protocol (TCP/UDP) destination Port number; as 240 the source port, this field is also needed to be in clear to enable network 241 edge routers to check traffics and set priorities. 243 3.1.1.3 Transmission Layer Protocol (TLP) 245 This is an 8-bit fixed-length field that indicates the protocol of the 246 transport layer. 248 The previously mentioned three fields (Source Port, Destination Port and 249 TLP) are used with IP source and destination addresses to identify traffic 250 flow. 252 3.1.1.4 Reserved 254 This is a 24-bit fixed-length field that is not used (reserved for future 255 uses) and must be set to zero. 257 3.1.1.5 Security Parameters Index 259 This is an arbitrary 32-bit fixed length identifier that in combination with 260 the destination address and security protocol (Q-ESP) uniquely identifies the 261 security association (SA) in use. 263 3.1.1.6 Sequence Number 265 This is an unsigned 32 bit field. It is a monotonically increasing ID that is 266 used to detect replay attacks. This value is authenticated, so that malicious 267 or accidental modifications could be detected. 269 3.1.2 The Q-ESP payload 271 The payload encrypts the upper layer transport protocol and its payload data 272 in transport mode, while in tunnel mode it encrypts the entire original IP 273 packet including its header. 275 3.1.3 The Q-ESP trailer 277 The Q-ESP trailer includes the Padding, the pad length field and the Next 278 Header field. 280 3.1.3.1 Padding 282 This is provided to allow block-oriented encryption algorithms area for 283 multiples of their block size. 285 3.1.3.2 Pad length 287 This is an 8-bit fixed-length field that indicates the length of the 288 included pad. 290 3.1.3.3 Next Header 292 This is a mandatory, 8-bit fixed-length field that points backward to refer 293 to the type of the protocol (IP, TCP, UDP, etc.) in the encrypted payload. 295 3.1.4. Authentication data area 297 It is a variable length area that is used to store the Integrity check 298 value (ICV). The Integrity Check Value (ICV) is calculated over the 299 Q-ESP headers and the Payload. In Q-ESP, to inherit the capability of AH, 300 we also apply the authentication algorithm over the source IP address 301 and destination IP address fields of the IP header. 302 However, unlike AH, we think that authenticating the rest of the IP header 303 fields is meaningless as they will be used before the packet reaches the 304 IPSec layer (i.e. before verifying their integrity); therefore, any change 305 in their values will not affect the IPSec processing. 306 Besides, in Q-ESP, both authentication and encryption are mandatory. 307 Actually,authentication helps to prevent DoS attacks [Nikov, 2006]. 308 Moreover,implementing authentication with encryption provides in 309 depth-defense if the encryption secret key is corrupted; in fact even 310 if the attacker succeeds in reading the content of the payload, 311 he will not be able to alter its content. 313 3.2. Q-ESP Mode of operations 315 Q-ESP must be supported in both transport and tunnel mode. We now 316 Show the Q-ESP transport mode for a typical IPv4 packet. 318 IP PACKET BEFORE APPLYING Q-ESP 320 ---------------------------- 321 | IP | TCP | Data | 322 ---------------------------- 324 AFTER APPLYING Q-ESP IN TRANSPORT MODE 326 <-----Q-ESP header------> 327 ------------------------------------------------------------------- 328 | IP ~ Src|Dst |Src |Dst |TLP| |SPI|Seq|TCP|Data| Q-ESP | Q-ESP | 329 |header| IP@|IP@ |Port|Port| | | | # | | |trailer| Auth | 330 ------------------------------------------------------------------- 331 <-> <---Encrypted----> 332 Reserved 333 <---------------------Authenticated----------------> 335 Figure 2: Q-ESP in transport mode 337 We now show the Q-ESP tunnel mode for a typical Ipv4 packet. 339 AFTER APPLYING Q-ESP IN TUNNEL MODE 341 <-----Q-ESP header------> 342 ---------------------------------------------------------------------------- 343 |Outer IP ~ Src|Dst |Src |Dst |TLP| |SPI|Seq|inner|TCP|Data| Q-ESP | Q-ESP | 344 | header | IP@|IP@ |Port|Port| | | | # | IP | | |trailer| Auth | 345 ---------------------------------------------------------------------------- 346 <-> <-------Encrypted------> 347 Reserved 348 <---------------------Authenticated---------------------> 350 Figure 3: Q-ESP in tunnel mode 352 In both the transport and the tunnel mode, the Protocol field of the outer 353 IP header should have a new value indicating that the next protocol is Q-ESP. 354 Thus, we should assign a new protocol identifier to Q-ESP protocol. 356 3.3 Q-ESP Processing 358 The same processing steps performed for ESP are performed for Q-ESP, however 359 there are some differences. In this draft, we only mention these differences. 361 3.3.1. Outbound processing 363 In the outbound processing, the differences between Q-ESP and ESP processing 364 are concerned with Q-ESP header construction and Integrity Check Value (ICV) 365 Calculation. 367 3.3.1.1: Constructing the Q-ESP header 369 To construct Q-ESP header, we will copy the first two fields (source and 370 destination ports) of the upper layer header protocol (TCP/UDP) at the 371 beginning of Q-ESP header. Then, we will put the protocol number of the 372 upper layer transmission protocol in the TLP field. Next we set the value 373 of the reserved field to zero. After that, we place the security parameter 374 index (SPI) obtained from the SA in its field (to tell the receiver how to 375 react with this packet); and finally, we increment the sequence number and 376 place it at the last field of the header. In this respect, the Q-ESP header 377 will contain the following fields: source port number, destination port 378 number, TLP, reserved, security parameter index (SPI) and sequence number. 380 3.3.1.2: Computing the authentication value 382 Recall that Q-ESP must authenticate the source and the destination IP 383 addresses, to achieve this goal: 384 We use the standard authentication algorithm (specified by the SA) such as 385 SHA-1 and its associated key to compute the integrity check value according 386 to equation 1. Then, we store the computed ICV value in the Q-ESP 387 authentication data area. 389 ICV = H(MH || P || Src IP || Dst IP, KA) (1) 391 Where, ICV is the integrity check value, H is the keyed-authentication 392 algorithm, MH is the Q-ESP header, P is the Q-ESP encrypted payload, and 393 the "Src IP" and "Dst IP" are the the source IP address and the destination 394 IP address fields of the external IP header respectively, KA is the 395 authentication key, and || is the concatenation symbol. 397 3.3.2. Inbound processing 399 In the inbound processing, the differences between Q-ESP and ESP processing 400 exist in sequence number checking and Integrity Check Value (ICV) 401 calculation. 403 3.3.2.1: Checking sequence number 405 In Q-ESP, this step is mandatory to prevent replay attacks. If the sequence 406 number of the packet is valid (i.e., it is not a duplicate and is not to 407 the right of the sequence number window contained in the SA), proceed to 408 the next step, otherwise the packet is dropped. 410 It is important to note that the window must not be advanced until the 411 packet that would cause its advancement has been authenticated. Otherwise, 412 an attacker can generate bogus packets with large sequence numbers that 413 would move the window outside the range of valid sequence numbers and 414 causes valid packets dropping [Dowaswamy and Harkins, 2003]. 416 3.3.2.2: Verifying the authentication value 418 Again, the difference here is in the authentication coverage; use the 419 standard authentication algorithm specified by the SA such as SHA-1 and 420 its associated key to re-compute the integrity check value (ICV)(using 421 equation 1) for the Q-EPS header and its payload, the protocol identifier, 422 the source IP address, and the destination IP address fields of the external 423 IP header. Then, the result is compared with the value stored in the 424 Authentication data area; if they are equal, proceed to the next step, if 425 not, drop the packet. 427 Actually, we have modified the IPSec kernel implementation of NetBSD version 428 5 to implement Q-ESP protocol [Mostafa, Abou El Kalam and Fraboul, 2008; 429 2009; 2010]. We tested our implementation and compared its performance with 430 ESP protocol. We built two different testbeds and used different scenarios. 431 The test results show that, in best effort environment both ESP and Q-ESP 432 have almost the same throughput for the same packet size; While in QoS 433 managed environment, Q-ESP has the advantage of allowing network control 434 devices to perform QoS classification adequately. 436 4. QoS classification batch 438 In order to deploy Q-ESP protocol, a slight software batch is needed to 439 be implemented and installed in the currently used network control devices 440 (such as routes) that perform QoS classification. The goal of this batch 441 is to tell classification algorithm where to find the needed fields to 442 perform classification. Actually, the position of these fields differs from 443 normal IP packet to Q-ESP protected packet. While the positions of IP source 444 and destination addresses are not changed, the position of source and 445 destination port numbers are moved to the beginning of the Q-ESP header. 446 In addition, the transport layer transfer protocol identifier is placed in 447 the TLP field in the Q-ESP header. 449 5. Possible applications of Q-ESP 451 Generally speaking, Q-ESP can be used, instead of ESP, in all applications 452 that need both security and QoS such as VoIP, VoD, satellite data, etc. 453 Moreover, Q-ESP can be used on top of MPLS to guarantee the confidentiality 454 of client data (as regards ISPs) while ensuring the other security and QoS 455 services. 457 Basically, Q-ESP has the added benefits of facilitating QoS classification, 458 allowing active admission control and separating security administrative 459 tasks from QoS administrative tasks. 460 Now, we could control the security of our data and let internet service 461 providers (ISPs) mange only QoS aspects. A Q-ESP packet can be handled 462 within different types of QoS domains. It can enter an integrated service 463 domain and exit it to enter another differentiated service or MPLS domain. 464 The needed information to perform classification is available and the 465 security of the packet is guaranteed. Clearly, the priority value of the 466 packet could be changed from domain to another depending on the QoS policy 467 defined in each domain. 469 Current solutions must classify packets and set each packet' priority before 470 encrypting it with ESP. Using Q-ESP, we encrypt our packets first before 471 sending it to ISPs QoS managed domains; in this way, the packets could be 472 easily classified and handled in all domains without any fear regarding its 473 security. 475 Clinet1 Integrated Differentiated Clinet2 476 Security ---> service -----> service -----> MPLS -----> Security 477 Gateway domain domain domain Gateway 479 In addition, if a packet filtering firewall is installed before the VPN 480 module (which is common architecture), the packet filtering firewall could 481 easily manipulate the packet as the needed fields to perform filtering 482 policy is available. In this way we could minimize the possibility of DoS 483 attack to the VPN module, as unconcerned packets will be filtered by the 484 firewall. 486 References 488 Blake, S., Black, D. Carlson, M. Davies, E. Wang, Z. and Weiss, W. (1998) 489 'An Architecture for Differentiated Services', RFC 2475. 491 Borg, N., Savanberg, E. and Schelen, O. (1999) 'Efficient Multi-Field 492 Packet Classification for QoS Purposes', International Workshop on Quality 493 of Service, p. 109-118. 495 Braden, R., Clark, D. and Shenker, S. (1994) 'Integrated Services in the 496 Internet Architecture: an Overview', RFC 1633. 498 Bradner, S. (1997) Key words for use in RFCs to Indicate Requirement 499 Levels. RFC 2119. 501 Deering, S., Hinden, R. (1998) Internet Protocol, Version 6 (IPv6) 502 Specification , RFC 2460. 504 Dowaswamy, N. and Harkins, D. (2003) IPSec, 'The New Security Standard 505 for the Internet, Intranets, and Virtual Private Networks', Prentice 506 Hall PTR. 508 Ferguson, N., Schneier, B. (2003) A Cryptographic Evaluation of IPsec, 509 Technical report. 511 Gupta, P. (2000) 'Algorithms for routing lookups and packet 512 classification,'. PhD. Thesis, Stanford University, Stanford, CA. 514 Huston, G. (2000) 'Next Steps for the IP QoS Architecture', RFC 2990. 516 Kent, S. and Atkinson, R. (1998) 'IP authentication header', RFC 2402. 518 Kent, S. (2005) 'IP Encapsulating security Payload (ESP)', RFC 4303. 520 Kent, S. and Atkinson, R. (1998) 'Security architecture for the Internet 521 protocol', RFC 2401. 523 Mostafa, M., Abou El Kalam, A., Fraboul, C. (2009) 'Q-ESP: 524 a QoS-compliant Security Protocol to enrich IPSec Framework'. 525 IFIP / IEEE, The Third International Conference on New Technologies, 526 Mobility and Security, Cairo, Egypt, 20-23 December 2009. 528 Mostafa, M., Abou El Kalam, A., Fraboul, C. (2010) 'A New Protocol 529 for Security and QoS in IP Networks',to appear in Int. J. Information 530 and Computer Security, Inderscience Publishers, 15 PP. 532 Mostafa, M., Abou El Kalam, A., Fraboul, C. (2008) 'EESP: A Security 533 Protocol that Supports QoS Management',IEEE International Conference 534 on Risks and Security of Internet and Systems, Tunisie, 28-30 october 2008. 536 Nichols, K., Blake, S. Baker, F. and Black, D. (1998) 'Definition of 537 the Differentiated Services Field in the IPv4 and IPv6 Headers', RFC 2474. 539 Nikov, V. (2006) 'A DoS Attack Against the Integrity-Less ESP (IPSEC)', 540 International Conference on Security and Cryptograph, p. 192-199 542 Postel, J. (1981) 'Internet Protocol Darpa Internet Program Protocol 543 Specification', RFC 791. 545 Shenker, S., Wroclawski, J. (1997) 'Network Element Service Specification 546 Template', RFC 2216. 548 Thi Mai Trang Nguyen T.M. (2003), 'Service Level Negotiation for 549 Heterogeneous IP-Based Networks,'. PhD. Thesis, ENST, Paris, France. 551 Authors' Addresses 553 Mahmoud MOSTAFA, Anas ABOU EL KALAM, Christian FRABOUL 554 ENSEEIHT - IRIT 555 2 rue Charles Camichel 556 B.P. 7122 557 F-31071 TOULOUSE Cedex 7 558 France 559 Voice : +33 5 61 58 80 12 560 fax : +33 5 61 58 83 06 561 E-mail: {firstname.lastname}@enseeiht.fr