Internet Engineering Task Force Yasuhito Watanabe INTERNET-DRAFT Keio University Document: draft-rihom-architecture-gli-01.txt Toshiharu Kurisu Keio University Sohgo Takeuchi Sony Computer Science Laboratories Fumio Teraoka Keio University Hideki Sunahara NARA Institute of Science and Technology Jun Murai Keio University Jul, 2004 The GLI system architecture Abstract In this document, overview of the Geographical Location Information (GLI) system is described. It manages the latest geographical location information and identifier of mobile nodes on the Internet. Each node registers its geographical location information to this system, and users can look-up identifiers of nodes by specifying location as a key, and vice versa. This system was designed with consideration of privacy protection of mobile nodes and scalability. 1 Introduction We proposed the GLI system. The Geographical Location Information (GLI) is the system on the Internet, manages the latest geographical location information of mobile nodes. The GLI system is based on the idea that the worldwide location system which can manage numerous number of mobile node existing on all over the world and protect the privacy of each mobile node. In order to enable system scalability to manage numerous number of mobile node's location information, the GLI system takes distributed management manner and manages all over the world. The GLI system also realize to protect the privacy of mobile node systematically by using unique identifier called HID as a mobile node's ID. The identifier can't be generated by the third person for the mobile node with the identifier. The GLI system provides two types of lookup function. The first is called Forward-Lookup function that is the search which uses the identifier of the node as the key, and gives the geographical location information of the specified mobile node. And the second is called Reverse-Lookup function that is the search which uses the area as the key, and gives the geographical location information of the mobile nodes within the specified area as a result of lookup. Yasuhito Watanabe Toshiharu Kurisu Sohgo Takeuchi, et al. [Page 1] The GLI system architecture Jul 2004 2 Overview 2.1 Requirements It is necessary for the GLI system to enable to manage many mobile nodes over the world. There are four requirements for designing this system. a. Service model for the location information and its definition There are many mobile nodes connected to the Internet with geographical location information. In such case, it is expected that enable us to do the following examples of search. ex. - To acquire the geographical location information of the specified mobile node - To search mobile nodes that exist in the specified geographical location information - To search the nearest service or resource from the specified geographical location information - Multicast communication based on geographical location information In each example, it is necessary to use both identifiers and geographical location information of mobile nodes as a key of search. Service model of the geographical location information should be defined considering above two types of search. b. To register identifier and location of mobile nodes correctly and reliably To make geographical location information service practically usable, it is necessary that such registered information of mobile nodes can be correct and reliable. The followings are requirements for managing information of mobile nodes. - one mobile node can register its information to the service itself. - registered information must not exposure to the unreliable third person. - information of mobile nodes should be updated to the latest one. c. Secure exchanging the location information Identifier and geographical location information of mobile nodes are private information. So it is necessary to take care of treating such information through the internet and accessing it. For example, - information of one mobile node may be known to its reliable person - information of one mobile node must not be known and be tracked by unknown person. d. Many mobile nodes can also register and be managed Many mobile nodes exists ubiquitously over the world. Especially most of mobile nodes are vehicles. There are many types of vehicle, for example car, truck, bus, train, airplane and etc. The number of car is at least 1 billion. So, system should be designed to manage such mobile nodes in an earth scale. Yasuhito Watanabe Toshiharu Kurisu Sohgo Takeuchi, et al. [Page 2] The GLI system architecture Jul 2004 2.2 GLI system concept 2.2.1 GLI system functionality The GLI system has a function to manage identifier and coordinates as geographical location information of mobile nodes on the Internet, also has API to look-up nodes and interfaces for positioning device such as GPS (Figure 1). Every mobile nodes has various types of positioning device. If it trys to register its location to the GLI system, it needs to exchange the location information to coordinates. Likewise, as most of applications use name of place, if they use the GLI system, they need to exchange the location information to coordinates. +-----------------------------------------------------------+ | | application software | | application layer +--------------------------------------+ | | various middle ware | | | for map matching, identify road | | | convert address, name of place, | | | and etc. | +--------------------+--------------------------------------+ | | API for looking up mobile nodes | | GLI system +--------------------------------------+ | | system core (register, look-up) | | +--------------------------------------+ | | interface for positioning devices | +--------------------+--------------------------------------+ | positioning devices| GPS, PHS, RF-ID, and etc. | +-----------------------------------------------------------+ Figure 1: The position of GLI system 2.2.2 Mobile node and managed information on the GLI system A mobile node moves in physical space, and the geographical location information changes dynamically. The GLI system manages identifier and geographical location information of such mobile nodes. Geographical location information consists of latitude, longitude, and an altitude. Identifier is used for identifying mobile node. It is globally unique. As the representative form of identifier, Hashed ID(HID) and FQDN are used. HID is considered possibility of being specified. FQDN can be used for public use. Detail about HID is described later section. 2.2.3 Model for managing geographical location information of mobile nodes The GLI system consists of the model for managing geographical location information of mobile nodes. The model consists mobile nodes, servers, look-up clients. Each mobile node registers its identifier and geographical location information to servers. Look-up clients send lookup requests to servers, and receive answer from servers as shown the following figure. Yasuhito Watanabe Toshiharu Kurisu Sohgo Takeuchi, et al. [Page 3] The GLI system architecture Jul 2004 +--------------+ +----------+ request +-----------+ | mobile nodes |-----------> | servers | <----------- | look-up | | | register | | -----------> | clients | +--------------+ +----------+ reply +-----------+ Figure 2: The basic structure 2.2.4 Look-up The GLI system supports two types of looking-up. One is Forward look-up. It is a way of looking-up geographical location information using key as identifier of a mobile node. Another is Reverse lookup. It is a way of looking-up identifiers using key as geographical location information. The reverse look-up has two types of look-up as shown the following figure. One is Range search that looks up mobile nodes in squared area consisting of two points. They are A and B shown in Figure 3. The GLI system that received a request of Range search replys the list consists of identifier and location information of 4 points shown in Figure 3. Another is Nearest search that looks up nearest mobile nodes from a specified point. It is A shown in Figure 4. The GLI system that received a request of Nearest search replys the list consists of identifier and location information of 3 points shown in Figure 4. Lat. ^ | A(x,y) | +--------------------------+ | | o | | | o | | | o o | | +--------------------------+B(i,j) | -+----------------------------------------------> Long. | Figure 3: range search Lat. ^ | o | \ | d3 \ o | \ / d1 | * | / A(x,y) | o -/ d2 | -+----------------------------------------------> Long. | dn means distance from point A. d1 < d2 < d3 Figure 4: nearest search Yasuhito Watanabe Toshiharu Kurisu Sohgo Takeuchi, et al. [Page 4] The GLI system architecture Jul 2004 2.3 Security Consideration 2.3.1 Threat around mobile nodes and GLI system GLI system is supposed to work on the Internet. There are some threats around mobile nodes and GLI system. In this section, threats around GLI system and assumption are described. [Assumption] Servers in the GLI system have a confidential relation. One look-up client can look-up mobile nodes with confidential relation with itself, another look-up client can not look-up mobile nodes without confidential relation with itself. [Threats] In a servers, data may be stolen and rewritten by the third person. In the Internet, data may be falsificated by wiretapping by the third person. Some Mobile nodes may be spoofed, tracked by the third person. 2.3.2 Requirements and solution for security Authentication of each mobile node can prevent of spoofing. Encrypting communication path can prevent of wiretapping and falsification of data. That location of mobile nodes may be specified by the third person is out of scope. For the threat of specifying a mobile node by unknown person and tracking a mobile node by unknown person, it is necessary to conceal identifiers of mobile nodes from unknown third person. 2.3.3 Privacy protection and Identifier of mobile nodes Requirements to protect privacy are to allow to specify mobile nodes from persons with a confidential relation and to prevent of specifying by the unknown third person without a confidential relation, and to prevent of tracking. Geographical location information tells real location on the earth. However, this system does not hide the geographical location of each mobile node. To look-up mobile nodes using a key as specified identifier, two types of identifier are introduced. One is FQDN, every look-up client can use and specify mobile nodes. Another is Hashed ID(HID), only look-up client with a confidential relation to it needs to understand the identifier, the third person can not understand. 2.3.4 HID (Hashed ID) For such requirements, HID (Hashed ID) is designed for the GLI system. To use HID, both a mobile nodes and look-up clients in a confidential relation have secret identifier for mobile nodes and time information to generate HID. The time information is changed with time. So, to input two valuables to a hash function can generates HID. HID is also changed with time, and can prevent tracking. The formula which generates HID is shown below. Yasuhito Watanabe Toshiharu Kurisu Sohgo Takeuchi, et al. [Page 5] The GLI system architecture Jul 2004 HID = hash ( ID, ts + ttl * n) ID: secret identifier ts: base time stamp ttl: the interval of base time stamp to be changed n: n is zero or more integers. In current implementation of the GLI system, HMAC-SHA1 is used for generating HID, HID has 160 bit length. Example. ID: icar1@sfc ts: 969160000 ttl: 300 random1: 345 random2:678 random3: 789 Registered and looked up HID, and Location Information 7ccb6ee0d0f0594620788b33b507ca8ada82efb1 N 35 22 59.279 E 139 25 30.344 0 11ad8c0517036061094c0df0e98e29a42d7c8dbd N 35 22 53.584 E 139 25 38.543 0 704896163fa238d0abd000dcd506a6f58cd614db N 35 22 55.201 E 139 25 39.552 0 8d04794e396c56fe529929f1dd844952a38bda04 N 35 23 2.646 E 139 25 35.992 0 3 Architecture The GLI system consists of Registration Client, Registration Server, HOME Server, HID Server, AREA Server, Lookup Client, and Lookup Server. In order to provide a highly scalable system, the HID Server and the AREA Server are distributed based on a hierarchical server structure. 3.1 Registration Client Registration Client sends Registration Message to the Registration Server with confidential relation. Registration Message contains the ID of the client and location information . The ID may be expressed in two ways: by using FQDN(Fully Qualified Domain Name) or by using HID(Hashed ID). If the Registration Client prefers to disclose the real identifier(the information that can specify the individual, such as name, telephone number, etc), the client may use the HID as the ID in the GLI system. The client changes the HID at fixed intervals to prevent the possibility of any trace by the third person. 3.2 Regsitration Server Registration Server receives Registration Message from the clients and forwards the received message to a HOME(HID) Server or to a Area Server. If the Registration Client uses the FQDN as its identifier, Registration Server forwards the message to a HOME Server. Likewise, if the client uses the HID as its identifier, Registration Server forwards the message to a HID Server. In the GLI system, multiple Registration Servers may exist. Each Registration Server transacts the message from Registration Clients with conficential relation . In order to decline a burden of HID(HOME) Server and AREA Server, Registration Server caches delegation information of distributed HID(HOME) Servers and AREA Servers. Following figure shows the Registration Message flow between the Registration Client, the Registra-tion Server, the HID(HOME) Server and the AREA Server. Yasuhito Watanabe Toshiharu Kurisu Sohgo Takeuchi, et al. [Page 6] The GLI system architecture Jul 2004 +--------------+ +--------------+ +---------------+ | Registration |------->| Registration |-----+------>|HID(HOME)server| | Client | | Server | | +---------------+ +--------------+ +--------------+ | | +-------------+ +------>| AREA Server | +-------------+ Figure 6: Regitration Message Flow 3.3 HOME Server HOME Server maintains the FQDN of each registered client along with the latest geographical location information, and processes Forward-Lookup requests. The hierarchy of the HOME Servers is constructed as in DNS, where servers manage domains represented in the name specified in the FQDN. For example, the client with ID of chris.wide.ad.jp is registered at the HOME Server of wide.ad.jp. 3.4 HID Server HID Server maintains the HID of each registered client along with latest geographical location information, and processes Forward-Lookup requests. The hierarchy of the HID Servers is a tree structure where ROOT HID Server masks the first 4bits of the HID(160bit) and obtains the MASK NUMBER(0-f). The server delegates the MASK NUMBER to the lower HID Servers, and the delegated HID Servers mask the next 4bits of the HID and delegate like upper layer server. Then the HID Server can be up to 40 layers hierarchal structure. Following figure7 shows an example of the delegation. ROOT HID Server refers the first 4 bits of HID as MASK NUMBER. The ROOT HID Server delegates MASK NUMBER(0-3) to Server A, MASK NUMBER(4-7) to Server B, and manages MASK NUMBER(8-f) by itself. In 1st Layer, HID Server refers the next 4bits of HID as MASK NUMBER. Server A delegates MASK NUMBER(0-5) to Server C, and manages MASK NUMBER(6-f) by itself. In 2nd Layer, Server C does not delegate. In this environment, location information of mobile nodes are maitained at the following servers; (1) "a0df.........d2(160bits)", is maintained at ROOT HID Server. (2) "40df.........a5(160bits)", is maintained at Server B. (3) "17df.........1d(160bits)", is maintained at Server A. (4) "24ac.........8f(160bits)", is maintained at Server C. Yasuhito Watanabe Toshiharu Kurisu Sohgo Takeuchi, et al. [Page 7] The GLI system architecture Jul 2004 ROOT Layer +-------------------+ | ROOT HID SERVER | +-------------------+ | | | | | | - - - - - - - - - - - - - - - - - - - - 1st Layer | | | | V V +----------+ +----------+ | 0,1,2,3 | | 4,5,6,7 | | Server A | | Server B | +----------+ +----------+ | | | - - - - - - - - - - - - - - - - - - - - 2nd Layer | | | V +-------------+ | 0,1,2,3,4,5 | | Server C | +-------------+ Figure 7: The example of HID Server's delegation 3.5 AREA Server AREA Server maintains the latest geographical location information of Registration Clients that are within the service area, and processes Reverse-Lookup requests. The hierarchy of the AREA Servers is constucted from four layers which are ROOT layer, DEGREE layer, MINUTE layer, and SECOND layer, expressed in Longitude and Latitude. The ROOT layer has one AREA Server (ROOT AREA Server) which serves the entire world. The ROOT AREA Server can delegate the rectangle area specified by minimum and maximum degree value of longitude and latitude to DEGREE layer server. The DEGREE layer MAY have several AREA Servers managing different areas. The servers in the DEGREE layer can also delegate the rectangle area specified by minimum and maximum minute value of longitude and latitude to the MIMUTE layer server. Likewise, the MINUTE layer, the servers can also delegate the rectangle area specified by minimum and maximum second value of longitude and latitude to the SECOND layer server. Figure8 below shows the overview of the AREA Server's delegation. The ROOT Server manages the entire world, and delegates area "A" to server A, and area "B" to server B. Server A and Server B belongs to the DEGREE Layer. Server A delegates area "C" within area "A" to Server C. Server B does not delegate. Server C belongs to the MINUTE Layer and also delegates area "D" within area "C" to Server D. Server D belongs to the SECOND Layer, but can not delegate any more. Yasuhito Watanabe Toshiharu Kurisu Sohgo Takeuchi, et al. [Page 8] The GLI system architecture Jul 2004 ROOT -- * manages the entire the world. | * delegates "A" to AREA Server A in DEGREE layer | * delegates "B" to AREA Server B in DEGREE layer <------------+-----------------> _ _ _ _ _ _ _ _ _ _ _ _ _ _ /_/_/_/_/_/_/_/_/_/_/_/_/_/_/ /_/_/B/B/_/_/_/_/_/_/_/_/_/_/ /_/_/B/B/_/_/_/_/A/A/A/A/_/_/ /_/_/_/_/_/_/_/_/A/A/A/A/_/_/ DEGREE --- Server A manages "A" /_/_/_/_/_/_/_/_/A/A/A/A/_/_/ Server B manages "B" /_/_/_/_/_/_/_/_/A/A/A/A/_/_/ | | delegate: Server A delegates "C" in area of "A" | to Server C. | V _ _ _ _ /_/_/_/_/ /_/C/C/_/ /_/C/C/_/ MINUTE --- Server C manages "C" /_/C/C/_/ | | delegate : Server C delegates "D" in area "C" | to Server D V _ _ /_/_/ /D/D/ SECOND --- Server D manages "D" /D/D/ Figure 8: The overview of AREA Server's delegation Figure9 below shows the example of AREA Server's delegation. Root AREA Server delegates "LATITUDE: North 30-38 degree, LONGITUDE: East 130-135 degree" to Server X. Server X delegates "LATITUDE: North 35 degree 10-50 minute, LONGITUDE: East 132 degree 15-55 minute" to Server Y. Server Y delegates "LATITUDE:North 35 degree 40 minute 25-35 second, LONGITUDE: East 132 degree 30 minute 20-45 second" to Server Z. Yasuhito Watanabe Toshiharu Kurisu Sohgo Takeuchi, et al. [Page 9] The GLI system architecture Jul 2004 | ROOT AREA SERVER | +------------------+ | | Delegates LAT N30-38 LON E130-135 | to Server X | | V ________________________________ / / / _ _ _ _ _ / N38 / ##### / / ##### / Server X / ##### _ _ _ _ _/ N30 / ##### / /________________/___/__________/ E130 E135 | | | Delegates LAT N35.10-50' LON E132.15-55' | to Server Y V ______ / __/ N35.50' / ### / Server Y / ###_/ N35.10' /_/_/_/ E132.15' E132.55' | | Delegates LAT N35.40'25-35" LON E132.30'.20-45" | to Server Z V _____ / __/ N35.40'.35" / ##_/ Server Z /_//_/ N35.40'.25" E132.30'.20" E132.30'.45" Figure 9: The example of AREA Server's delegation Yasuhito Watanabe Toshiharu Kurisu Sohgo Takeuchi, et al. [Page 10] The GLI system architecture Jul 2004 3.6 Lookup Client 3.6.1 Forward-Lookup Forward-Lookup is a search mechanism for location information of the mobile node specified by the Forward-Lookup Client. Forward-Lookup Client sends Forward-Lookup request message to Lookup Server. Forward-Lookup request message contains the identifier of a mobile node of which the client specifies. Lookup Server forwards the request message to HID(HOME) server and receives the result. Forward-Lookup Client receives the lookup result from the Lookup Server. Following figure 10 shows the Forward-Lookup message flow between the Forward-Lookup Client, Lookup Server, and HID(HOME) Server. +----------------+ request +------------+ request +---------------+ | Forward-Lookup |--------->| Lookup |------------>| HID(HOME) | | Client |<---------| Server |<------------| Server | +----------------+ reply +------------+ reply +---------------+ Figure 10: The Forward-Lookup message flow 3.6.2 Reverse-Lookup Reverse-Lookup is a search mechanism for entities within the area specified by the Reverse-Lookup Client. Reverse-Lookup Clients send Reverse-Lookup request message to a Lookup Server. In the case of range search, Reverse-Lookup request message contains the minimum and maximum value of longitude and latitude of the area. Lookup Server forwards the request message to AREA server and receives the result. The client receives the list of the identifier and location information of the mobile nodes that are in the specified area. Following figure 11 shows the Reverse-Lookup message flow between the Reverse-Lookup Client, Lookup Server, and AREA Server. +----------------+ request +------------+ request +---------------+ | Reverse-Lookup |--------->| Lookup |------------>| AREA | | Client |<---------| Server |<------------| Server | +----------------+ reply +------------+ reply +---------------+ Figure 11: The Reverse-Lookup message flow 3.7 Lookup Server 3.7.1 Forward-Lookup When Lookup Server receives Forward-Lookup request message from Lookup Client, it forwards the received message to HOME(HID) Server. Same as Registration Server, if the identifier contained in the received message is FQDN, the message MUST BE sent to the HOME Server. Otherwise, the message MUST BE sent to the HID Server. When Lookup Server receive the lookup result message from the HID(HOME) Server, it forwards the message to lookup client. Yasuhito Watanabe Toshiharu Kurisu Sohgo Takeuchi, et al. [Page 11] The GLI system architecture Jul 2004 3.7.2 Reverse-Lookup When Lookup Server receives Reverse-Lookup request message from Lookup Client, it forwards the received message to AREA Server. When Lookup Sever receives the lookup result message from the AREA Server(s) (If the area specified in the request message covers two or more domains which are covered by different AREA Servers, the result message are received from multiple AREA Servers.), it forwards the result message to lookup client. In order to decline a burden of HID(HOME) Server and AREA Server, Lookup Server caches delegation information of distributed HID(HOME) Server and AREA Server. 4 TODO We have already implemented the GLI system. Now we have been actual proof experimenting using some real cars and virtual cars generated by ITS simulater. Our recent TODO 1. Evaluate the GLI system based on actual proof experiment. 2. Publish internet-draft about the GLI system specification. 3. Examine whether we apply RuleMaker and RuleHolder defined in RFC3693 to the GLI system in order to realize flexible privacy protect. 5 Authors' Addresses Yasuhito Watanabe Graduate School of Media and Governance, Shonan Fujisawa Campus, Keio University 5322 Endo, Fujisawa, Japan 252-8520 E-mail: riho-m@sfc.wide.ad.jp Toshiharu Kurisu Keio University, 3-14-1 Hiyoshi, Kohoku-ku, Yokohama, Japan 223-0061 E-mail: chris@tera.ics.keio.ac.jp Sohgo Takeuchi Sony Computer Science Laboratories, Takanawa Muse bldg. 3-14-13 Higashigotanda, Shinagawa-ku, Tokyo, Japan 141-0022 E-mail: sohgo@csl.sony.co.jp Hideki Sunahara Information Technology Center, NARA Institute of Science and Technology, 8916-5 Takayamacho, Ikoma, Nara, Japan 630-0193 E-mail: suna@wide.ad.jp Fumio Teraoka Department of Information and Computer Science, Keio University 3-14-1 Hiyoshi, Kohoku-ku, Yokohama, Japan 223-0061 Email: tera@tera.ics.keio.ac.jp Yasuhito Watanabe Toshiharu Kurisu Sohgo Takeuchi, et al. [Page 12] The GLI system architecture Jul 2004 Jun Murai Faculty of Environmental Information, Keio University, Shonan Fujisawa Campus, Keio University 5322 Endo, Fujisawa, Japan 252-8520 E-mail: jun@wide.ad.jp Yasuhito Watanabe Toshiharu Kurisu Sohgo Takeuchi, et al. [Page 13]