Internet-Draft Inter-domain SAVNET Problem Statement March 2023
Wu, et al. Expires 26 September 2023 [Page]
Workgroup:
Internet Engineering Task Force
Internet-Draft:
draft-wu-savnet-inter-domain-problem-statement-07
Published:
Intended Status:
Informational
Expires:
Authors:
J. Wu
Tsinghua University
D. Li
Tsinghua University
L. Liu
Zhongguancun Laboratory
M. Huang
Huawei
L. Qin
Tsinghua University
N. Geng
Huawei

Source Address Validation in Inter-domain Networks Gap Analysis, Problem Statement, and Requirements

Abstract

This document provides the gap analysis of existing inter-domain source address validation mechanisms, describes the fundamental problems, and defines the requirements for technical improvements.

Status of This Memo

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

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

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."

This Internet-Draft will expire on 26 September 2023.

▲

Table of Contents

1. Introduction

Source address validation (SAV) is crucial for protecting networks from source address spoofing attacks. The MANRS initiative advocates deploying SAV as close to the source as possible [manrs], and access networks are the first line of defense against source address spoofing. However, access networks face various challenges in deploying SAV mechanisms due to different network environments, router vendors, and operational preferences. Hence, it is not feasible to deploy SAV at every network edge. Additional SAV mechanisms are needed at other levels of the network to prevent source address spoofing along the forwarding paths of the spoofed packets. The Source Address Validation Architecture (SAVA) [RFC5210] proposes a multi-fence approach that implements SAV at three levels of the network: access, intra-domain, and inter-domain.

If a spoofing packet is not blocked at the originating access network, intra-domain and inter-domain SAV mechanisms can help block the packet along the forwarding path of the packet. As analyzed in [intra-domain], intra-domain SAV for an AS can prevent a subnet of the AS from spoofing the addresses of other subnets as well as prevent incoming traffic to the AS from spoofing the addresses of the AS, without relying on the collaboration of other ASes. As complementrary, in scenarios where intra-domain SAV cannot work, inter-domain SAV leverages the collaboration among ASes to help block incoming spoofing packets in an AS which spoof the source addresses of other ASes.

This document provides an analysis of inter-domain SAV. Figure 1 illustrates an example for inter-domain SAV. P1 is the source prefix of AS 1, and AS 4 sends spoofing packets with P1 as source addresses to AS 3 through AS 2. Assume AS 4 does not deploy intra-domain SAV, these spoofing packets cannot be blocked by AS 4. Although AS 1 can deploy intra-domain SAV to block incoming packets which spoof the addresses of AS 1, these spoofing traffic from AS 4 to AS 3 do not go through AS 1, so they cannot be blocked by AS 1. Inter-domain SAV can help in this scenario. If AS 1 and AS 2 deploy inter-domain SAV, AS 2 knows the correct incoming interface of packets with P1 as source address, and the spoofing packets can thus be blocked by AS 2 since they come from the incorrect interface.

+------------+
|  AS 1(P1)  #
+------------+ \
                \            Spoofed Packets
              +-+#+--------+ with Source Addresses in P1 +------------+
              |    AS 2    #-----------------------------#    AS 4    |
              +-+#+--------+                             +------------+
                /
+------------+ /
|    AS 3    #
+------------+
AS 4 sends spoofed packets with source addresses in P1 to AS 3
  through AS 2.
If AS 1 and AS 2 deploy inter-domain SAV, the spoofed packets
  can be blocked at AS 2.
Figure 1: An example for illustrating inter-domain SAV

There are many existing mechanisms for inter-domain SAV. This document analyzes them and attempts to answer: i) what are the technical gaps (Section 4), ii) what are the fundamental problems (Section 5), and iii) what are the practical requirements for the solution of these problems (Section 6).

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. Terminology

SAV Rule:

The rule that indicates the validity of a specific source IP address or source IP prefix.

Improper Block:

The validation results that the packets with legitimate source addresses are blocked improperly due to inaccurate SAV rules.

