idnits 2.17.1 draft-ietf-pana-usage-scenarios-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 2) being 69 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 25, 2002) is 7855 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'PANAREQ' ** Obsolete normative reference: RFC 2284 (Obsoleted by RFC 3748) ** Obsolete normative reference: RFC 2486 (Obsoleted by RFC 4282) ** Downref: Normative reference to an Informational RFC: RFC 2516 ** Downref: Normative reference to an Informational RFC: RFC 3314 ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Yoshihiro Ohba (Editor) 3 Expires: April, 2003 Subir Das 4 Basavaraj Patil 5 Hesham Soliman 6 Alper Yegin 8 October 25, 2002 10 Problem Statement and Usage Scenarios for PANA 12 14 Status of This Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC 2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents, valid for a maximum of six 25 months, and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This document addresses a set of problems which a network layer 38 protocol called PANA (Protocol for carrying Authentication for 39 Network Access) is trying to solve in the area of network access 40 authentication and describes several usage scenarios where PANA is 41 applicable. It also helps to facilitate the discussion for PANA 42 requirements and security threat analysis that are used as basis of 43 actual PANA protocol design. 45 Table of Contents 47 1 Introduction ............................................ 2 48 2. Terminology ............................................. 2 49 3. Problem Statement ....................................... 3 50 4. Usage Scenarios ......................................... 4 51 4.1. PANA with Physical Layer Security ....................... 5 52 4.2. PANA with Link Layer Security ........................... 5 53 4.3. PANA in the Absence of Any Lower Layer Security ......... 6 54 4.4. Mobile IP ............................................... 7 55 4.5. Personal Area Networks .................................. 7 56 4.6. Limited Free Access ..................................... 8 57 4.7. Multiple-Interface Device ............................... 9 58 5. Acronyms ................................................ 9 59 6. Acknowledgments ........................................ 10 60 7. References ............................................. 10 61 8. Authors' Information ................................... 10 63 1 Introduction 65 Network access in most cases requires some form of authentication. 66 Generally authentication is performed at the time of link 67 establishment. Authentication for network access is usually tied to 68 the access technology itself. As a result specific authentication 69 schemes are implemented depending on the type of network being 70 accessed. An example would be the use of 802.1x for authenticating to 71 an 802.11 network and PPP authentication in the case of a dial-up 72 connection to an ISP. Authentication for network access may be 73 performed at a higher layer, either IP or at the application layer. 74 This has the advantage of decoupling the association of 75 authentication from the access technology. The assumption here is of 76 course that link layer connectivity is provided by the access network 77 operator. 79 This I-D discusses various scenarios where a network or higher layer 80 authentication protocol may be deployed. 82 2. Terminology 84 Following terminologies are defined for this document. See also 85 [PANAREQ]. 87 Device 89 A network element (namely notebook computers, PDAs, etc.) that 90 requires access to a provider's network. 92 Device Identifier (DI) 94 The identifier used by the network as a handle to control and 95 police the network access of a PANA client. Depending on the 96 access technology, identifier might contain any of IP address, 97 link-layer address, switch port number, etc. of a device. PANA 98 authentication agent keeps a table for binding device identifiers 99 to the PANA clients. At most one PANA client should be 100 associated with a DI on a PANA authentication agent. 102 Enforcement Point (EP) 104 A node where decisions on per-packet enforcement policy are 105 enforced for devices by using Device Identifier information 106 indicated by a PAA. Per-packet enforcement includes per-packet 107 filtering and may include cryptographic per-packet protection as 108 well. 110 PANA Client (PaC) 112 The entity wishing to obtain network access from a PANA 113 authentication agent within a network. A PANA client is 114 associated with a network device and a set of credentials to 115 prove its identity within the scope of PANA. 117 PANA Authentication Agent (PAA) 119 The entity whose responsibility is to authenticate the 120 credentials provided by a PANA client and grant network access 121 service to the device associated with the client and identified 122 by a DI. 124 Access Point 126 A first-hop L2 attachment point from a PaC device. 128 Access Router 130 A first-hop router from a PaC device. 132 3. Problem Statement 134 Access networks which are not physically secured from unintended 135 usage usually require clients to go through an authentication and 136 authorization process. Network access authentication of clients 137 require a protocol between the client and the network to execute one 138 or more authentication methods (e.g., CHAP, TLS, SIM, etc.). In the 139 light of proliferation of various access technologies (e.g., GPRS, 140 IEEE 802.11, DSL, etc.), it is important that the authentication 141 methods are not tied to the underlying link-layer. Authentication 142 protocol must be able to carry various authentication methods 143 regardless of the underlying access technologies. 145 An important aspect of an authentication protocol is the ability to 146 provide dynamic service provider selection to the clients. Regardless 147 of their network access provider (NAP), clients should be able to 148 select an Internet access provider (ISP) of their choice. This is 149 usually achieved by clients presenting an identifier which carries 150 domain information during the authentication process. For example an 151 NAI[RFC2486]: john@anyisp.com. The authentication agent in the access 152 network would consult the backend authentication servers in the given 153 domain, and the respective ISP service will be used once access is 154 authorized. This is also essential in providing roaming service to 155 clients. Separation of NAP from ISP, and a single NAP providing 156 service for clients from multiple ISPs are made possible by this 157 feature. 159 Support for various authentication methods, including the ones that 160 can provide dynamic service provider selection and roaming can be 161 achieved by using an authentication protocol that can carry EAP 162 [RFC2284]. EAP acts as an encapsulation of arbitrary authentication 163 methods, but it still requires a transport between the client and the 164 access network. Among all the link-layers, only IEEE 802 defines how 165 to carry EAP on the link-layer [802.1X]. Any other link-layer has to 166 resort to using PPP/PPPoE [RFC1661,RFC2516] as a link-layer agnostic 167 way of carrying EAP. Inserting this additional layer(s) between the 168 link-layer and network-layer to achieve this goal is an inadequate 169 method. Using PPP just for client authentication incurs extra round- 170 trips, generates overhead of PPP processing for data packets, and 171 forces the network topology into a point-to-point model. 173 Defining a network-layer transport for EAP would provide a cleaner 174 solution to this problem. Such a solution would not only provide 175 support of various authentication methods, dynamic service provider 176 selection and roaming by carrying EAP, but it will also define a 177 link-layer agnostic carrier for this protocol. This goal will be 178 achieved without having to incur additional costs and limitations of 179 inserting another layer in the stack as in the case of PPP. 181 Meanwhile, in the absence of such a standard solution, some 182 architectures are forced to design their own ad-hoc solutions to the 183 problem. One such solution is the application-layer authentication 184 method implemented by http redirects and web-based login. In addition 185 to being a non-standard solution, this provides an incomplete network 186 access authentication with well-known vulnerabilities, and therefore 187 regarded as a stop-gap solution. 189 Another method designed to provide network access authentication is 190 based on overloading an existing network-layer protocol. Mobile IPv4 191 [RFC3344] protocol has a built-in authentication mechanism. 192 Regardless of whether mobile nodes need to use a foreign agent in an 193 access network, registration via a foreign agent can be required by 194 using an appropriate flag in the agent advertisements. This forces 195 the nodes to register with a foreign agent, and therefore utilizes 196 Mobile IPv4 protocol for network access authentication. Such a 197 solution has very limited applicability as a link-layer agnostic 198 method since it relies on use of Mobile IPv4 protocol. 200 4. Usage Scenarios 202 The first three subsections describe PANA usage scenarios categorized 203 in terms of lower layer security. Other subsections describe 204 scenarios that are not categorized in terms of lower layer security. 206 4.1. PANA with Physical Layer Security 208 In the networks where a certain degree of security is provided at 209 physical layer, authenticating the client is still essential since 210 physical layer does not provide information on the client, but per- 211 packet authentication and encryption may not necessarily be provided 212 at higher layers. DSL networks that are implemented on top of point- 213 to-point phone lines are such an example. In this type of networks, 214 PANA is just used for client authentication and a hook to an 215 appropriate access control. 217 In DSL networks, there are a number of deployment scenarios with 218 regard to client configuration and client authentication. In DSL 219 networks where PPP is used for both configuration and authentication 220 (and IP encapsulation), the providers may not require to migrate to 221 use PANA. On the other hand, there are some DSL networks that use 222 some configuration method other than PPP, i.e., DHCP or static 223 configuration. Those networks use either an ad-hoc network access 224 authentication method such as http-redirect with web-based login or 225 no authentication method at all. A standard, L2 agnostic network 226 access authentication is needed for this type of DSL networks and 227 PANA can be used to fill the demand. 229 4.2. PANA with Link Layer Security 231 In certain networks, link layers may be secured by means outside the 232 scope of an authentication protocol. A higher layer authentication 233 protocol in such cases will provide access authorization. For 234 example, web-based login in current Wi-Fi networks. One can enable 235 WEP security to protect the authentication messages. However, it is 236 also possible that the link layer can be secured following a 237 successful authentication by virtue of key exchange or other means. 239 Wireless data networks such as, CDMA2000 networks require the 240 user/device authentication with the MSC/VLR before providing access 241 to the data network. This authentication which is specific to the 242 technology. Hence the link layer is secured following this 243 authentication. 245 CDMA2000 networks offer two types of data services namely simple IP 246 and Mobile IP. Simple IP requires the user to provide authentication 247 data via PPP. Radius based AAA is used in the backend to verify the 248 credentials provided by the user before allowing network access. 249 Currently CDMA2000 networks include PPP as part of the protocol stack 250 between the MN and the PDSN (Packet Data serving Node - equivalent to 251 the Access Router), and hence are able to rely on PPP functionality 252 to authenticate a user accessing the data network. However it is 253 possible that future releases of the standard may not use PPP but 254 adopt simple framing schemes such as HDLC or variants. In such a 255 scenario network access authentication can be done using a protocol 256 such as PANA. 258 When the MN chooses Mobile IPv4 service, authentication is done by 259 the Foreign agent in the PDSN which interacts with the AAA server. 260 Authentication data as well as the MNs identity, which is the NAI is 261 included in the Mobile IPv4 Registration Request message and the 262 foreign agent then uses the NAI and the data from the MN-AAA auth 263 extension in the Radius request message. Only after a successful 264 response message from the Radius server is the registration request 265 message forwarded to the home agent. This model is combining an IP 266 mobility scheme with network access authentication. A better approach 267 would be to separate network access and Mobile IPv4. PANA would be 268 used to authenticate the user for network access and Mobile IPv4 269 messages would be sent after authentication has completed. Such a 270 model would enable different authentication schemes to be supported 271 since EAP is used rather than relying on just HMAC-MD5 which is the 272 default algorithm for the MN-AAA auth extension. Authentication for 273 network access and authentication/authorization for enabling IP 274 Mobility should be separated. This can be accomplished by using PANA 275 for network access while allowing Mobile IP implementations to adhere 276 to the specification [RFC3344]. 278 The IP mobility solution for IPv6 networks is slightly different from 279 the IPv4 networks. When Mobile IPv6 is deployed in such networks, the 280 FA would no longer exist and hence the current scheme used would no 281 longer work. In such a scenario the MN will have to authenticate 282 using another mechanism and PANA is a possible solution. 284 Since link layer security is enabled as a result of authentication to 285 the MSC/VLR, authentication at an upper layer is an acceptable 286 technique. 288 4.3. PANA in the Absence of Any Lower Layer Security 290 Ethernet links composed of legacy hubs and switches and early 291 deployment of Wi-Fi networks (802.11b) do not use link layer 292 authentication or security mechanisms such as, 802.1X. In absence of 293 such lower layer security not only providers are unable to control 294 the unauthorized use of their networks but also users feel insecure 295 while exchanging sensitive information. In order to support 296 authentication functionality in such legacy systems, many providers 297 today use a higher-layer authentication scheme, such as http-redirect 298 commonly known as web-based login. In this method, once the link is 299 established, users' traffic are re-directed to a web server which in 300 turn generates a web-based login forcing users to provide the 301 authentication information. While this method solves the problem 302 partially by allowing only authorized users to access the network it 303 does not enable the lower layer security such as, per-packet 304 authentication and encryption, etc. Moreover, it is a non-standard ad 305 hoc solution. 307 In such scenarios, a standard network layer solution such as, PANA is 308 suitable since it provides link-layer agnostic network access 309 authentication. In fact, PANA can provide support of various 310 authentication schemes and also capable of enabling lower layer 311 security. For example, a link can be protected by negotiating 312 encryption keys between PaC and PAA after successful authentication. 313 Although PANA does not define key distribution protocol or mechanism, 314 it is possible to use PANA to enable per-packet protection mechanism 315 such as, IPsec and WEP, to secure communication in the edge subnet. 316 This is achievable if authentication carrier protocol that is used by 317 PANA supports key distribution mechanism. Hence, for legacy networks 318 where lower layer authentication and key distribution mechanisms are 319 absent PANA could be very useful. So in a way, PANA can help 320 bootstrapping L2 authentication without a pre-shared secret." 322 4.4. Mobile IP 324 Mobile IPv4 defines its own authentication extensions to authenticate 325 and authorize mobile nodes at the foreign agents and home agents. One 326 of the possible modes of Mobile IPv4 is when the mobile node uses a 327 co-located care-of address and doesn't rely on any mobility 328 management functionality of the foreign agent on the access network. 329 In this case, mobile node can send its registration request directly 330 to the home agent. 332 Even in the co-located care-of address case, the protocol has a way 333 to require mobile nodes to register with a foreign agent by setting 334 Registration-Required bit in the agent advertisements. This forces 335 mobile nodes to send their registration requests via foreign agent, 336 and therefore gives the foreign agent a chance to authenticate and 337 authorize the node for network access. 339 This method can only be used in IPv4 networks where every client 340 implements mobile node functionality. Even for IPv4 clients, a better 341 approach would be to replace this protocol-specific authentication 342 method by a common authentication protocol such as PANA. PANA can be 343 used with any client regardless of Mobile IPv4 support. 345 PANA can also be used with IPv6 clients, or dual-stack clients. 346 Mobile IPv6 protocol doesn't define a foreign agent in the access 347 networks, therefore it cannot provide any protocol support for access 348 authentication. Network access authentication can be handled by PANA 349 regardless of IP version of the clients and independent of whether 350 they support or use Mobile IP. 352 4.5. Personal Area Networks 354 A Personal Area Network would consist of one or more routers 355 connecting one or more hosts to the Internet. Hosts may also 356 communicate directly to each other (e.g. if a shared link is used). 357 Communicating through the mobile router is inefficient and could 358 waste scarce battery power in such device. This should be limited to 359 cases where two hosts do not support the same link layer. It is also 360 important that hosts are authorized to communicate to other hosts in 361 a PAN or gain access to the Internet via the mobile router. Such 362 authentication should be independent of the underlying link layer 363 (e.g. more than one link layer may be used in a PAN), but maybe be 364 used to bootstrap link layer or IP layer authentication for further 365 communication. 367 Current cellular systems lack a single authentication mechanism that 368 can be used to allow hosts in a PAN (behind a mobile router) to gain 369 access to other hosts in a PAN or (simultaneously)to the Internet via 370 the mobile router. 372 The current 3GPP architecture assumes that a split User Equipment 373 (UE) TE and MT [RFC3314] are possible when PPP is run between them 374 for authentication and access control. If more than one device (e.g. 375 laptop, PDA ...etc) needs to be connected to the MT (typically mobile 376 phone), each one would need to setup a PPP connection to the MT. This 377 is a typical case of a Personal Area Network (PAN) trying to connect 378 to the Internet via 3GPP network. However, this configuration is 379 inefficient; if devices behind the MT need to communicate with each 380 other, they can only do so via the MT. Unless some PPP switching is 381 done in the MT, packets between these devices will need to go over 382 the air interface (WCDMA) and get routed through the network and back 383 to the MT. This adds significant cost as a result of bandwidth 384 inefficiency and battery consumption in the MT. All these issues 385 point towards the need to evolve this architecture towards having a 386 multi-access link between the MT and various TEs. Different multi- 387 access link layers can be utilized for this scenario. A link layer 388 agnostic authentication protocol (PANA) is the main enabler for this 389 scenario, as it would allow hosts connected to the MT to authenticate 390 themselves to the MT (The MT implements an IP stack) and gain access 391 to both, the PAN and the Internet via the MT. 393 The use of PANA in this scenario would imply that hosts have a PaC 394 function that allows them to authenticate themselves to gain network 395 access. A router on this subnet (i.e. the MT interfacing to the 3GPP 396 network) would contain a PAA server. In this scenario, there would be 397 no need for authorizing devices through consultation with a backend 398 AAA server; pre-configured secrets would suffice for such a small 399 network. 401 Although IKE (with shared secrets or public keys) can be used for 402 network access authentication in this scenario with some 403 implementation specifics and limitations, it is not designed by 404 nature for network access authentication and would require the use of 405 IPsec tunnel mode for access control, which is not desired in many 406 cases where layer 2 encryption exists. Using a standardized (layer 2 407 independent) protocol specialized for network access (i.e., PANA) 408 will better fit this scenario. 410 4.6. Limited Free Access 412 Certain networks might allow clients to access a limited topology 413 without any explicit authentication and authorization. However, the 414 policy may be such that an access beyond this topology requires 415 authentication and authorization. For example, in an airport network, 416 information such as, flight arrival and departure gate numbers, 417 airport shops and restaurants, etc., are offered as free services by 418 the airlines or airport authorities for their passengers. In order to 419 access such information, users can simply plug in their devices into 420 the network without performing any authentication. On the other hand, 421 access to further services or sites using such local networks 422 requires authentication and authorization. The access network can 423 detect such an attempt and initiate authentication. Once users 424 perform the authentication it will be allowed to go beyond the free 425 access zone. PANA can be an enabler to such limited free access 426 scenarios since PANA authentication is not performed before IP 427 address configuration and it also allows the network to initiate the 428 authentication whenever appropriate. 430 4.7. Multiple-Interface Device 432 A device can have multiple interfaces of homogeneous or heterogeneous 433 technologies. PANA can be used by such a device as a unified higher- 434 layer network access authentication carrier that is independent of 435 the types of the interfaces. There are two possible scenarios for 436 PANA: simultaneous activation and interface switching. 438 In case of simultaneous activation, the multiple interfaces of a 439 device may be activated at the same time for various requirements 440 such as increased bandwidth, load balancing and reliability. 442 In case of interface switching, one of the multiple interfaces of a 443 device is activated at a time and the device may switch from one 444 interface to another. 446 In both cases, each interface may or may not be connected to the same 447 IP subnet. When each interface is connected to a distinct IP subnet, 448 each IP subnet may not be owned by the same service provider, which 449 indicates that the simultaneous activation case is related to host 450 multihoming. 452 5. Acronyms 454 AAA: Authentication, Authorization and Accounting 456 AP: Access Point 458 AR: Access Router 460 DSL: Digital Subscriber Line 462 EAP: Extensible Authentication Protocol 464 GPRS: General Packet Radio Service 466 HDLC: High-level Data Link Control 468 MSC: Mobile Switching Center 470 MN: Mobile Node 472 MT: Mobile Termination 474 NAI: Network Access Identifier 476 PAA: PANA Authentication Agent 478 PaC: PANA Client 480 PPP: Point-to-Point Protocol 482 TE: Terminal Equipment 484 UE: User Equipment 485 VLR: Visiting Location Register 487 6. Acknowledgments 489 The authors would like to thank James Carlson, Jacques Caron, Paal 490 Engelstad, Henry Haverinen, Prakash Jayaraman, James Kempf, Thomas 491 Narten, Erik Nordmark, Reinaldo Penno, Phil Roberts, David Spence, 492 Barani Subbiah, George Tsirtsis, Cliff Wang and the rest of the PANA 493 Working Group for the ideas and support they have given to this 494 document. 496 7. References 498 [802.1X] IEEE Standard for Local and Metropolitan Area Networks, 499 "Port-Based Network Access Control", IEEE Std 802.1X-2001. 501 [PANAREQ] R. Penno, et al., "Protocol for Carrying Authentication for 502 Network Access (PANA) Requirements and Terminology", Internet-Draft, 503 Work in progress. 505 [RFC1661] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661 506 (STD 51), July 1994. 508 [RFC2284] L. Blunk, et al., "PPP Extensible Authentication Protocol 509 (EAP)", RFC 2284, March 1998. 511 [RFC2486] B. Aboba, et al., "The Network Access Identifier", RFC 2486, 512 January 1999. 514 [RFC2516] L. Mamakos, et al., "A Method for Transmitting PPP Over 515 Ethernet (PPPoE)", RFC 2516, February 1999. 517 [RFC3314] M. Wasserman et al., "Recommendations for IPv6 in Third 518 Generation Partnership Project (3GPP) Standards", RFC 3314, September 519 2002. 521 [RFC3344] C. Perkins, "IP Mobility Support for IPv4", RFC 3344, 522 August 2002. 524 8. Authors' Information 526 Yoshihiro Ohba 527 Toshiba America Research, Inc. 528 P.O. Box 136 529 Convent Station, NJ 07961-0136 530 USA 531 Phone: +1 973 829 5174 532 Fax: +1 973 829 5601 533 Email: yohba@tari.toshiba.com 535 Subir Das 536 MCC 1D210R, Telcordia Technologies 537 445 South Street, Morristown, NJ 07960 538 Phone: +1 973 829 4959 539 email: subir@research.telcordia.com 541 Basavaraj Patil 542 Nokia 543 6000 Connection Dr. 544 Irving, TX. 75039 545 USA 546 Phone: +1 972-894-6709 547 Email: Basavaraj.Patil@nokia.com 549 Hesham Soliman 550 Ericsson Radio Systems AB 551 Torshamnsgatan 29, 552 Kista, Stockholm 16480 553 Sweden 554 Phone: +46 8 4046619 555 Fax: +46 8 4047020 556 Email: Hesham.Soliman@era.ericsson.se 558 Alper E. Yegin 559 DoCoMo USA Labs 560 181 Metro Drive, Suite 300 561 San Jose, CA, 95110 562 USA 563 Phone: +1 408 451 4743 564 Email: alper@docomolabs-usa.com