TICTOC Y. Xu
Internet-Draft Huawei Technologies
Intended status: Standards Track October 16, 2010
Expires: April 19, 2011
IPsec security for packet based synchronization
draft-xu-tictoc-ipsec-security-for-synchronization-00.txt
Abstract
Cellular networks often use Internet standard technologies to handle
synchronization. This document analyses the need for security
methods for synchronization messages distributed over the Internet.
This document also gives a solution on how to mark the
synchronization message when IPSec is implemented in end to end
frequency synchronization."
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 http://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 April 19, 2011.
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
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
Xu Expires April 19, 2011 [Page 1]
Internet-Draft IPsec security for synchronzation October 2010
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology used in this document . . . . . . . . . . . . . . 5
3. Security requirements for synchronization . . . . . . . . . . 5
4. Security mechanism for synchronization . . . . . . . . . . . . 5
5. ESP format enhancement . . . . . . . . . . . . . . . . . . . . 6
5.1. Existing ESP format . . . . . . . . . . . . . . . . . . . 7
5.2. Flexible ESP format . . . . . . . . . . . . . . . . . . . 8
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. IPv4/v6 consideration for IPsec based sychronization . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Xu Expires April 19, 2011 [Page 2]
Internet-Draft IPsec security for synchronzation October 2010
1. Introduction
When transfering timing in internet, a shared infrastructure is used,
and hence the path is no longer physically deterministic. It leaves
open the possibility to disrupt, corrupt or even spoof the timing
flow, where a timing signal purports to come from a higher quality
clock than it actually does. In the extreme, this may be used to
attack the integrity of the network, to disrupt the synchronization
flow, or cause authentication failures. On the other hand, it may be
possible for unauthorized users to request service from a clock
server. This may overload a clock server and compromise its ability
to deliver timing to authorized users.
For the cellular backhaul applications, two kinds of synchronization
is needed, one is the recovery of an accurate and stable frequency
synchronization signal as a reference for the radio signal (e.g.
GSM, UMTS FDD, LTE FDD). In addition to frequency synchronization,
phase/time synchronization are also needed in Mobile technologies,
This is the case for the TDD technologies such as UMTS TDD,LTE TDD.
Frequency synchronization is normally implemented in an end-to-end
scenario where none of the intermediate nodes in the network have to
recognize and process the synchronization packets. However In phase/
time synchronization, a hop-by-hop scenario will request intermediate
nodes to process the synchronization packets If very accurate phase/
time is needed (e.g. sub-microsecond accuracy).
Femtocell is the typical cellular backhaul application that requires
time synchronization. A Femtocell is defined as a wireless base
station for deployment in residential environments and is typically
connected to the mobile core network via a public broadband
connection (eg., DSL modem, cable modem). Femtocell improves
cellular network coverage and saves cost for operators. Just like a
typical macrocell (larger base station), Femtocells (residential base
stations) require a certain level of synchronization (frequency or
phase/time) on the air interface, predominantly frequency
requirements.
The [3GPP.33.320] specification defines some of the high-level
network architecture aspects of a Home NodeB (3G UMTS) and a Home
eNodeB (4G LTE). In addition, the Femto Forum organization also
provides a network reference model very similar to 3GPP. Both
architectures have commonalities as illustrated in Figure 1.
Xu Expires April 19, 2011 [Page 3]
Internet-Draft IPsec security for synchronzation October 2010
+-------------+
| |
| Femtocell |<-----------------------------+
| | |
+-------------+ |
|
|
/---------------------\
| |
| Public Network |
| |
\---------------------/
|
|
+------------+ +-------------+ |
|Clock Server|---------->| | |
+------------+ | | |
| Security GW |->---+
+------------+ | |
|Femto GW |---------->| |
+------------+ +-------------+
Figure 1. Typical Architecture of a Femtocell Network
The network architecture shows that a public network is used to
establish connectivity between Femtocell and core network elements
(e.g., Security Gateway, Femto Gateway, Clock server, etc.). With
respect to synchronization process, Femtocell will therefore see
synchronization messages exchanged over the public network (e.g,
Internet). This presents a set of unique challenges for mobile
operators.
One challenge involves the security aspects of such the Femto
architecture. In both reference models, the communication between
Femtocell and Femto Gateway is secured by a mandatory Security
Gateway function. The Security Gateway is mandatory since the Femto
Gateway and Clock server communicate to Femtocell via a public
backhaul broadband connection (also known as the 3GPP iuh interface
or Femto Forum Fa interface). The [3GPP.33.320] specification
requires that the Femtocell SHALL support receiving time
synchronization messages over the secure backhaul link between
Femtocell and the Security Gateway, and Femtocell SHALL use IKEv2
protocol to set up at least one IPsec tunnel to protect the traffic
with Security Gateway.
Xu Expires April 19, 2011 [Page 4]
Internet-Draft IPsec security for synchronzation October 2010
This document provides analysis on security requirements for packet-
based synchronization and proposes IPsec security solution for end to
end frequency synchronization.
2. Terminology 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 [RFC2119].
3. Security requirements for synchronization
The ITUT [G.8265] specification provides general consideration on
synchronization security. Because packet-based timing streams may be
observed at different points in the network, there may be cases where
timing packets flow across multiple network domains which may
introduce specific security requirements. There may also be aspects
of security that may be related to both the network (e.g.
authentication and/or authorization) and to the synchronization
protocol itself. ITUT [G.8265] specification recommends to use
existing, standards-based security techniques to help ensure the
integrity of the synchronization. Examples may include encryption
and/or authentication techniques, or network techniques for
separating traffic, such as VLANs or LSPs. Specifically for the
performance issue, it may not be possible to implement some security
requirements without actually degrading the overall level of timing
or system performance. From above analysis, following
synchronizations requirements are listed:
1. synchronization client SHOULD be prevented from connecting to
rogue clock servers
2. clock servers SHOULD be prevented from providing service to
unauthorized synchronization client
3. Security mechanisms to achieve synchronization SHOULD minimize
any degradation in performance and this side effect SHOULD be
controlled to meet specific synchronization requirements(e.g.,
Femtocell synchronization)
4. Security mechanism for synchronization
There are mainly two kinds of security mechanism used in current
synchronization: authentication-based and encryption-based.
For the authentication-based security mechanism, a shared secret key
between the synchronization client and the clock servers is used to
compute an authentication code (known as an "Integrity Check Value",
Xu Expires April 19, 2011 [Page 5]
Internet-Draft IPsec security for synchronzation October 2010
ICV) over the entire message datagram. [IEEE1588] contains an
experimental security annex defining an authentication-based
approach. This approach also implements a challenge-response
mechanism to confirm the creation of any security association (SA)
between a clock servers and a synchronization client. A limitation
of the process is that no method of sharing the key is proposed in
[IEEE1588]. This MUST be handled by other means.
For the encryption-based security mechanism, a shared-key approach is
also used. Instead of creating an ICV, the shared key is used to
encrypt the contents of the packet completely. The encryption might
be performed in the synchronization device itself, or it might be
performed in a separate device, e.g. a secure gateway. An example
might be where the timing packets have to pass through an encrypted
tunnel (e.g. an IPSec tunnel). Full encryption might be required for
various reasons. The contents of the packet may be considered
secret, such as might be the case where accuracy of the time
distribution is being sold as a service. Alternatively, it may be
because other traffic from a device is considered secret, and hence
it is easier to encrypt all traffic.
IPsec,as a popular security mechanism, is being considered in some
mobile applications, especially in case of unsecure backhaul links
(e.g. Femtocells, [3GPP.33.320]) being involved. IPsec can provide
data source authentication, confidentiality, integrity that is
suitable to end to end synchronization without intermediate nodes .
For example, if only frequency synchronization is needed, an end-to-
end scenario where none of the intermediate nodes in the network have
to recognise and process the synchronization packets might be
suitable to use IPsec security mechansim. In this case, the
synchronization packets will be encrypted if the packed is
transported in the IPSec tunnel.
IPsec can meet synchronization rquirement 1 and 2 in section 3,
however IPsec still need some enhancement to meet requirement 3 .
Normally, device will decrypt IPSec message in IP layer, but in order
to improve the synchronization accuracy, some synchronization
protocol (e.g. [IEEE1588]) requests to process the synchronization
message in hardware, therefore the synchronization device may need to
identify synchronization messages in physical layer before the
message is decrypted. How to identify the synchronization messages
in IPsec becomes the most important issue to keep the synchronization
accuracy in IPsec synchronization scenario.
5. ESP format enhancement
As discussed above section, it has advantage to identify whether the
Xu Expires April 19, 2011 [Page 6]
Internet-Draft IPsec security for synchronzation October 2010
tunnel packets received by synchronization client are the special
timing packets or not. This section proposes a solution to identify
the timing packets When using IPsec to protect the whole time
synchronization message. The main thought is to use time packet
identifier which is included in a new defined flexible ESP format to
identify whether the received data packet is a timing packet or not.
5.1. Existing ESP format
ESP provides confidentiality, data integrity, access control, and
data source authentication to IP datagrams as specified in [RFC4303].
The ESP contains several parts (Figure 2): Security Parameters
Index(SPI) and Sequence Number(SQN),ESP Payload,ESP trailer and the
ICV. SPI and SQN are used to identity a SA and replay protection
respectively. ESP trailer is comprised of Padding, Pad length, Next
Header. The integrity scope is from SPI to Next Header. The
encryption protection is provided for the Payload Data and ESP
trailer. For SPI and SQN, only the authentication of data integrity
is provided.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
| Security Parameters Index (SPI) | ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| Sequence Number | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
| Payload Data* (variable) | | ^
~ ~ | |
| | |Conf.
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| | Padding (0-255 bytes) | |ered*
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Next Header | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| Integrity Check Value-ICV (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. Top-Level Format of an ESP Packet
Except for the fields discussed above, there are no other reserved
bits in ESP. However, In the protection of time packets over IPsec
scenario, the time packet is encrypted in Payload Data, the receiver
could not identify whether it is the time packet or not.
Xu Expires April 19, 2011 [Page 7]
Internet-Draft IPsec security for synchronzation October 2010
5.2. Flexible ESP format
This documents proposes to define a new flexible ESP format. The new
extended ESP format not only contains the fields described in
[RFC4303], but also has additional authentication information. The
additional authentication information is comprised of ESP special
usage flags(one octet zeros),extended data type, extended data
length, and Authentication Payload (Figure 3). In the extended ESP
additional authentication information, it includes a data type to
identify the time packets, and could also identify whether the time
packet is the event message or not by addintional time-packet
information in Authentication Payload. In addition, the
authentication of data integrity for the whole extended Data is
provided. The figure of the proposed flexible ESP format is as
following:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (32-bit) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| Authentication Payload (variable) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Data* (variable) |
~ ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding (0-255 bytes) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Pad Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Check Value-ICV (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. New defined ESP format with 32-bit Sequence Number
o Security Parameters Index(32-bit)-Defined in [RFC4303].
Xu Expires April 19, 2011 [Page 8]
Internet-Draft IPsec security for synchronzation October 2010
o Sequence Number (32-bit or the extended 64-bit)-Defined in
[RFC4303].
o One octet zero bits - The inspection bits, used to distinguish
from the existing ESP.
o ED-Type(Extended Data Type (8-bit))- The message type flag in
extended additional authentication information which indicates the
message type in encryped Payload Data.
o ED-Length(Extended Data Length (16-bit))- The length of extended
additional authentication data contains the whole extended
additional authentication information.
o Authentication Payload- It contains additional message
information, and also contains the information of integrity for
extended data, such as, integrity algorithm, and the extended data
integrity check value. it is an optional part to provide more
information of encrypted messages in Payload Data and also provide
authentication of data integrity for extended data, which includes
One octet zero bits, Extended Data Type, Extended Data Length and
Authentication Payload data.
o Other fields- Defined in [RFC4303].
In Femtocell scenario, as the link between Security Gateway and clock
server is normally security path, the message transmitted between
them are in plain text. When Security Gateway receives the message,
it identifies the time packet at first, then put appropriate value to
Data type field to identify the message type in Payload Data, after
that, it could put more packet information into Authentication
Payload, such as UDP port number or timestamps, then Extended Data
Length, Algorithm ID, Extended Data integrity Check value (Figure 4),
could also be filled consequently. following figure illustrates on
how to use this new flexible ESP format to identify time packet.
Xu Expires April 19, 2011 [Page 9]
Internet-Draft IPsec security for synchronzation October 2010
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (32-bit) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 1| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Time packets information ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Algorithm or Algorithm ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time packets identifier ICV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Data* (variable) |
~ ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding (0-255 bytes) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Pad Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Check Value-ICV (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. New defined ESP format with 32-bit Sequence Number for
time-packet
o Extended Data Type (8-bit) - The value 0x1 here indicates that the
extended context is time packet.
o Extended Data Length (16-bit)- The length of whole extended
additional authentication data
o Time packets information(variable)- the addintional message
information, such as UDP port number or timestamps. It is a part
of Authentication payload.
o Algorithm or Algorithm ID- It indicates which algorithm could be
used to generate the extended data ICV. It is a part of
Authentication payload.The integrity algorithm negotiated during
IKEv2 could be used, also Algorithm ID field in the extended
additional authentication data could be marked to indicate the
integrity algorithm, such as HMAC- SHA1, HMAC-256, or others. It
Xu Expires April 19, 2011 [Page 10]
Internet-Draft IPsec security for synchronzation October 2010
is a part of Authentication payload.
o Extended Data integrity Check value (variable) - Time packets
identifier integrity Check value.It is a part of Authentication
payload.
Time packets information, Algorithm or Algorithm ID and Extended Data
integrity Check value form the Authentication Payload, it is an
optinal field and used to guarantee the integrity of transmission.
As the integrity protection is only for the Extended Data but not for
the whole ESP packet, the time delay of calculation can be decreased.
In addition, if the integrity protection is not necessary, this part
of security validation could be ignored.
6. Example
In this section, the procedure to identify time packet in Security
Gateway scenario is depicted.
+-------------+ +------------+ +-------------+
| | | | | |
| Femtocell |<-------------------->|Security GW |-----|Clock Server |
| | | | | |
+-------------+ +------------+ +-------------+
| establish IPSec Tunnel | |
|<--------------------------------->| |
| | |
| Sync Request | |
|-----------------------------------|------------------>|
| | |
| Sync Response | |
|<----------------------------------|-------------------|
| | |
| message with time packets | |
|<----------------------------------|-------------------|
| | |
+--------------+ | |
|identify the | | |
|timing packet | | |
| | | |
+--------------+ | |
Figure 5. example procedure
In the Security Gateway scenario, The IPsec with tunnel mode is
established between Femtocell and Security Gateway. After Femtocell
Xu Expires April 19, 2011 [Page 11]
Internet-Draft IPsec security for synchronzation October 2010
and Clock server exchange the Sync Request and Sync Response, the
clock server will send the time packets to Femtocell to implement
frequency synchronization with the protection of IPsec tunnel. When
Femtocell receives the message, it can identify whether it is time
packet, and can also identify whether the time packet is the event
message by the time packet information in the unencryped field as
defined in the new ESP format. If the message is time packet and
identifies that it is the event message, Femtocell will do special
process for the event message, such as recording the message
receiving time. On the server side, When Security Gateway receives
the message, it identifies the time packet at first, then put
appropriate value to Data type field to identify the message type in
Payload Data, after that, it could put more packet information into
Authentication Payload, such as UDP port number or timestamps, then
Extended Data Length, Algorithm ID, Extended Data integrity Check
value, could also be filled consequently.
7. IPv4/v6 consideration for IPsec based sychronization
IPsec is a security mechanism used both for IPv4 and IPv6, and ESP-
based solution has no impact on the IPv4 header and makes the
transition/migration from IPv4 to IPv6 seamless.
8. Security Considerations
This protocol variation inherits all the security properties of
regular ESP as described in [RFC4303].
This document defines a new flexible ESP format, which contains
Extended Data Type Extended Data Length and additional authentication
paylaod. The authentication of data integrity for the extended data
is provided, and the data type is carried in the unencryption part.
Therefore the receiver could identify whether the receiving messages
are time packets or not.
9. IANA Considerations
There have been no IANA considerations so far in this document.
10. Acknowledgments
The authors appreciate the valuable work and contribution done to
this document by Marcus Wong.
Xu Expires April 19, 2011 [Page 12]
Internet-Draft IPsec security for synchronzation October 2010
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
11.2. Informative References
[3GPP.33.320]
3GPP, "Security of Home Node B (HNB) / Home evolved Node B
(HeNB)", 3GPP TS 33.320 10.0.0, October 2010.
[G.8265] IEEE, "Architecture and requirements for packet based
frequency delivery", V0.2 June 2010.
[IEEE1588]
IEEE, "Standard for A Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems",
IEEE Std 1588-2008.
Author's Address
Yixian Xu
Huawei Technologies
Huawei Building, Xinxi Road No.3
Haidian District, Beijing 100085
P. R. China
Phone: +86-10-82836300
Email: xuyixian@huawei.com
Xu Expires April 19, 2011 [Page 13]