INTERNET-DRAFT Mingui Zhang Intended Status: Proposed Standard Huawei Expires: April 18, 2011 Bin Liu Tsinghua University Dacheng Zhang Huawei Beichuan Zhang The University of Arizona October 15, 2010 Secure Extension of BGP by Decoupling Path Propagation and Adoption draft-zhang-idr-decoupling-00 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. 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 Notice Copyright (c) 2010 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 Zhang Expires April 18, 2011 [Page 1] INTERNET-DRAFT DBGP October 15, 2010 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. Zhang Expires April 18, 2011 [Page 2] INTERNET-DRAFT DBGP October 15, 2010 Abstract This draft proposes an extension of BGP which can be used to mitigate the issue of false routing announcement and works well with attack detection and prevention systems. Conventions used in this document 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]. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3 False Routing Announcements . . . . . . . . . . . . . . . . . . 4 3.1 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2 Countermeasures . . . . . . . . . . . . . . . . . . . . . . 5 3.2.1 Prevention . . . . . . . . . . . . . . . . . . . . . . 5 3.2.2 Detection . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.3. Traditional Mitigation . . . . . . . . . . . . . . . . 6 3.3 Paradox of Blocking Suspicious Routing Updates and Attack Detection . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. DBGP's Mitigation: Decoupling Path Propagation and Adoption . . 7 4.1 Quarantine Time . . . . . . . . . . . . . . . . . . . . . . 7 5 Protocol Descriptions . . . . . . . . . . . . . . . . . . . . . . 8 5.1 DAS_PATH Attribute TLV . . . . . . . . . . . . . . . . . . . 9 5.2 Identification of Suspicious Paths . . . . . . . . . . . . . 9 5.3 Propagating Updates . . . . . . . . . . . . . . . . . . . 11 5.4 Choosing Alternative Paths . . . . . . . . . . . . . . . . 11 5.5 Releasing Quarantined Paths . . . . . . . . . . . . . . . 12 6 Security Considerations . . . . . . . . . . . . . . . . . . . 12 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1 Normative References . . . . . . . . . . . . . . . . . . 12 8.2 Informative References . . . . . . . . . . . . . . . . . 13 Appendix A: Empirical Evaluation . . . . . . . . . . . . . . . . 13 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Zhang Expires April 18, 2011 [Page 3] INTERNET-DRAFT DBGP October 15, 2010 1 Introduction The false routing announcement in the global routing system is a serious security problem that can lead to widespread service disruptions. Existing work such as Pretty Good BGP (PGBGP)[PGBGP] blocks suspicious routing updates to protect data delivery. However, such an approach has the side effect of blocking the view of any detection system at the control plane or data plane. As a result, an attack will not be detected and operators will not be alerted to take actions stopping the attack. This draft proposes an extension of BGP, to solve this paradox by decoupling path propagation and adoption in BGP (dubbed as DBGP). 2 Terminology BGP: Broad Gateway Protocol DBGP: Decoupling path propagation and adoption in BGP 3 False Routing Announcements 3.1 Problem False routing announcements can be caused by either inadvertent mis- configurations or malicious attacks. For the ease of exposition, we use "attacker" to refer to the network (or Autonomous System, AS) that makes the false routing announcements regardless of the intention. Based on which part of the routing path is false, such announcements can be classified into five types, each of which has different severity: o Prefix origin: The attacker originates someone else's prefix. Depending on where a network is in the Internet topology, some will choose paths leading to the true origin and some will choose paths leading to the false origin. o Intermediate node: The attacker does not forge the prefix or its origin, but inserts itself into the path as an intermediate AS. Similar to the case of false origin, some networks will choose the correct paths and some the false paths. But usually fewer networks will choose the false path since it is longer than that of false origin attack. o Intermediate link: The attacker forges a new link to bypass some of the ASes to get a shorter path. The shortened path is expected to attract more networks' traffic. o Sub-prefix: The attacker originates a sub-prefix of someone else's prefix. Due to the longest match in routing lookup, a Zhang Expires April 18, 2011 [Page 4] INTERNET-DRAFT DBGP October 15, 2010 false sub-prefix will win over the original prefix. Thus, all traffic destined to the sub-prefix range will be forwarded to the attacker. o Super-prefix: Theoretically the attacker can also announce a false super-prefix, but that will not attract any traffic unless part of the prefix range is unused by the real owner, in which case it is equivalent to announcing a false origin of the unused prefix range. 3.2 Countermeasures The current strategies proposed for the problem of false announcements fall in three categories: prevention, detection and mitigation. 3.2.1 Prevention Prevention schemes (e.g., [SBGP], [SoBGP], and [SPV]) use cryptographic mechanisms to protect the routing updates and let routers reject any forged announcement. Unfortunately no prevention scheme has seen much deployment on the Internet due to the lack of incentives for those first movers. Since crypto-based schemes add significant computational load to routers and require upgrade on software or hardware, individual ISPs need to see immediate benefits to justify the deployment. On the current Internet, however, the first mover's routing announcements will be accepted by other networks without authentication, and adding authentication does not bring any immediate benefit. 3.2.2 Detection The representative detection systems proposed in recent years include [Cyclops], [PHAS], [MyASN], [IAR], [iSPY], [NWatch], [OList], and [LWeight]. Such systems are designed to detect false routing by examining routing updates, probing data paths, cross-checking with registry databases, or a combination of these techniques. Once a false routing case is detected, the owner of the prefix will be notified, and it is expected that the owner will take actions to resolve the problem, which, in today's Internet, usually involves contacting the offending network or its upstream provider to stop the false routing announcements. This process of detection, notification and resolution takes time, ranging from an hour to a day in some past incidents and varying from network to network [NWatch][RIPE]. In the meantime, the damage to data traffic has already been made and malicious attackers may have already achieved their objectives. Zhang Expires April 18, 2011 [Page 5] INTERNET-DRAFT DBGP October 15, 2010 3.2.3. Traditional Mitigation A mitigation schemes attempts to protect the data traffic while an attack is going on. The common approach is to somehow identify abnormal routing updates and block them. As proposed in [PGBGP] and [PGBGP++], a router can examine the content of incoming updates. If an AS path contains unexpected prefix origin or links, it will be suppressed from propagating for a period of time to wait for the network operator's validation. The length of the time is configurable by the network operators. Instead, an alternative path (via trusted prefix origin and links) will be employed for data delivery in the suppression period. After this period,if the path is not proved to be illegal, the router will adopt and announce the new path. PGBGP gives operators certain reaction time to resolve potential false announcements while protecting data delivery in the meantime. When a real attack is detected and resolved, the corresponding false announcement will be withdrawn from the routing system, whereas legitimate announcement will stay in the routing system and eventually be accepted. But blocking false routing announcements can get in the way of detection systems. For instance, on September 22, 2008, a Russian ISP AS8997 hijacked a large number of prefixes as it leaked an entire table [ASN8997]. However, since the upstream ISP of AS8997 blocked the routing updates, detection systems such as MyASN and IAR did not pick up this incident. The attack mainly affected ISPs and users within Russia but largely went unnoticed by prefix owners. Each existing solution has its drawbacks, and none is sufficiently effective by itself. The future of the Internet probably will have several different solutions at the same time, complementary to each other, forming a multi-line defense to protect routing and data delivery before, during, and after attacks. 3.3 Paradox of Blocking Suspicious Routing Updates and Attack Detection It has been realized that a mitigation mechanism and a detection system that complement each other well can be integrated into an effective routing defense solution. For instance, the mitigation mechanism can help the detection system to confine the damage caused by an attack, as the affected data traffic may be vulnerable for hours before the attack can be actually detected by the detection mechanism and be eventually stopped. Also, the mitigation mechanism can also obtain benefit from the detection system because a mitigation mechanism normally cannot identity false routing information accurately with its limited knowledge, resource and time. The output from the detection system can be used to correct the many false positives generated by the mitigation mechanism and also inform Zhang Expires April 18, 2011 [Page 6] INTERNET-DRAFT DBGP October 15, 2010 the prefix owner to resolve the attack. However, there is a dilemma: the mitigation mechanism tries to render the attack ineffective while the detection system needs the attack to be effective in order to detect it. 4. DBGP's Mitigation: Decoupling Path Propagation and Adoption In order to solve the dilemma mentioned in Section 3.3, this document proposes a solution which decouples path propagation and path adoption. In current BGP, the path a router adopts for data forwarding is the same path being propagated to neighbors. As a consequence, upon receiving a suspicious path, a router has to either accept it (no mitigation but good detection) or reject it (good mitigation but no detection). The basic idea of this solution is to extend BGP so that a router can use trusted paths for data forwarding and can also inform its neighbor routers about the suspicious path. In this way, the data traffic is protected while the false routing announcements are being propagated and will likely be monitored by the detection system. In order to achieve this, a new BGP attribute, DAS_PATH, is defined in Section 5 to transport suspicious path information. Additionally, based on historical operating experiences, a false routing announcement can be detected and corrected in a certain period (e.g., one day) after it is launched, and so an announcement will be trusted if it is not withdrawn in a pre-defined period. The rest of this section will discuss the design details in identifying suspicious paths, choosing alternative paths for data forwarding, propagating the paths, and releasing quarantined paths. 4.1 Quarantine Time In mitigation schemes, when a new path is identified as a suspicious one, it will be quarantined (or blocked) from being used for a period of time, which is call the quarantine time and noted as T_q. A router MAY determine the quarantine time itself. Assume there are two routers, R1 and R2. R1 is the downstream of R2, and the quarantine time of R1 and R2 is T1 and T2 respectively. The suspicious path is PATH at R1. There are two possibilities. o T1 is shorter than T2. When T1 expires, PATH becomes trusted by R1 and R1 begins to use it for data delivery. R1 will announce R1-PATH as a legitimate AS path to R2. However, at this time, the path R1-PATH is still being quarantined by R2. o T1 is longer than T2. When T2 expires, R1-PATH becomes trusted Zhang Expires April 18, 2011 [Page 7] INTERNET-DRAFT DBGP October 15, 2010 by R2. However, R2 can not use this path for data delivery as R1 has not announced R1-PATH as an AS path. It will be cached in the Adj-RIBs-In until the downstream router R1 has announced it as an AS path when T1 expires. 5 Protocol Descriptions Take Figure 1 for example. A, B, C, and O are DBGP routers residing in different ASes, , X is the attacker and p is the prefix of interest. Before the attack, the preferred path for traffic is ABCO. Here, we use the notation "R1R2...Rn-p" to denote the AS path which is destined to prefix "p" via routers R1, R2, ..., Rn. When X makes a false announcement of X-p to B, B will regard this new path as suspicious because it would divert traffic to an AS(X) that previously was not on the data path (BCO). B will store the suspicious path in its Adj-RIBs-In (The routing tables of an AS router is comprised of three sub-tables: Adj-RIBs-In, Loc-RIB and Adj-RIBs-Out [BGP4]), but keep using the existing path in its Loc-RIB for data forwarding. At the same time, B re-announces its path (BCO) in an update message to A, and encapsulates the new, suspicious path (BX) as an optional transitive attribute which is defined in Section 5.1. After receiving the update message, router A learns this suspicious path, stores it, and propagates it further to its neighbors using the optional attribute the same way. Therefore, the suspicious path is propagated to the Internet while not adopted for data forwarding. This approach enable the detection systems to intercept the suspicious path and notify the prefix owner to take actions. Once the attack is stopped, the false announcements will be withdrawn from the routing system, i.e., deleted or replaced in the Adj-RIBs-In of the involved routers. However, a router realizes that the quarantine time has been expired and the suspicious path is still in the Adj-RIBs-In, the router regards the path as a legitimate one. Hence the DBGP router will install the path in its Loc-RIB for data forwarding and re-announce the path using the regular ASPATH attribute in the update message. For example, if BX-p has been validated as legitimate, B will announce it to A as its AS_PATH. The rest of this section will discuss the design details in new BGP attribute definition, identifying suspicious paths, choosing alternative paths for data forwarding, propagating the paths, and releasing quarantined paths. [X]->p ^ | [A]->[B]->[C]->[O]-p Figure 1: Attack Example 1 Zhang Expires April 18, 2011 [Page 8] INTERNET-DRAFT DBGP October 15, 2010 5.1 DAS_PATH Attribute TLV DAS_PATH (Decoupled AS_PATH) is defined as an optional transitive attribute. It is composed of a sequence of DAS path segments. Each DAS path segment is represented by a triple . The path segment type is a 1-octet long field with the following values defined: Value Segment Type 1 DAS_SET unordered set of ASs a route in the UPDATE message has traversed 2 DAS_SEQUENCE ordered set of ASs a route in the UPDATE message has traversed The path segment length is a 1-octet long field containing the number of ASs in the path segment value field. The path segment value field contains one or more AS numbers, each encoded as a 2-octets long field. When a DAS_PATH is propagated across the network, the operations on DAS_PATH follows the well-known AS_PATH attribute only that DAS_PATH is non-mandatory. If a router which does not deploy DBGP receives the update messages containing DAS_PATH attribute, i.e., does not understand this attribute, it will just pass it on to the next router. If its downstream router is a DBGP router, it will be able to pick up the information from this attribute and continue DBGP operations. Therefore DBGP can be incrementally deployed over the Internet. 5.2 Identification of Suspicious Paths For a given prefix p, a path is trusted if it has been staying in the Adj-RIBs-In continuously for the required quarantine time, T_q. All the nodes, links, and origins that appear in trusted paths are trusted components, and the set of them is denoted by trusted(p). This set of trusted components is derived from current contents of all Adj-RIBs-In without using a database to store historical information like PGBGP does. Nodes, links, and origins that do not belong to trusted(p) are said to be suspicious components for this particular prefix p. A new path is suspicious if it contains any suspicious component for its prefix. However, not all suspicious paths need to be explicitly quarantined. DBGP quarantines paths that satisfy the following condition: o A new path is quarantined if and only if it is suspicious, more Zhang Expires April 18, 2011 [Page 9] INTERNET-DRAFT DBGP October 15, 2010 preferred than other alternative paths, and contains an AS that is not in the current data forwarding path. If the new path is not better than alternative paths, it will not be able to divert any traffic. One may suggest that the attacker can first announce a less preferred path so that DBGP routers will take it as a backup path without suspicion, and then make the primary path fail to trick the router to use the false backup path. But in this case, if the attacker has the control of the primary path, it can already get the traffic without doing this. If the attacker does not have control of the primary path, it will not know when the primary path may fail and which backup path the router will choose, thus the attack will not be effective. If the new path does not introduce any new AS on the data path, it is not quarantined since it does not divert any traffic. In Figure 2, when X launches an attack by announcing X-p, this path is not quarantined by B since B already sends its traffic to X. B will accept this path and announces it to A. Assuming ABX-p is more preferred than ACO-p, A will quarantine ABX-p since this new path would divert A's traffic to a new place, AS X, and X is a suspicious origin to A. To reduce the potential false positives in quarantining paths, we introduce an optimization rule. If the current best path is replaced by a suspicious path (i.e., the same neighbor that sent the best path previously sends another path to replace it), then the current best path is cached for a short time period. This rule is used to accommodate some unstable prefixes, which may get announced and withdrawn or oscillate between two paths frequently. With this rule, quick re-announcement of a path will not be treated as suspicious. Previous measurement work has shown that (1) most prefixes are stable, and only a small number of prefixes are very unstable; (2) the most popular prefixes are stable; and (3) the most preferred paths are being used by routers for most of the time [BGPpop][Stable][BGPHA]. Therefore, DBGP's criterion for suspicious paths will not generate excessive false positives in reality. The majority of the rest prefixes is only suspicious infrequently. Zhang Expires April 18, 2011 [Page 10] INTERNET-DRAFT DBGP October 15, 2010 +---------------+ | | | v [A]->[B]->[X]->[C]->[O]-p | p Figure 2: Attack Example 2 5.3 Propagating Updates DBGP uses the new BGP attribute, DAS_PATH, to carry the suspicious path in updates. In certain cases DBGP update may need to carry multiple DAS_PATHs. For example, in Figure 3, assume C does not deploy DBGP and accepts the false announcement of X-p. When B receives BCX-p, B quarantines this new path and switches to its backup BDO-p. The update from B to A will have BDO as the AS_PATH, and BCX as the DAS_PATH attribute. However, since BDO is suspicious to A as well, A will quarantine BDO and switch to AEFO. Thus the update from A will contain two DAS_PATHs: ABCX and ABDO. Whether an update contains multiple DAS_PATHs depends on the topology and routing policy. In the worst case, the number of DAS_PATH in an update is the same as the AS hop count of the AS_PATH. Given AS e 10 hops, we do not expect this will make DBGP message too large and it is confirmed in our simulations. [X]->p ^ | [A]->[B]->[C]->[O]-p | | ^ | | /| | +-->[D]-+ | | | +------->[E]->[F] Figure 3: Attack Example 3 5.4 Choosing Alternative Paths When a new path is the most preferred but suspicious, DBGP routers will use an alternative path for data delivery. The question is which alternative path to be chosen. First, if the existing path that is being used for data forwarding is still the best, then the router can stick to that path without any changes. Second, if the existing path in use will have been replaced by the suspicious path, then the router needs to pick an alternative. For example, in Figure 3, suppose C does not deploy DBGP and blindly accepts the false Zhang Expires April 18, 2011 [Page 11] INTERNET-DRAFT DBGP October 15, 2010 announcement X-p. B's existing path BCO-p will be replaced by a suspicious path BCX-p, therefore B needs to temporarily switch to a backup path BDO-p from its Adj-RIBs-In. Third, if there is no alternative path or all alternative paths are labeled as suspicious, then the router err on data delivery by adopting a suspicious path to forward packets. 5.5 Releasing Quarantined Paths If the quarantined paths are false announcements, it is likely that within T_q, the attack will be stopped and these paths being withdrawn from the routing system. In this case, there is no explicit release of the quarantined path. Just the upstream router will send an update with empty DAS_PATH attribute. If T_q has passed and the quarantined path is still in the Adj-RIBs-In, then it is more likely that this is a legitimate path. The router will treat the path as a regular path and make it go through the path selection process. If the path turns out to be the most preferred one, it will be used for data forwarding and trigger routing updates to neighbor routers. 6 Security Considerations The entire document is about security consideration. 7 IANA Considerations 8 References 8.1 Normative References [PGBGP] J. Karlin, S. Forrest, and J. Rexford, "Pretty Good BGP: Improving BGP by Cautiously Adopting Routes," in Proceedings of IEEE ICNP, 2006. [SBGP] S. Kent, C. Lynn, and K. Seo, "Secure Border Gateway Protocol (SBGP)," IEEE Journal on Selected Areas in Communications, vol. 18, no. 4, pp. 582 - 592, 2000. [Cyclops] Y.-J. Chi, R. Oliveira, and L. Zhang, "Cyclops: the as- level connectivity observatory," SIGCOMM Comput. Commun. Rev., vol. 38, no. 5, pp. 5-16, 2008. [PHAS] M. Lad, D. Massey, D. Pei, B. Zhang, and L. Zhang, "PHAS: A Prefix Hijack Alert System," in 15th USENIX Security Symposium, 2006, pp.153-166. [MyASN] "RIPE myASN System," http://www.ris.ripe.net/myasn.html. [IAR] [Online]. Available: http://iar.cs.unm.edu/ [iSPY] Z. Zhang, Y. Zhang, Y. C. Hu, Z. M. Mao, and R. Bush, "iSPY: Detecting IP Prefix Hijacking on My Own," in Proceedings of ACM SIGCOMM, 2008. [NWatch] G. Siganos and M. Faloutsos, "Neighborhood Watch for Zhang Expires April 18, 2011 [Page 12] INTERNET-DRAFT DBGP October 15, 2010 Internet Routing: Can We Improve the Robustness of Internet Routing Today?" in Proceedings of IEEE INFOCOM, 2007. [Olist] X. Zhao, D. Pei, L. Wang, D. Massey, A. Mankin, S. Wu, and L. Zhang,"Dection of Invalid Routing Announcement in the Internet," in Proceedings of the IEEE DSN, June 2002. [LWeight] C. Zheng, L. Ji, D. Pei, J. Wang, and P. Francis, "A Light-weight Distributed Scheme for Detecting IP Prefix Hijacks in Real-time," in Proceedings of ACM SIGCOMM, 2007. [SBGP] S. Kent, C. Lynn, and K. Seo, "Secure Border Gateway Protocol (SBGP),"IEEE Journal on Selected Areas in Communications, vol. 18, no. 4, pp. 582 - 592, 2000. [SoBGP] J. Ng, "Extensions to BGP to Support Secure Origin BGP," April 2004, ftp://ftp-eng.cisco.com/sobgp/drafts/draft- ng-sobgp-bgp-extensions-02.txt. [SPV] Y.-C. Hu, A. Perrig, and M. Sirbu, "SPV: Secure Path Vector Routing for Securing BGP," in Proceedings of ACM SIGCOMM, 2004. [RIPE] [Online]. Available: http://www.ripe.net/news/study- youtubehijacking.html [ASN8997] "Prefix hijack by ASN 8997." [Online]. Available: http://www.merit.edu/mail.archives/nanog/2008- 09/msg00704.html [BGPpop] J. Rexford, J. Wang, Z. Xiao, and Y. Zhang, "BGP Routing Stability of Popular Destinations," in Proceedings of ACM IMC, 2002, pp. 197-202. [Stable] K. Butler, P. McDaniel, and W. Aiello, "Optimizing BGP Security by Exploiting Path Stability," in Proceedings of ACM CCS, Alexandria, VA, United States, 2006, pp. 298-310. [BGPHA] R. V. Oliveira, R. Izhak-Ratzin, B. Zhang, and L. Zhang, "Measurement of Highly Active Prefixes in BGP," in Proceedings of IEEE Globecom,2005. [BGP4] J. W. Stewart, BGP4: Inter-Domain Routing in the Internet. Boston,MA, USA: Addison-Wesley Longman Publishing Co., Inc., 1998. 8.2 Informative References Appendix A: Empirical Evaluation The following aspects of DBGP are tested on the SSFNet-2.0 simulation platform which has a implementation of BGP4. o The capacity to counter attacks o The ability to rectify the false positives o The memory and message overhead The evaluation proves that DBGP can be used to mitigate all types of Zhang Expires April 18, 2011 [Page 13] INTERNET-DRAFT DBGP October 15, 2010 attacks. Compared with previous mitigation approaches [PGBGP], it reduces the delay of legitimate announcements significantly, only incurs a small amount of messages and memory overhead. Author's Addresses Mingui Zhang Huawei Technologies Co.,Ltd HuaWei Building, No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing, 100085 P.R. China Email: mingui@huawei.com Bin Liu Tsinghua University East Main Building RM9-416 Tsinghua University, Hai-Dian District, Beijing, 100084 P.R. China Email: lmyujie@gmail.com Dacheng Zhang Huawei Technologies Co.,Ltd HuaWei Building, No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing, 100085 P.R. China Email: zhangdacheng@huawei.com Beichuan Zhang University of Arizona Computer Science Department, The University of Arizona Tucson, AZ 85721 U.S.A. Email: bzhang@arizona.edu Zhang Expires April 18, 2011 [Page 14]