Improper Permit:

The validation results that the packets with spoofed source addresses are permitted improperly due to inaccurate SAV rules.

3. Existing Inter-domain SAV Mechanisms

Inter-domain SAV is typically performed at the AS level and can be deployed at AS border routers (ASBR) to prevent source address spoofing. There are various mechanisms available to implement inter-domain SAV for anti-spoofing ingress filtering [manrs] [isoc], which are reviewed in this section.

4. Gap Analysis

Inter-domain SAV protects against source address spoofing attacks across all AS interfaces, including provider, customer, and peer interfaces. This section performs a gap analysis of existing SAV mechanisms at these interfaces to identify their technical shortcomings.

4.1. SAV at Provider Interface

SAV at provider interface is recommended to deploy ACL-based ingress filtering and/or Loose uRPF to prevent spoofing source addresses from provider AS [nist] [RFC3704], and can utilize source-based RTBH filtering to configure SAV rules remotely. In the following, we expose the problems with existing inter-domain SAV mechanisms at the provider interface with a reflection attack scenario.

                  +-----------+
  Attacker(P1') +-+  AS 3(P3) |
                  +---+/\+----+
                        |
                        |
                        | (C2P)
                  +-----------+
                  |  AS 4(P4) |
                  +/\+-----+/\+
                   /         \
                  /           \
           (C2P) /             \ (C2P)
         +-----------+      +-----------+
 Victim+-+  AS 1(P1) |      |  AS 2(P2) +-+Server
         +-----------+      +-----------+

 P1' is the spoofed source prefix P1 by the attacker
 which is inside of AS 3 or connected to AS 3 through other ASes
Figure 2: A scenario of the reflection attack from provider AS

As depicted in Figure 2, a reflection attack is a type of cyber attack in which the attacker spoofs the victim's IP address (P1) and sends requests to server's IP address (P2) that respond to that type of request. The servers then send responses back to the victim, overwhelming its network resources. The arrows represent the commercial relationship between ASes. AS 3 is the provider of AS 4, and AS 4 is the provider of AS 1 and AS 2. Suppose AS 1 and AS 4 have deployed inter-domain SAV, while the other ASes have not.

By applying ACL-based ingress filtering at the provider interface of AS 4, the ACL rules can block any packets with spoofed source addresses from AS 3 in P1 and P2, thus stopping the attack. However, this approach incurs heavy operational overhead, as it requires network operators to update the ACL rules promptly based on changes in prefixes or topology of AS 1 and AS 2. Otherwise, it may cause improper block or improper permit of legitimate traffic.

Source-based RTBH filtering allows for the deployment of SAV rules on AS 1 and AS 4 remotely. However, in order to avoid improper block or improper permit, the specified source addresses need to be updated in a timely manner, which incurs additional operational overhead.

Loose uRPF can greatly reduce the operational overhead because it uses the local FIB as information source, and can adapt to changes in the network. However, it can improperly permit spoofed packets. In Figure 2, Loose uRPF is enabled at AS 4's provider interface, while EFP-uRPF is enabled at AS 4's customer interfaces, following [RFC3704]. An attacker inside AS 3 or connected to it through other ASes may send packets with source addresses spoofing P1 to a server in AS 2 to attack the victim in AS 1. As AS 3 lacks deployment of inter-domain SAV, the attack packets will reach AS 4's provider interface. With Loose uRPF, AS 4 cannot block the attack packets at its provider interface, and thus resulting in improper permit.

4.2. SAV at Customer Interface

To prevent the spoofing of source addresses within a customer cone, operators can enable ACL-based ingress filtering, source-based RTBH filtering, and/or uRPF-based mechanisms at the customer interface, namely Strict uRPF, FP-uRPF, VRF uRPF, or EFP-uRPF. However, ACL-based ingress filtering and source-based RTBH filtering need to update SAV rules in a timely manner and have the same operational overhead as performing SAV at provider interfaces, while uRPF-based mechanisms may cause improper block problems in two inter-domain scenarios: limited propagation of prefixes and hidden prefixes. In the following, we show how uRPF-based mechanisms may block legitimate traffic.

4.2.1. Limited Propagation of Prefixes

In inter-domain networks, some prefixes may not be propagated to all domains due to various factors, such as NO_EXPORT or NO_ADVERTISE communities or other route filtering policies. This may cause asymmetric routing in the inter-domain context, which may lead to false positives when performing SAV with existing mechanisms. These mechanisms include EFP-uRPF, which we focus on in the following analysis, as well as trict uRPF, FP-uRPF, and VRF uRPF. All these mechanisms suffer from the same problem of improper block in this scenario.

            +-----------------+
            |       AS 4      |
            +-+/\+-------+/\+-+
               /           \
              /             \
    P1[AS 1] /               \
            /                 \
           / (C2P/P2P)   (C2P) \
  +----------------+     +----------------+
  |      AS 3      |     |      AS 2      |
  +-------+/\+-----+     +------+/\+------+
            \                    /
    P1[AS 1] \                  / P1[AS 1]
              \ (C2P)    (C2P) / NO_EXPORT
             +------------------+
             |     AS 1(P1)     +---P1
             +------------------+
Figure 3: Limited propagation of prefixes caused by NO_EXPORT

Figure 3 presents a scenario where the limited propagation of prefixes occurs due to the NO_EXPORT community attribute. AS 1 is the customer of both AS 2 and AS 3, and AS 4 is the provider of AS 2. The relationship between AS 3 and AS 4 can be either customer-to-provider (C2P) or peer-to-peer (P2P). AS 1 advertises prefix P1 to its provider, AS 2 and AS 3. Upon receiving the route for prefix P1 from AS 1, AS 3 propagates it to AS 4. However, AS 2 does not propagate the route for prefix P1 to AS 4 because AS 1 adds the NO_EXPORT community attribute in the BGP advertisement sent to AS 2. In this scenario, AS 4 learns the route for prefix P1 only from AS 3. Suppose AS 1 and AS 4 have deployed inter-domain SAV while other ASes have not, and AS 4 have deployed EFP-uRPF at the customer interface.

Assuming that AS 3 is the customer of AS 4, if AS 4 deploys EFP-uRPF with algorithm A at customer interfaces, it will require packets with source addresses in P1 to only arrive from AS 3. When AS 1 sends legitimate packets with source addresses in P1 to AS 4 through AS 2, AS 4 improperly blocks these packets. The same problem applies to Strict uRPF, FP-uRPF, and VRF uRPF. Although EFP-uRPF with algorithm B can avoid improper block in this case, network operators need to first determine whether limited prefix propagation exists before choosing the suitable EFP-uRPF algorithms, which adds more complexity and overhead to network operators. Furthermore, EFP-uRPF with algorithm B is not without its problems. For example, if AS 3 is the peer of AS 4, AS 4 will not learn the route of P1 from its customer interfaces. In such case, both EFP-uRPF with algorithm A and algorithm B have improper block problems.

4.2.2. Hidden Prefixes

Some servers' source addresses are not advertised through BGP to other ASes. These addresses are unknown to the inter-domain routing system and are called hidden prefixes. Legitimate traffic with these hidden prefixes may be dropped by existing inter-domain SAV mechanisms, such as Strict uRPF, FP-uRPF, VRF uRPF, or EFP-uRPF, because they do not match any known prefix.

For example, Content Delivery Networks (CDN) use anycast [RFC4786] [RFC7094] to improve the quality of service by bringing content closer to users. An anycast IP address is assigned to devices in different locations, and incoming requests are routed to the closest location. Usually, only locations with multiple connectivity announce the anycast IP address through BGP. The CDN server receives requests from users and creates tunnels to the edge locations, where content is sent directly to users using direct server return (DSR). DSR requires servers in the edge locations to use the anycast IP address as the source address in response packets. However, these edge locations do not announce the anycast prefixes through BGP, so an intermediate AS with existing inter-domain SAV mechanisms may improperly block these response packets.

                  +----------+
  Anycast Server+-+ AS 3(P3) |
                  +--+/\+----+
                       |
                       |
                       | (C2P)
                  +----------+
                  |   AS 4   |
                  +/\+----+/\+
                   /        \
                  /          \
           (C2P) /            \ (C2P)
      +-----------+          +-----------+
User+-+    AS 1   |          |    AS 2   +-+Edge Server
      +-----------+          +-----------+

  P3 is the anycast prefix and is only advertised by AS 3 through BGP
Figure 4: A Direct Server Return (DSR) scenario

Figure 4 illustrates a DSR scenario where the anycast IP prefix P3 is only advertised by AS 3 through BGP. In this example, AS 3 is the provider of AS 4, and AS 4 is the provider of AS 1 and AS 2. AS 1 and AS 4 have deployed inter-domain SAV, while other ASes have not. When users in AS 1 send requests to the anycast destination IP, the forwarding path is AS 1->AS 4->AS 3. The anycast servers in AS 3 receive the requests and tunnel them to the edge servers in AS 2. Finally, the edge servers send the content to the users with source addresses in prefix P3. The reverse forwarding path is AS 2->AS 4->AS 1. Since AS 4 does not receive routing information for prefix P3 from AS 2, EFP-uRPF with algorithm A/B, and all other existing uRPF-based mechanisms at the customer interface of AS 4 facing AS 2 will improperly block the legitimate response packets from AS 2.

4.3. SAV at Peer Interface

To prevent spoofing traffic from peer ASes, SAV at peer interfaces can enable ACL-based ingress filtering, source-based RTBH filtering, and/or employ one of the following uRPF-based SAV mechanisms: FP-uRPF, VRF uRPF, or EFP-uRPF. ACL-based ingress filtering and source-based RTBH filtering have high operational overhead and uRPF-based SAV mechanisms share the same improper block problems with the inter-domain SAV mechanisms when applied at provider interfaces or customer interfaces. The improper block problems occur in cases of limited propagation of prefixes and hidden prefixes. For brevity, we do not analyze these problems again here. Moreover, if we apply EFP-uRPF with algorithm B at peer or customer interfaces, we may encounter improper permit problems, as explained below.

+-----------+    (P2P)    +-----------+
|  AS 3(P3) +-------------+  AS 4(P4) |
+-----+-----+             +/\+-----+/\+
      |                    /         \
      +                   /           \
 Attacker(P1')     (C2P) /             \ (C2P)
                 +-----------+      +-----------+
         Victim+-+  AS 1(P1) |      |  AS 2(P2) +-+Server
                 +-----------+      +-----------+

P1' is the spoofed source prefix P1 by the attacker
which is inside of AS 3 or connected to AS 3 through other ASes
Figure 5: A scenario of the reflection attack from peer AS

Figure 5 depicts a scenario of a reflection attack originating from a peer AS. The direction of the commercial relationship between ASes is indicated by arrows. AS 3 is the lateral peer of AS 4, which is the provider of AS 1 and AS 2. Assuming that AS 1 and AS 4 have deployed inter-domain SAV and that EFP-uRPF with algorithm B is enabled at AS 4's peer and customer interfaces, a reflection attacker located in AS 3 or connected to it through other ASes can launch an attack on a victim in AS 1 by sending packets with spoofed source addresses in P1 to a server in AS 2. Since AS 3 does not perform SAV, the spoofed attack packets will arrive at the peer interface of AS 4, EFP-uRPF with algorithm B cannot block them since it allows packets with source addresses in prefix P1 on any of AS 4's peer interfaces.

5. Problem Statement

Based on the above analysis, we conclude that existing inter-domain SAV mechanisms have limitations in asymmetric routing scenarios, and they may cause improper block or improper permit issues. They also incur high operational overhead when network routing changes dynamically.

For ACL-based ingress filtering, network operators need to manually update ACL rules to adapt to network changes. Otherwise, they may cause improper block or improper permit issues. Manual updates induce high operational overhead, especially in networks with frequent policy and route changes. Source-based RTBH filtering has the similar problem as ACL-based ingress filtering.

Strict uRPF and Loose uRPF are automatic SAV mechanisms, thus they do not need any manual effort to adapt to network changes. However, they have issues in scenarios with asymmetric routing. Strict uRPF may cause improper block problems when an AS is multi-homed and routes are not symmetrically announced to all its providers. This is because the local FIB may not include the asymmetric routes of the legitimate packets, and Strict uRPF only uses the local FIB to check the source addresses and incoming interfaces of packets. Loose uRPF may cause improper permit problems and fail to prevent source address spoofing. This is because it is oblivious to the incoming interfaces of packets.

FP-uRPF and VRF uRPF improve Strict uRPF in multi-homing scenarios. However, they still have improper block issues in asymmetric routing scenarios. For example, they may not handle the cases of limited propagation of prefixes. These mechanisms use the local RIB to learn the source prefixes and their valid incoming interfaces. But the RIB may not have all the prefixes with limited propagation and their permissible incoming interfaces.

EFP-uRPF allows the prefixes from the same customer cone at all customer interfaces. This solves the improper block problems of FP-uRPF and VRF uRPF in multi-homing scenarios. However, this approach also compromises partial protection against spoofing from the customer cone. EFP-uRPF may still have improper block problems when it does not learn legitimate source prefixes. For example, hidden prefixes are not learned by EFP-uRPF.

Finally, existing inter-domain SAV mechanisms cannot work in all directions (i.e. interfaces) of ASes to achieve effective SAV. Network operators need to carefully analyze the network environment and choose approapriate SAV mechansim for each interface. This leads to additional operational and cognitive overhead, which can hinder the rate of adoption of inter-domain SAV.

6. Requirements for New Inter-domain SAV Mechanisms

This section lists the requirements which can help bridge the technical gaps of existing inter-domain SAV mechanisms. These requirements serve as practical guidelines that can be met, in part or in full, by proposing new techniques.

6.1. Automatic Update

The new inter-domain SAV mechanism MUST be able to adapt to dynamic networks and asymmetric routing scenarios automatically, instead of relying on manual update.

6.2. Accurate Validation

The new inter-domain SAV mechanism SHOULD improve the validation accuracy in all directions of ASes over existing inter-domain SAV mechanisms. It SHOULD avoid improper block and minimize improper permit so that the legitimate traffic from an AS will not be blocked and the spoofed traffic will be reduced as much as possible. To avoid improper block, ASes that deploy the new inter-domain SAV mechanism SHOULD be able to acquire all the real data-plane forwarding paths.

In cases where it is difficult to acquire all the real forwarding paths exactly, it is essential to obtain a minimal set of acceptable paths that cover the real forwarding paths to avoid improper block and minimize improper permit. Additionally, multiple sources of SAV-related information, such as RPKI ROA objects, ASPA objects, and collaborative advertisements of other ASes, can help reduce the set of acceptable paths and improve the validation accuracy.

6.3. Working in Incremental/Partial Deployment

The new inter-domain SAV mechanism SHOULD NOT assume pervasive adoption and SHOULD provide effective protection for source addresses when it is partially deployed in the Internet. Not all AS border routers can support the new SAV mechanism at once, due to various constraints such as capabilities, versions, or vendors. The new SAV mechanism should not be less effective in protecting all directions of ASes under partial deployment than existing mechanisms.

7. Inter-domain SAV Scope

The new inter-domain SAV mechanism should work in the same scenarios as existing inter-domain SAV mechanisms. Generally, it includes all IP-encapsulated scenarios:

Scope does not include:

In addition, the new inter-domain SAV mechanism should not modify data-plane packets. Existing architectures or protocols or mechanisms can be inherited by the new SAV mechanism to achieve better SAV effectiveness.

8. Security Considerations

SAV rules can be generated based on route information (FIB/RIB) or non-route information. If the information is poisoned by attackers, the SAV rules will be false. Legitimate packets may be dropped improperly or malicious traffic with spoofed source addresses may be permitted improperly. Route security should be considered by routing protocols. Non-route information, such as ASPA, should also be protected by corresponding mechanisms or infrastructure. If SAV mechanisms or protocols require information exchange, there should be some considerations on the avoidance of message alteration or message injection.

The SAV procedure referred in this document modifies no field of packets. So, security considerations on data-plane are not in the scope of this document.

9. IANA Considerations

This document does not request any IANA allocations.

10. References

10.1. Normative References

[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3704]
Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, , <https://www.rfc-editor.org/rfc/rfc3704>.
[RFC8704]
Sriram, K., Montgomery, D., and J. Haas, "Enhanced Feasible-Path Unicast Reverse Path Forwarding", BCP 84, RFC 8704, DOI 10.17487/RFC8704, , <https://www.rfc-editor.org/rfc/rfc8704>.
[RFC2827]
Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, , <https://www.rfc-editor.org/rfc/rfc2827>.
[RFC5210]
Wu, J., Bi, J., Li, X., Ren, G., Xu, K., and M. Williams, "A Source Address Validation Architecture (SAVA) Testbed and Deployment Experience", RFC 5210, DOI 10.17487/RFC5210, , <https://www.rfc-editor.org/rfc/rfc5210>.
[RFC4364]
Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, , <https://www.rfc-editor.org/rfc/rfc4364>.
[RFC5635]
Kumari, W. and D. McPherson, "Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF)", RFC 5635, DOI 10.17487/RFC5635, , <https://www.rfc-editor.org/rfc/rfc5635>.
[RFC6811]
Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, , <https://www.rfc-editor.org/rfc/rfc6811>.
[RFC4786]
Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, , <https://www.rfc-editor.org/rfc/rfc4786>.
[RFC7094]
McPherson, D., Oran, D., Thaler, D., and E. Osterweil, "Architectural Considerations of IP Anycast", RFC 7094, DOI 10.17487/RFC7094, , <https://www.rfc-editor.org/rfc/rfc7094>.

10.2. Informative References

[intra-domain]
"Source Address Validation in Intra-domain Networks Gap Analysis, Problem Statement, and Requirements", , <https://datatracker.ietf.org/doc/draft-li-savnet-intra-domain-problem-statement/>.
[manrs]
MANRS, "MANRS Implementation Guide", , <https://www.manrs.org/netops/guide/antispoofing/>.
[isoc]
Internet Society, "Addressing the challenge of IP spoofing", , <https://www.internetsociety.org/resources/doc/2015/addressing-the-challenge-of-ip-spoofing/>.
[nist]
NIST, "Resilient Interdomain Traffic Exchange: BGP Security and DDos Mitigation", , <https://www.nist.gov/publications/resilient-interdomain-traffic-exchange-bgp-security-and-ddos-mitigation>.
[urpf]
Cisco Systems, Inc., "Unicast Reverse Path Forwarding Enhancements for the Internet Service Provider-Internet Service Provider Network Edge", , <https://www.cisco.com/c/dam/en_us/about/security/intelligence/urpf.pdf>.

Acknowledgements

Many thanks to Jared Mauch, Barry Greene, Fang Gao, Anthony Somerset, Kotikalapudi Sriram, Yuanyuan Zhang, Igor Lubashev, Alvaro Retana, Joel Halpern, Aijun Wang, Michael Richardson, Li Chen, Gert Doering, Mingxing Liu, John O'Brien, Roland Dobbins, etc. for their valuable comments on this document.

Authors' Addresses

Jianping Wu
Tsinghua University
Beijing
China
Dan Li
Tsinghua University
Beijing
China
Libin Liu
Zhongguancun Laboratory
Beijing
China
Mingqing Huang
Huawei
Beijing
China
Lancheng Qin
Tsinghua University
Beijing
China
Nan Geng
Huawei
Beijing
China