L3VPN Working Group Bhargav Bhikkaji Internet-draft Balaji Venkat Venkataswami Intended Status:Experimental RFC Dell-Force10 Expires: August 2012 March 2, 2012 Preventing spoofing attacks in BGP-MPLS-VPN Inter-Provider Model-C draft-bhargav-l3vpn-inter-provider-optcsec-03 Abstract In certain models of inter-provider Multi-Protocol-Label-Switching based Virtual Private Networks (MPLS-VPNs), spoofing attacks against VPN sites is a key concern. Unidirectional attacks towards VPN sites can compromise servers at the VPN sites and cause Denial-of-Service (DoS) situations. Currently, the inner labels associated with VPN sites are not encrypted during transmission. The Provider Edge (PE) router at the end to which the VPN customer is attached accepts any data packet with a valid label. This enables a man-in-the-middle attacker to spoof a packet to a specific site of a VPN. In this paper, we propose some secure techniques which provide security against such label-spoofing. These techniques ensure that an attacker would not be able to spoof labeled data packets. In order to make the proposed scheme robust, some additional steps are proposed over and above the initial steps specified. This makes the attacker to spend non-linear time to guess the right label for his unidirectional attacks to succeed. Our proposed technique can be applied to a specific type of inter-provider Border Gateway Protocol(BGP) based MPLS VPN and other existing variant where Multi-Protocol exterior- BGP (MP-eBGP) multi-hop is used. In future, if any other variant is proposed to use MP-eBGP multi-hop, our scheme can be used to protect against spoofing attacks. 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-Drafts. Bhargav.B et.al Expires August 2012 [Page 1] INTERNET DRAFT Securing Inter-provider MPLS-VPN Model-C February 2012 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2012 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 (http://trustee.ietf.org/license-info) 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 Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Security issue in model C . . . . . . . . . . . . . . . . . 5 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Methodology of the Proposal . . . . . . . . . . . . . . . . . 6 2.1 Solution:1 . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.1 Control Plane operation . . . . . . . . . . . . . . . . 7 2.1.2 Data-Plane Operation . . . . . . . . . . . . . . . . . . 8 2.1.3 Mapping a hash to a 20 bit value . . . . . . . . . . . . 9 2.2 Solution:2 . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2.1 Control Plane operation . . . . . . . . . . . . . . . . 9 2.2.2 Data-Plane Operation . . . . . . . . . . . . . . . . . . 10 2.3 Use Case:1 . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.4 Use Case:2 (RSVP can use this during tunnel setup) . . . . . 11 2.5 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.6 Limitations . . . . . . . . . . . . . . . . . . . . . . . . 12 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 13 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 13 Bhargav.B et.al Expires August 2012 [Page 2] INTERNET DRAFT Securing Inter-provider MPLS-VPN Model-C February 2012 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1 Normative References . . . . . . . . . . . . . . . . . . . 13 5.2 Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Bhargav.B et.al Expires August 2012 [Page 3] INTERNET DRAFT Securing Inter-provider MPLS-VPN Model-C February 2012 1 Introduction MPLS technology helps forward data packets in the Internet using fixed-size labels [3]. By stacking labels (label-stacking technique), specific customer services such as layer 3 VPNs based on BGP extensions are widely deployed in the Internet. BGP based MPLS layer 3 VPN services are provided either on a single internet service provider (ISP) core or across multiple ISP cores. The latter cases are known as inter-provider MPLS VPNs which are broadly categorized and referred to as models: A, B and C. Model A uses back-to-back VPN Routing and Forwarding (VRF) connections between Autonomous System Border Routers (ASBRs). Model B uses eBGP redistribution of labelled VPN-IPv4 routes from AS to neighbouring AS. Model C uses multi-hop eBGP redistribution of labelled VPNIPv4 routes and eBGP redistribution of IPv4 routes from AS to neighbouring AS. Please refer [1] for more details. A. Security issues in inter-provider VPN models Model A is as secure a standard as the single-Autonomous System (AS) standard proposed in [5]. Model B can be secured well on the control plane, but on the data-plane the top-most label is not checked for validity. This weakness could be exploited to inject crafted packets from inside an MPLS core into the other. There is a work-around discussed in [1] that solves the problem. Model C can also be secured well on the control plane. But as the ASBRs do not have any VPN information and the inner-most label cannot be validated, the data-plane has architectural weakness with respect to security. This enables unidirectional packets to be sent into the VPN sites connected to the other AS, which cannot be protected against by mere configuration. Model C can therefore only be deployed where service providers trust each other. For more details refer to [1]. In [2] the authors propose encryption techniques, such as IPSec, for securing the provider edge (PE) to PE legs of the network. However the authors also highlight that the processing capacity could be over-burdened. If an attacker is located at the core of the network, or in the intermediate link or network between the providers that constitute a inter-provider MPLS VPN solution, then spoofing attacks are possible. In case an attacker spoofs the inner labels that identify packets going towards a L3 VPN site, sensitive information related to services available within the organizational servers can be compromised. A denial-of-service (DoS) attack could also be launched against these sensitive sites. As far as we know, there is no scheme adopting encryption available for installing an anti- spoofing mechanism for these VPN service labels. The proposed scheme in this document provides an alternative in case other schemes that dont adopt encryption are not suitable. The PEs at the end to which the VPN customer is attached will accept any packet with a valid label and will forward it to the VPN customer. There is no way to Bhargav.B et.al Expires August 2012 [Page 4] INTERNET DRAFT Securing Inter-provider MPLS-VPN Model-C February 2012 ensure the veracity of a spoofed packet. 1.1 Security issue in model C The deficiency discussed above is particularly true in the case of inter-provider BGP based MPLS VPN model C. Even though model C is highly scalable for carrying VRF routes, the vulnerability of the data-plane has rendered it unusable and the current recommendation is that model C must not be used. As discussed in [1] the insecurity for model C stems from the fact that anybody within the core of the network or at the peering points of the providers can cause DoS attacks or worm attacks. It is possible to filter all IP traffic with the exception of the required eBGP peering between the AS border routers thereby preventing a large number of potential IP traffic related attacks. Labelled packets, however, are much harder to control. In model C, there are at least two labels for each packet: the PE label, which defines the Label Switched Path (LSP) to the egress PE, and the VPN label, which defines the VPN on the PE to which the packet is associated. 1.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 RFC 2119 [RFC2119]. Bhargav.B et.al Expires August 2012 [Page 5] INTERNET DRAFT Securing Inter-provider MPLS-VPN Model-C February 2012 2. Methodology of the Proposal Consider a setup as below The reference MPLS-eBGP based VPN network for model-C / Option-C as described in [11] is shown in Figure 1, which also shows the control plane exchanges. The near-end PE (PE_ne) and far-end PE (PE_fa) are connected through the inter-provider MPLS core. The VPN connectivity is established through a set of routers from different Autonomous Systems (AS) and their ASBRs. In the VPN, MP-eBGP updates are exchanged for a set of Forward Equivalence Classes (FECs). These FECs, which have to be protected, originate from the prefixes behind PE_ne in a VPN site or a set of VPN sites. _______[AB1]________________ ___________[AB2]___________ ( / | ) ( / \ ) ( / +-----------+ ) ( / \ ) ( Net:PE_ne Net:PE_ne ) ( Net:PE_ne Net:PE_ne ) ( LDP Label:POP LDP Label:L1 ) (LDP Label:L3 LDP Label:L4) ( | | ) ( | | ) ( | | ) ( | | ) [CE1]<-[PE_ne]__________[ASBR1]<---->[ASBR2]_________________[PE_fa] | 172.18.10.0/24 NH:PE_ne 172.18.20.0/24 [CE2] VPN Label: Inner Label IL1 For the example below we refer to PE_ne and PE_fa in the diagram as PE-1 and PE-2. 1) PE-1 and PE-2 would establish a MPeBGP-VPNV4 session between them 2) PE-1 and PE-2 will exchange VPN-labels for the prefixes (FECs) between them which are to be used during forwarding 3) This mechanism does not avoid an attacker who is trying to spoof a packet from somewhere inside the core or from within the network between the two ISP / provider networks. There are 2 ways to solve this problem Bhargav.B et.al Expires August 2012 [Page 6] INTERNET DRAFT Securing Inter-provider MPLS-VPN Model-C February 2012 2.1 Solution:1 2.1.1 Control Plane operation 1) PE-1 and PE-2 agree upon looking for a "Secure Label" in addition to the VPN label 2) PE-1 and PE-2 use PKI and publish their respective public keys. _______[AB1]________________ ___________[AB2]___________ ( / | ) ( / \ ) ( / +-----------+ ) ( / \ ) ( Net:PE_ne Net:PE_ne ) ( Net:PE_ne Net:PE_ne ) ( LDP Label:POP LDP Label:L1 ) (LDP Label:L3 LDP Label:L4) ( | | ) ( | | ) ( | | ) ( | | ) [CE1]<-[PE_ne]__________[ASBR1]<---->[ASBR2]__________[PE_fa]-->[CE2] ^ ^ +-------------- MP-eBGP IPVPN-V4 session --------------+ Figure 2:PKI exchange to exchange their respective public keys. 3) PE-1 and PE-2 also agree upon a universal hashing algorithm to use. It could be any of standard universal hashing algorithms which minimize collisions to the maximum extent possible. They also agree upon a bitmask that is to be used in step 5.1. These could be exchanged using the MP-eBGP label exchange mechanism using suitable fields which will be discussed in the appendix A.1 to be added later. 4) Unlike the VPN label that is exchanged as part of the MPBGP-VPNV4 exchange, the "Secure Label" is generated on the fly during forwarding. _______[AB1]________________ ___________[AB2]___________ ( / | ) ( / \ ) ( / +-----------+ ) ( / \ ) ( Net:PE_ne Net:PE_ne ) ( Net:PE_ne Net:PE_ne ) ( LDP Label:POP LDP Label:L1 ) (LDP Label:L3 LDP Label:L4) ( | | ) ( | | ) ( | | ) ( | | ) [CE1]<-[PE_ne]__________[ASBR1]<---->[ASBR2]__________[PE_fa]-->[CE2] ^ ^ +-------------- MP-eBGP IPVPN-V4 session --------+ 172.18.10.0/24 (4) NH:PE_ne 172.18.20.0/24 VPN Label: Inner Label IL1 Universal hashing Algorithm: UA1, Bitmask: B1 5) Secure labels are generated for prefixes reachable via PE-1 by PE-2 Bhargav.B et.al Expires August 2012 [Page 7] INTERNET DRAFT Securing Inter-provider MPLS-VPN Model-C February 2012 5.1) PE-2 takes a hash on the first 256 bytes of the packet's payload received using the universal hashing algorithm agreed upon. If the PEs are from the same vendor or from a different vendor the algorithm to be used is expressed in a standard identifier which is understood by both PEs. 5.2) Take any 20 bits from the hash using a bitmask that is also shared amongst the two PEs. 5.3) Take this 20 bit value and encrypt with the private key of PE-2 if traffic is flowing from PE-2 to PE-1. The inner label, universal hashing algorithm and the bitmask are sent from PE-1 to PE-2 for prefixes reachable via PE-1. Steps 5.1 to 5.3 are done as part of data plane operations which are explained below. 2.1.2 Data-Plane Operation _______[AB1]________________ ___________[AB2]___________ ( / | ) ( / \ ) ( / +-----------+ ) ( / \ ) (IL1:SL:172.18.10.1 L1:IL1:SL:172.18.10.1 / \ ) ( | L3:IL1:SL:172.18.10.1 <-+ L4:IL1:SL:172.18.10.1) ( | | ) ( | | ) ( | | ) ( | | ) [CE1]<-[PE_ne]__________[ASBR1]<---->[ASBR2]__________[PE_fa]-->[CE2] 172.18.10.0/24 L2:IL1:SL:172.18.10.1 172.18.20.0/24 1) Let us assume a customer connected to PE-2 is sending a packet to PE-1 2) The packet could be any payload encapsulated in the MPLS header having the usual stack of labels for MODEL-C 3) When the packet reaches PE-2, following operation is done 3.1) Generate a hash of the received packet using the universal hashing algorithm chosen. 3.2) Take agreed 20 bits from the hash using the bitmask exchanged. (Text below talks about what 20 bits to take) 3.3) Encrypt those 20 bits with PE-2's private key 3.4) Send the packet with VPN label on top of the secure label 4) When the packet reaches PE-1, following operation is done 4.1) Generate a hash on the 256 bytes of data after the secured Bhargav.B et.al Expires August 2012 [Page 8] INTERNET DRAFT Securing Inter-provider MPLS-VPN Model-C February 2012 label 4.2) Take agreed 20 bits using the bitmask agreed upon after hash calculation in #4.1, call it 'K' 4.3) Decrypt received secured-label using public key of PE-1 4.4) Check if decrypted secured label and K are same. 4.5) If both are same then forward the packet otherwise drop it 2.1.3 Mapping a hash to a 20 bit value 1) The universal hashing algorithm selected generates a 128 bit value but a MPLS label is 20 bit value 2) A mechanism is necessary to map 128 bits to a 20 bit value 3) PE-1 and PE-2 would exchange a 128 bitmask which is used to convey which 20 bits in that 128 bits is to be used for the purposes of encryption 4) This bitmask / bitmap is generated randomly and exchanged at the time of MP-eBGP NLRI exchanges and expires every t seconds. 5) Whenever a new bitmap is generated, this would be shared between the PE's 2.2 Solution:2 2.2.1 Control Plane operation _______[AB1]________________ ___________[AB2]___________ ( / | ) ( / \ ) ( / +-----------+ ) ( / \ ) ( Net:PE_ne Net:PE_ne ) ( Net:PE_ne Net:PE_ne ) ( LDP Label:POP LDP Label:L1 ) (LDP Label:L3 LDP Label:L4) ( | | ) ( | | ) ( | | ) ( | | ) [CE1]<-[PE_ne]__________[ASBR1]<---->[ASBR2]__________[PE_fa]-->[CE2] ^ ^ +-------------- MP-eBGP IPVPN-V4 session --------------+ (1) PKI exchange to exchange their respective public keys. 1) PE-1 and PE-2 use PKI and publish their respective public keys. 2) PE-1 and PE-2 agree upon looking for a digital signature below Bhargav.B et.al Expires August 2012 [Page 9] INTERNET DRAFT Securing Inter-provider MPLS-VPN Model-C February 2012 the EOS label.This would be done with an appropriate indicator in the MP-eBGP update which would tell the other PE (far-end PE) that a digital signature mechanism is to be used for purposes of protecting the payload / stream between the two PEs. _______[AB1]________________ ___________[AB2]___________ ( / | ) ( / \ ) ( / +-----------+ ) ( / \ ) ( Net:PE_ne Net:PE_ne ) ( Net:PE_ne Net:PE_ne ) ( LDP Label:POP LDP Label:L1 ) (LDP Label:L3 LDP Label:L4) ( | | ) ( | | ) ( | | ) ( | | ) [CE1]<-[PE_ne]__________[ASBR1]<---->[ASBR2]__________[PE_fa]-->[CE2] ^ ^ +-------------- MP-eBGP IPVPN-V4 session --------+ 172.18.10.0/24 (4) NH:PE_ne 172.18.20.0/24 VPN Label: Inner Label IL1 Universal hashing Algorithm: UA1, Digital Signature mechanism 3) PE-1 and PE-2 also agree upon what universal hashing algorithm to use. 4) Digital signature is generated as follows 4.1) First take a hash on the first 256 bytes of the packet received 4.2) Encrypt with private key available for the transaction. 2.2.2 Data-Plane Operation _______[AB1]________________ ___________[AB2]___________ ( / | ) ( / \ ) ( / +-----------+ ) ( / \ ) (IL1:DS:172.18.10.1 L1:IL1:DS:172.18.10.1 / \ ) ( | L3:IL1:DS:172.18.10.1 <-+ L4:IL1:DS:172.18.10.1) ( | | ) ( | | ) ( | | ) ( | | ) [CE1]<-[PE_ne]__________[ASBR1]<---->[ASBR2]__________[PE_fa]-->[CE2] 172.18.10.0/24 L2:IL1:DS:172.18.10.1 172.18.20.0/24 1) Let us assume a customer connected to PE-1 is sending a packet to PE-2 2) The packet could be any payload encapsulated in the MPLS header having a stack of labels for MODEL-C Bhargav.B et.al Expires August 2012 [Page 10] INTERNET DRAFT Securing Inter-provider MPLS-VPN Model-C February 2012 3) When the packet reaches PE-1, following operation is done 3.1) Generate a hash of the received packet involving the first 256 bytes of the packet. 3.2) Encrypt the hash with private key of PE-1. 3.3) Add these encrypted 128 bits below EOS label 3.4) Send the packet with VPN label and with encrypted digital signature below EOS label 4) When the packet reaches PE-2, following operation is done 4.1) Based on the VPN label, PE-2 knows that it needs to look for a digital signature below EOS label 4.2) Remove 128 bit digital signature below EOS label 4.3) Calculate a hash after removing the digital signature, call it 'J' 4.4) Decrypt the received digital signature with public key of PE-1, Call it 'K' 4.5) compare the J and K. If they are equal, forward the packet else drop it. Note: 1) For both solutions, hash is calculated only before slapping VPN label at PE-1, ie TTL update gets over by then 2) In case of Solution 2, to support ECMP case, we could add one nibble extra in front of the digital signature based on IPV4 or IPV6 2.3 Use Case:1 1) The above case talks about usage of this mechanism in VPN case 2.4 Use Case:2 (RSVP can use this during tunnel setup) 1) Head-end during tunnel setup can inform tail-end about "Secured- Label" during setup 2) We can use any of the above solutions for LSP setup as well. 2.5 Advantages Bhargav.B et.al Expires August 2012 [Page 11] INTERNET DRAFT Securing Inter-provider MPLS-VPN Model-C February 2012 1) Any attacker's packet would have to guess a 40 bit label in the case of Solution 1 and a 20 + 128-bit DS label in Solution 2. 2) Since we are using PKI, it is impossible for an attacker to create a packet with same semantics(of PE) since he would have to guess the Algorithm UA(x) and the bitmask pattern in Solution (1) and the PKI key as well. In Solution (2) he would have to guess the PKI key and the Algorithm UA(x). 3) Provides real security from attacker in the case of a man-in-the- middle attack say from the intervening network between the two providers. 5) The same mechanism could be used by RSVP for tunnel setup between Head-end and tail-end. Head-end during RSVP set-up can inform tail- end to use the "Secured-Label" mechanism or the DS mechanism in Solution 1 and Solution 2 respectively. 2.6 Limitations 1) An additional decryption and hashing is necessary in PE for secured labels in Solution 2 and in Solution 1 a bitmask lookup and selection is required over and above the decryption and hashing. 2) This mechanism will not work if this packet is fragmented inside the core. But given that fragmentation is not done as PMTUD may be in vogue this is not really a serious limitation. Bhargav.B et.al Expires August 2012 [Page 12] INTERNET DRAFT Securing Inter-provider MPLS-VPN Model-C February 2012 3 Security Considerations PKI is a secure mechanism as established in common security parlance. The control plane is secure in Option-C / Model-C in Inter-provider VPNs. It would take more than polynomial time complexity for an attacker to spoof the traffic when this mechanism is in vogue. Thus spoofing attacks are obviated. 4 IANA Considerations IANA needs to assign the Type value for exchanging the additional details in the control plane as illustrated in the above two solutions. 5 References 5.1 Normative References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC1776] Crocker, S., "The Address is the Message", RFC 1776, April 1 1995. [TRUTHS] Callon, R., "The Twelve Networking Truths", RFC 1925, April 1 1996. 5.2 Informative References [1] S. Alouneh, A. En-Nouaary and A. Agarwal, MPLS security: an approach for unicast and multicast environments, Annals of Telecommunications, Springer, vol. 64, no. 5, June 2009, pp. 391-400, doi:10.1007/s12243-009- 0089-y. [2] M. H. Behringer and M. J. Morrow, MPLS VPN security, Cisco Press, June 2005, ISBN-10: 1587051834. [3] B. Daugherty and C. Metz, Multiprotocol Label Switching and IP, Part 1, MPLS VPNS over IP Tunnels, IEEE Internet Computing, May-June 2005, pp. 68-72, doi: 10.1109/MIC.2005.61. [4] L. Fang, N. Bita, J. L. Le Roux and J. Miles, Interprovider IP-MPLS services: requirements, Bhargav.B et.al Expires August 2012 [Page 13] INTERNET DRAFT Securing Inter-provider MPLS-VPN Model-C February 2012 implementations, and challenges, IEEE Communications Magazine, vol. 43, no. 6, June 2005, pp. 119-128, doi: 10.1109/MCOM.2005.1452840. [5] C. Lin and W. Guowei, Security research of VPN technology based on MPLS, Proceedings of the Third International Symposium on Computer Science and Computational Technology (ISCSCT 10), August 2010, pp. 168-170, ISBN- 13:9789525726107. [6] Y. Rekhter, B. Davie, E. Rosen, G. Swallow, D. Farinacci and D. Katz, Tag switching architecture overview, Proceedings of the IEEE, vol. 85, no. 12, December 1997, pp. 1973-1983, doi:10.1109/5.650179. [7] E. Rosen and Y. Rekhter, BGP/MPLS IP Virtual Private Networks (VPNs), RFC 4364, Standard Track, February, 2006. [8] T. H. Cormen, C. E. Leiserson, R. L. Rivest and C. Stein, Introduction to algorithms, 3rd edition, MIT Press, September 2009, ISBN-10:0262033844. [9] C. Semeria, RFC 2547bis: BGP/MPLS VPN fundamentals, Juniper Networks white paper, March 2001. [10] Advance MPLS VPN Security Tutorials [Online], Available: http://etutorials.org/Networking/MPLS+VPN+security/ Part+II+Advanced+MPLS+VPN+Security+Issues, [Accessed: 10th December 2011] [11] Inter-provider MPLS VPN models [Online], Available: http://mpls-configuration-on-cisco- iossoftware.org.ua/1587051990/ ch07lev1sec4.html, [Accessed 10th December 2011] [EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header", RFC 3514, April 1 2003. [RFC5513] Farrel, A., "IANA Considerations for Three Letter Acronyms", RFC 5513, April 1 2009. [RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, April 1 2009. Bhargav.B et.al Expires August 2012 [Page 14] INTERNET DRAFT Securing Inter-provider MPLS-VPN Model-C February 2012 Authors' Addresses Bhargav Bhikkaji, Dell-Force10, 350 Holger Way, San Jose, CA 95134 U.S.A EMail: BHARGAV_BHIKKAJI@dell.com Balaji Venkat Venkataswami, Dell-Force10, Olympia Technology Park, Fortius block, 7th & 8th Floor, Plot No. 1, SIDCO Industrial Estate, Guindy, Chennai - 600032. EMail: BALAJI_VENKAT_VENKAT@dell.com Bhargav.B et.al Expires August 2012 [Page 15]