One document matched: draft-irtf-mobopts-location-privacy-solutions-00.txt
Mobopts Working Group Y. Qiu
Internet-Draft Institute for Infocomm Research
Expires: August 30, 2006 F. Zhao
UC Davis
R. Koodli
Nokia Research Center
February 26, 2006
Mobile IPv6 Location Privacy Solutions
draft-irtf-mobopts-location-privacy-solutions-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 30, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Mobile IPv6 [1] is an IP layer mobility protocol which allows mobile
nodes to remain reachable while moving around on the Internet. With
the existing specification, a mobile node's movement can be tracked
by simply monitoring the IP addresses in communication involving the
mobile node. In this document, we propose techniques for hiding a
Qiu, et al. Expires August 30, 2006 [Page 1]
Internet-Draft MIP6 location privacy solutions February 2006
mobile node's location information from eavesdroppers as well as from
correspondent nodes. The proposed techniques are efficient and fully
compatible with the base Mobile IPv6 operation.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Analysis of Location Privacy in MIP6 . . . . . . . . . . . . . 4
3. Hiding Mobile Node's Location Movement Information . . . . . . 5
3.1. Pseudo Home Address . . . . . . . . . . . . . . . . . . . 5
3.2. Hiding HoA within Home Binding Update . . . . . . . . . . 5
3.3. Hiding CoA via Reverse Tunneling Mode . . . . . . . . . . 6
3.4. Hiding HoA from an Eavesdropper in Route Optimization . . 7
3.4.1. Home Test Init from the Mobile Node . . . . . . . . . 7
3.4.2. Home Test from Correspondent Node . . . . . . . . . . 8
3.4.3. Correspondent Binding Update . . . . . . . . . . . . . 8
3.4.4. The increment of Sequence Numbers . . . . . . . . . . 9
3.4.5. Traffic Packets between Mobile Node and
Correspondent Node . . . . . . . . . . . . . . . . . . 10
4. Location Privacy with Unmodified RR Signaling . . . . . . . . 11
4.1. Route-Optimized Binding Update to CN . . . . . . . . . . . 11
4.1.1. The generation of the privacy management key, Kpm . . 11
4.1.2. Route-Optimized Binding Update to CN directly . . . . 11
4.2. Reverse-tunneled Binding Update to CN . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5.1. Hiding a MN's Location Information from its CN and
from an Eavesdropper in Reverse Tunneling Mode . . . . . 14
5.2. Hiding a MN's Location Movement Information from an
Eavesdropper in Route Optimization . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
Qiu, et al. Expires August 30, 2006 [Page 2]
Internet-Draft MIP6 location privacy solutions February 2006
1. Introduction
IP Address Location Privacy in the presence of IP Mobility is an
important problem for which some solutions are already frequently
discussed. However, details are not documented. Furthermore,
solutions for Home Address profiling may benefit from more
investigation. In this document, we briefly discuss the problem and
then specify the details of solutions. We introduce a "Pseudo Home
Address" as a mechanism to hide Home Address during route-optimized
communication. The IP address location privacy problem is specified
in detail in [2].
In the protocol, we focus on the threats to location privacy posed by
the passive entities. In order to compromise the location privacy
successfully, the passive entities are usually required to be at
certain locations, for example, an eavesdropper along certain paths
taken by the traffic between MN, HA and CN. The threats posed by the
active attackers are out of scope for now. Also we only consider the
location privacy of MN; thus we assume both CN and HA are fixed node
in order to simplify the scenarios. While in the real deployment, CN
or HA might be mobile as well, the same analysis and solution for MN
may also apply in these cases.
We categorize the threats related to location privacy in MIP6 from
the passive entities into the following two kinds: IP address
location privacy and profiling attacks.
The issue of IP address location privacy means that other entities
can learn the location information of MN from its IP addresses
without authorization. In the presence of mobility, there are two
problems related to IP address location privacy: Disclosing a new IP
address (CoA) to a correspondent, and revealing a fixed IP address
(HoA) to an eavesdropper. So, a MN may not mind using a fixed Home
Address with a correspondent but may not wish to disclose its new
Care-of Address, whereas it may not wish to reveal its Home Address
to an on-looker, but has to use the CoA from its visited network.
The issue of profiling attacks means that other entities can enrich
its knowledge about MN, for example by linking the activities of MN
and then analyzing the collected information. With the enlarged
knowledge base together with other additional background information
about MN, other entity can compromise the location privacy of MN with
a higher probability.
The scope of this protocol will be limited the issue of IP address
location privacy. And we use the commonly adopted terminology
defined in [1] and [2] in this document.
Qiu, et al. Expires August 30, 2006 [Page 3]
Internet-Draft MIP6 location privacy solutions February 2006
2. Analysis of Location Privacy in MIP6
Current MIP6 specification does not consider location privacy. For
example, both CoA and HoA are available to on-lookers in the
following messages:
o Home Binding Update and Acknowledgement
o Correspondent Binding Update and Acknowledgement
o Prefix Discovery
o Data packets between MN and CN in the Route Optimization mode
Also HoA is available in the HoTi/HoT message on the HA-CN path.
Hence, the CN, on-lookers and even the HA can inspect copies of
packets from MN, and learn the complete location information
deterministically without MN's authorization.
In Route Optimization Mode, where the MN must use CoA as the source
IP address in the communication with HA and CN, both its peers and
eavesdropper can learn CoA. In order to protect the location
privacy, MN must use some way to conceal its real HoA. If the MN is
always the initiator of a communication, MN can conceal its HoA from
both the CN and the on-looker. However, if the CN is the initiator
of a communication, the CN certainly knows the MN's HoA, and then
MN's CoA. Therefore, in this case, MN can only conceal its HoA from
the on-lookers.
In Reverse Tunneling Mode, a MN can hide its current location from
the CN by reverse tunneling all its traffic through the Home Agent.
The MN, in addition can hide its Home Address from any eavesdroppers
on the access network by also reverse tunneling IPsec-encrypted
Mobile IP signaling and data traffic with its Home Agent.
Qiu, et al. Expires August 30, 2006 [Page 4]
Internet-Draft MIP6 location privacy solutions February 2006
3. Hiding Mobile Node's Location Movement Information
3.1. Pseudo Home Address
It is desirable not to reveal the real Home Address at all in the
mobile node's communication. So, some other field can be used to
substitute the real HoA, but such a field must be communicated
securely and the field itself must not become a target of profiling.
We define a field called a "Pseudo Home Address", which is sent as a
destination option in place of the Home Address. The field is used
by the home agent and correspondent to recover the real Home Address
from the Pseudo Home Address in packets among MN, HA and CNs.
The computation of Pseudo Home Address is as follows:
Pseudo_HoA = HMAC_SHA1(Kph, Previous Pseudo_HoA))
Where the Kph could be derived from the secret key pre-established
manually between the MN and HA or derived from the secret key set up
during IKE phase 1 between the MN and the HA.
3.2. Hiding HoA within Home Binding Update
When MN moves to a new foreign subnet, it sends the following
modified Home Binding Update to its HA:
o IPv6 header (source = CoA, destination = HA)
o Destination option header
* Home Address option (Pseudo_HoA)
o ESP header in transport mode
o Mobility header
* Home Binding Update
* Alternative CoA option (CoA)
And HA replies to MN with the following modified Home Binding
Acknowledgement:
o IPv6 header (source = HA, destination = CoA)
o Destination option header
Qiu, et al. Expires August 30, 2006 [Page 5]
Internet-Draft MIP6 location privacy solutions February 2006
* Home Address option (Pseudo_HoA)
o ESP header in transport mode
o Mobility header
* Home Binding Acknowledgement
Note that Pseudo_HoA is used instead of the real HoA in above
messages. In case MN fails to receive the Binding Acknowledgement,
it will retransmit the Binding Update but with a new sequence number
in order to detect a replay attack. Upon the successful binding
update, MN and HA each computes a new PseudoHoA as described in above
section.
They then replace the previous Pseudo_HoA with the new one in their
respective data record and in their respective Home BU cache:
PseudoHoA (as the index of the entry)
HoA (as the index of the entry)
CoA
Lifetime
......
3.3. Hiding CoA via Reverse Tunneling Mode
To hide its CoA from the CN and its HoA from an eavesdropper, the MN
communicates Mobile IP signaling and IP data packets with its HA via
reverse tunneling.
When the MN sends a Home Binding Update from a visited network to its
HA, it uses the following packet form to hide its HoA from being
monitored on the access network:
o IPv6 header (source = CoA, destination = HA)
o Destination option header
* Home Address option (Pseudo_HoA)
o ESP header in transport mode
o Mobility header
Qiu, et al. Expires August 30, 2006 [Page 6]
Internet-Draft MIP6 location privacy solutions February 2006
* Binding Update
* Alternative CoA option (CoA)
The HA uses the following packet form to reply a Binding
Acknowledgement to the MN that is not on the home link:
o IPv6 header (source = HA, destination = CoA)
o Routing header (type 2)
* Pseudo_HoA
o ESP header in transport mode
o Mobility header
* Binding Acknowledgement
In case the MN fails to receive the Binding Acknowledgement, the MN
will retranismit the Binding Update but with a new sequence number in
order to detect replay attack.
The MN and HA each computes a new Pseudo HoA as described in Section
3.1.
The MN and HA then each replace the old Pseudo_HoA with the new one
in their respective databases. This updating of Pseudo_HoA is only
performed once right after the successful home binding update and
acknowledgement.
3.4. Hiding HoA from an Eavesdropper in Route Optimization
3.4.1. Home Test Init from the Mobile Node
The MN sends HoTI to HA with the following packet form:
o IPv6 header (source = CoA, destination = HA)
o ESP header in tunneling mode
o IPv6 header (source = HoA, destination = CN)
o Mobility header
* HoTI
The HoTI is then forwarded to the CN in the following form:
Qiu, et al. Expires August 30, 2006 [Page 7]
Internet-Draft MIP6 location privacy solutions February 2006
o IPv6 header (source = HA, destination = CN)
o Destination option
* Pseudo_HoA
o Mobility header
* HoTI
3.4.2. Home Test from Correspondent Node
Upon receiving the HoTI from HA, the CN replies with HoT in the
following form:
o IPv6 header (source = CN, destination = HA)
o Destination option
* Pseudo_HoA
o Mobility header
* HoT = (home init cookie, home keygen token, home nonce index)
where home keygen token = First (64, HMAC_SHA1(Kcn, (Pseudo_HoA |
nonce | 0))) and Kcn is the CN's local secret [1].
Upon receiving the packet, HA, using Pseudo_HoA as an index,
retrieves HoA and CoA from the Home BU cache, generates a new HoT
packet and forwards the packet to MN:
o IPv6 header (source = HA, destination = CoA)
o ESP header in tunneling mode
o IPv6 header (source = CN, destination = HoA)
o Mobility header
* HoT = (home init cookie, home keygen token, home nonce index)
3.4.3. Correspondent Binding Update
The MN sends the CoTI to the CN and the CN replies to the MN with
CoT, in exactly the same ways as specified in the RR test [1].
After receiving the HoT and CoT, the MN sends the Binding Update to
Qiu, et al. Expires August 30, 2006 [Page 8]
Internet-Draft MIP6 location privacy solutions February 2006
the CN in the following packet form:
o IPv6 header (source = CoA, destination = CN)
o Destination Option
* E(Kbm, HoA)
o Mobility header
* Binding Update = (Pseudo_HoA, home nonce index, ...)
where Kbm is the binding update key given by
o Kbm = SHA1 (home keygen token | care-of keygen token)
o home keygen token = First (64, HMAC_SHA1(Kcn, (Pseudo_HoA | nonce
| 0)))
o care-of keygen token = First (64, HMAC_SHA1(Kcn, (CoA | nonce |
1)))
and E(Kbm, HoA) is a symmetric key encryption of the HoA under the
secret binding update key Kbm.
After receiving the BU, the CN first computes home keygen token and
care-of keygen token. The CN then computes Kbm and decrypts E(Kbm,
HoA) to recover HoA. The CN then keeps both HoA and Pseudo HoA in
its binding cache table. The subsequent data traffic between the MN
and the CN will follow the same procedure and packet format as
specified in [1] except that the Pseudo HoA is used in place of the
HoA.
3.4.4. The increment of Sequence Numbers
RFC 3775 [1] only requires that the sequence number field in the
Binding Update is greater than the Sequence Number received in the
previous valid Binding Update for this home address. However, if the
increment of sequence number is fixed, an eavesdropper is also able
to guess the MN's movement by monitoring a series of BU messages.
Here the increment of sequence number is defined as
seq#_increment = First(8, HMAC_SHA1(Kbm, home nonce index | care
nonce index));
then
Qiu, et al. Expires August 30, 2006 [Page 9]
Internet-Draft MIP6 location privacy solutions February 2006
Seq# = previous Seq# + seq#_increment.
In order to avoid exceeding easily the 16 bit range of se-quence
number and keep enough random numbers, we pick up the first 8 bits
from the result of the keyed pseudo function.
If seq#_increment = 0, then set
seq#_increment = 1.
As the increment of sequence number is not fixed now, MN needs to
deal with the case when it reaches 2^16-1. If the new Seq# > 2^16-1,
then MN sets the new Seq# to 2^16-1.
3.4.5. Traffic Packets between Mobile Node and Correspondent Node
The subsequent data traffic between MN and CN will follow the same
procedure and packet format as specified in [1] except that
Pseudo_HoA is used in place of HoA:
Packets from MN to CN:
o IPv6 header (source = CoA, destination = CN)
o Destination option
* Pseudo_HoA
o Payload
Packets from CN to MN:
o IPv6 header (source = CN, destination = CoA)
o Routing Header
* Pseudo_HoA
o Payload
Qiu, et al. Expires August 30, 2006 [Page 10]
Internet-Draft MIP6 location privacy solutions February 2006
4. Location Privacy with Unmodified RR Signaling
In this section, we present an IP address location privacy mechanism
without any modification on the original RR test, which would help
ease the transition to a Mobile IPv6 management solution with the
support of location privacy.
The basic idea is that both CN and MN derive a shared privacy
management key, Kpm, from the keygen tokens achieved in the home
address and care-of address test procedures; afterwards, MN uses Kpm
to hide its home address in the Binding Update to CN; and finally CN
authenticates the received Binding Update and restores the MN'S home
address therein.
4.1. Route-Optimized Binding Update to CN
4.1.1. The generation of the privacy management key, Kpm
MN and CN may use a different key from Kbm for the purpose of
location privacy. In the following we describe the details to
generate a so-called privacy management key, Kpm.
With the home address test and the care-of address test, a care-of
keygen token and a home keygen token are generated in the same way as
in the original RR test. The privacy management key, Kpm, is then
generated as follows:
Kpm = SHA1 (home keygen token | care-of keygen token | 0)
4.1.2. Route-Optimized Binding Update to CN directly
In the original RR test, the home address is visible in the Binding
Update to CN. MN can make the home address invisible to on-lookers
by replacing the HoA with a Pseudo Home Address generated from the
original Home Address and Kpm as follows:
Pseudo Home Address = E(Kpm, Home Address)
where E is an encryption algorithm, such as AES.
The format of the Binding Update to CN is as follows:
o Source Address = care-of address
o Destination Address = correspondent
o Parameters:
Qiu, et al. Expires August 30, 2006 [Page 11]
Internet-Draft MIP6 location privacy solutions February 2006
* Pseudo home address
* sequence number
* home nonce index
* care-of nonce index
* First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent |
BU)))
When CN receives this BU message, CN firstly verifies the MAC based
on the re-generated Kbm. If it is successful, CN recovers the home
address from the Pseudo home address:
Home Address = D(Kpm, Pseudo Home Address)
where D is a decryption algorithm.
CN may also use this information to update its Binding Update cache.
Also CN may send back a Binging Acknowledgement if requested:
o Source Address = correspondent
o Destination Address = care-of address
o Parameters:
* Sequence number
* First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent |
BA)))
4.2. Reverse-tunneled Binding Update to CN
MN may send the BU not directly to CN, but via HA. In this case, the
packet header format is as follows:
o IPv6 header (source = care-of address, destination = home agent)
o ESP header in tunnel mode
o IPv6 header (source = home address, destination = correspondent
node)
o Destination Option
Qiu, et al. Expires August 30, 2006 [Page 12]
Internet-Draft MIP6 location privacy solutions February 2006
* Pseudo Home Address
o Mobility header
* Binding Update
* Alternate Care-of Address option (care-of address)
The privacy management key Kpm is the same as the binding management
key Kbm.
When a CN receives a BU with an alternate-CoA option and a new
destination option containing the Pseudo Home Address, it first
computes the Kbm, verifies the MAC for the Binding Update, and then
recovers the Home Address from the Pseudo Home Address, and verifies
if it is actually the Home Address present in the source IP address.
When the Binding Update is reverse-tunneled through the Home Agent,
the Home Address is visible as the source IP address along the HA-CN
path. However the on-lookers on the HA-CN path can launch the attack
to compromise the RR test anyway.
Qiu, et al. Expires August 30, 2006 [Page 13]
Internet-Draft MIP6 location privacy solutions February 2006
5. Security Considerations
The modified binding update procedures and data packets presented
above can be explored to achieve two objectives: 1) hiding the
location information of a mobile node from its correspondent node as
well as from an eavesdropper when data packets are communicated in
the reverse tunneling mode, and 2) hiding a mobile node's location
movement information from an eavesdropper during route optimization.
5.1. Hiding a MN's Location Information from its CN and from an
Eavesdropper in Reverse Tunneling Mode
When MN roams to a new foreign subnet, it sends the modified home
binding update (BU) to its HA and the HA replies with the modified
home binding acknowledgement (BA). Note that in both BU and BA,
Pseudo_HoA is used in place of HoA; hence an eavesdropper will not be
able to relate CoA to HoA. Moreover, the value of Pseudo_HoA is
updated continually whenever MN moves to a new subnet. As a result,
the eavesdropper is not able to link past Pseudo_HoA values.
In the reverse tunneling mode, CN continues to send data packets to
MN's HoA since it is not aware of the movement of MN. Data packets
from CN are intercepted by HA and are tunneled to MN's CoA. To
tunnel intercepted packets, HA encapsulates the packets using IPsec
ESP tunneling mode which encrypts the inner IPv6 header where HoA is
used in destination option, with the outer IPv6 header addressed to
MN's CoA.
5.2. Hiding a MN's Location Movement Information from an Eavesdropper
in Route Optimization
In the route optimization mode, since MN and CN communicate with each
other directly, obviously it is not possible to hide MN's location
(i.e., CoA) from CN. The best we can hope for is to hide MN's
location movement from an eavesdropper. This is accomplished as
follows.
When MN moves to a new foreign subnet, it first performs the modified
home binding update procedure given in section 3. As discussed
before, this procedure does not disclose the relationship between HoA
and CoA and therefore prevents an eavesdropper from learning the
current location of MN. The procedure also updates Pseudo_HoA values
whenever MN enters a new subnet in order to avoid the eavesdropper
from tracing MN's movement from one subnet to another.
To initiate the route optimization mode, MN next performs the
modified correspondent binding update procedure described in section
3. It is easy to see that none of these messages relates HoA with
Qiu, et al. Expires August 30, 2006 [Page 14]
Internet-Draft MIP6 location privacy solutions February 2006
CoA. Hence, the eavesdropper, observing all the message flows, may
learn that a node is at CoA but is not able to relate it to the
target MN. The same observation applies to the data packets.
6. IANA Considerations
This document may specify IANA Type assignment(s) in subsequent
versions.
Qiu, et al. Expires August 30, 2006 [Page 15]
Internet-Draft MIP6 location privacy solutions February 2006
7. Conclusion
In this document, we introduced solutions to protect location
information of mobile node. The proposed techniques are efficient
and fully compatible with the base Mobile IPv6 operation.
With our techniques, a mobile node's location information can be
hidden from eavesdroppers during route optimization and further
hidden from its correspondent node during reverse tunneling. The
basic idea is that a pseudo HoA is used in place of the MN's real HoA
for all packets to and from the MN, and the pseudo HoA is updated
whenever MN moves to a new location. As a result, the binding
between the CoA and the HoA cannot be derived by an eavesdropper (or
even by the correspondent node in the reverse tunneling mode).
Moreover, as the pseudo HoA is never used as a communicating address,
the process of IP reachable checking and DNS updates could be
avoided.
8. References
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[2] Koodli, R., "IP Address Location Privacy and Mobile IPv6:
Problem Statement", draft-irtf-mobopts-location-privacy-ps-00
(work in progress), July 2005.
Qiu, et al. Expires August 30, 2006 [Page 16]
Internet-Draft MIP6 location privacy solutions February 2006
Authors' Addresses
Ying Qiu
Institute for Infocomm Research
21 Heng Mui Keng Terrace
Singapore 119613
Phone: +65-6874-6742
Email: qiuying@i2r.a-star.edu.sg
Fan Zhao
University of California Davis
One Shields Avenue
Davis, CA 95616
US
Phone: +1 530 752 3128
Email: fanzhao@ucdavis.edu
Rajeev Koodli
Nokia Research Center
313 Fairchild Drive
Mountain View, CA 94043
US
Email: rajeev.koodl@nokia.com
Qiu, et al. Expires August 30, 2006 [Page 17]
Internet-Draft MIP6 location privacy solutions February 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Qiu, et al. Expires August 30, 2006 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-24 10:42:16 |