idnits 2.17.1 draft-ietf-dhc-dhcp-privacy-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 119 has weird spacing: '...ntifier any p...' -- The document date (February 9, 2015) is 3335 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dhc S. Jiang 3 Internet-Draft Huawei Technologies Co., Ltd 4 Intended status: Informational S. Krishnan 5 Expires: August 13, 2015 Ericsson 6 T. Mrugalski 7 ISC 8 February 9, 2015 10 Privacy considerations for DHCP 11 draft-ietf-dhc-dhcp-privacy-00 13 Abstract 15 DHCP is a protocol that is used to provide addressing and 16 configuration information to IPv4 hosts. This document discusses the 17 various identifiers used by DHCP and the potential privacy issues. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 13, 2015. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Requirements Language and Terminology . . . . . . . . . . . . 3 55 3. Identifiers in DHCP . . . . . . . . . . . . . . . . . . . . . 3 56 3.1. Client ID Option . . . . . . . . . . . . . . . . . . . . 3 57 3.2. Address Fields & Options . . . . . . . . . . . . . . . . 4 58 3.3. Subscriber-ID Option . . . . . . . . . . . . . . . . . . 4 59 3.4. Relay Agent Information Option and Sub-options . . . . . 4 60 3.5. Client FQDN Option . . . . . . . . . . . . . . . . . . . 5 61 3.6. Parameter Request List Option . . . . . . . . . . . . . . 5 62 3.7. Vendor Class and Vendor-Identifying Vendor Class Options 5 63 3.8. Civic Location Option . . . . . . . . . . . . . . . . . . 6 64 3.9. Coordinate-Based Location Option . . . . . . . . . . . . 6 65 3.10. Client System Architecture Type Option . . . . . . . . . 6 66 4. Existing Mechanisms That Affect Privacy . . . . . . . . . . . 6 67 4.1. DNS Updates . . . . . . . . . . . . . . . . . . . . . . . 6 68 4.2. Allocation strategies . . . . . . . . . . . . . . . . . . 7 69 5. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 5.1. Device type discovery . . . . . . . . . . . . . . . . . . 8 71 5.2. Operating system discovery . . . . . . . . . . . . . . . 8 72 5.3. Finding location information . . . . . . . . . . . . . . 8 73 5.4. Finding previously visited networks . . . . . . . . . . . 9 74 5.5. Finding a stable identity . . . . . . . . . . . . . . . . 9 75 5.6. Pervasive monitoring . . . . . . . . . . . . . . . . . . 9 76 5.7. Finding client's IP address or hostname . . . . . . . . . 9 77 5.8. Correlation of activities over time . . . . . . . . . . . 9 78 5.9. Location tracking . . . . . . . . . . . . . . . . . . . . 9 79 5.10. Leasequery & bulk leasequery . . . . . . . . . . . . . . 10 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 81 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 83 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 86 10.2. Informative References . . . . . . . . . . . . . . . . . 12 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 89 1. Introduction 91 Dynamic Host Configuration Protocol (DHCP) [RFC2131] is a protocol 92 that is used to provide addressing and configuration information to 93 IPv4 hosts. The DHCP protocol uses several identifiers that could 94 become a source for gleaning additional information about the IPv4 95 host. This information may include device type, operating system 96 information, location(s) that the device may have previously visited, 97 etc. This document discusses the various identifiers used by DHCP 98 and the potential privacy issues [RFC6973]. 100 Future works may propose protocol changes to fix the privacy issues 101 that have been analyzed in this document. It is out of scope for 102 this document. 104 Editor notes: for now, the document is mainly considering the privacy 105 of DHCP client. The privacy of DHCP server and relay agent are 106 considered less important because they are open for public services. 107 However, this may be a subject to change if further study shows 108 opposite result. 110 2. Requirements Language and Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. When these 115 words are not in ALL CAPS (such as "should" or "Should"), they have 116 their usual English meanings, and are not to be interpreted as 117 [RFC2119] key words. 119 Stable identifier any property disclosed by a DHCP client that does 120 not change over time or changes very infrequently and is unique 121 for said client in a given context. Examples include MAC address, 122 client-id that does not change or a hostname. Stable identifier 123 may or may not be globally unique. 125 3. Identifiers in DHCP 127 There are several identifiers used in DHCP. This section provides an 128 introduction to the various options that will be used further in the 129 document. 131 3.1. Client ID Option 133 The Client Identifier Option [RFC2131] is used to pass an explicit 134 client identifier to a DHCP server. There is an analogous Server 135 Identifier Option but it is not as interesting in the privacy context 136 (unless a host can be convinced to start acting as a server). 138 The client identifier is an opaque key, which must be unique to that 139 client within the subnet to which the client is attached. It 140 typically remains stable after it has been initially generated. It 141 may contain a hardware address, identical to the contents of the 142 'chaddr' field, or another type of identifier, such as a DNS name. 143 It is recommended that client identifiers be generated by using the 144 permanent link-layer address of the network interface that the client 145 is trying to configure. [RFC4361] updates the recommendation of 146 Client Identifiers to be "consists of a type field whose value is 147 normally 255, followed by a four-byte IA_ID field, followed by the 148 DUID for the client as defined in RFC 3315, section 9". This does 149 not change the lifecycle of the Client Identifiers. Clients are 150 expected to generate their Client Identifiers once (during first 151 operation) and store it in a non-volatile storage or use the same 152 deterministic algorithm to generate the same Client Identifier values 153 again. 155 3.2. Address Fields & Options 157 The 'yiaddr' field [RFC2131] in DHCP message is used to allocate 158 address from the server to the client. 160 The DHCPv4 specification [RFC2131] provides a way to specify the 161 client link-layer address in the DHCPv4 message header. A DHCPv4 162 message header has 'htype' and 'chaddr' fields to specify the client 163 link-layer address type and the link-layer address, respectively. 164 The 'chaddr' field is used both as a hardware address for 165 transmission of reply messages and as a client identifier. 167 The 'requested IP address' option [RFC2131] is used by client to 168 suggest that a particular IP address be assigned. 170 3.3. Subscriber-ID Option 172 A DHCP relay includes a Subscriber-ID option [RFC3993] to associate 173 some provider-specific information with clients' DHCP messages that 174 is independent of the physical network configuration through which 175 the subscriber is connected. 177 The "subscriber-id" assigned by the provider is intended to be stable 178 as customers connect through different paths, and as network changes 179 occur. The Subscriber-ID is an ASCII string, which is assigned and 180 configured by the network provider. 182 3.4. Relay Agent Information Option and Sub-options 184 A DHCP relay agent includes a Relay Agent Information [RFC3046] to 185 identify the remote host end of the circuit. It contains a "circuit 186 ID" sub-option for the incoming circuit, which is an agent-local 187 identifier of the circuit from which a DHCP client-to-server packet 188 was received, and a "remote ID" sub-option which provides a trusted 189 identifier for the remote high-speed modem. 191 Possible encoding of "circuit ID" sub-option includes: router 192 interface number, switching hub port number, remote access server 193 port number, frame relay DLCI, ATM virtual circuit number, cable data 194 virtual circuit number, etc. 196 Possible encoding of the "remote ID" sub-option includes: a "caller 197 ID" telephone number for dial-up connection, a "user name" prompted 198 for by a remote access server, a remote caller ATM address, a "modem 199 ID" of a cable data modem, the remote IP address of a point-to-point 200 link, a remote X.25 address for X.25 connections, etc. 202 The link-selection sub-option [RFC3527] is used by any DHCP relay 203 agent that desires to specify a subnet/link for a DHCP client request 204 that it is relaying but needs the subnet/link specification to be 205 different from the IP address the DHCP server should use when 206 communicating with the relay agent. It contains an IP address, which 207 can identify the client's subnet/link. 209 3.5. Client FQDN Option 211 The Client Fully Qualified Domain Name (FQDN) option [RFC4702] is 212 used by DHCP clients and servers to exchange information about the 213 client's fully qualified domain name and about who has the 214 responsibility for updating the DNS with the associated AAAA and PTR 215 RRs. 217 A client can use this option to convey all or part of its domain name 218 to a DHCP server for the IP-address-to-FQDN mapping. In most case a 219 client sends its hostname as a hint for the server. The DHCP server 220 MAY be configured to modify the supplied name or to substitute a 221 different name. The server should send its notion of the complete 222 FQDN for the client in the Domain Name field. 224 3.6. Parameter Request List Option 226 The Parameter Request List option [RFC2131] is used to inform the 227 server about options the client wants the server to send to the 228 client. The content of a Parameter Request List option are the 229 option codes for an option requested by the client. 231 3.7. Vendor Class and Vendor-Identifying Vendor Class Options 233 The Vendor Class option [RFC2131] and the Vendor-Identifying Vendor 234 Class option [RFC3925] is used by a DHCP client to identify the 235 vendor that manufactured the hardware on which the client is running. 237 The information contained in the data area of this option is 238 contained in one or more opaque fields that identify the details of 239 the hardware configuration of the host on which the client is 240 running, or of industry consortium compliance, for example, the 241 version of the operating system the client is running or the amount 242 of memory installed on the client. 244 3.8. Civic Location Option 246 DHCP servers use the Civic Location Option [RFC4776] to delivery of 247 the location information (the civic and postal addresses) to the DHCP 248 clients. It may refer to three locations: the location of the DHCP 249 server, the location of the network element believed to be closest to 250 the client, or the location of the client, identified by the "what" 251 element within the option. 253 3.9. Coordinate-Based Location Option 255 The GeoConf and GeoLoc options [RFC6225] is used by DHCP server to 256 provide the coordinate-based geographic location information to the 257 DHCP clients. It enables a DHCP client to obtain its geographic 258 location. 260 After the relevant DHCP exchanges have taken place, the location 261 information is stored on the end device rather than somewhere else, 262 where retrieving it might be difficult in practice. 264 3.10. Client System Architecture Type Option 266 The Client System Architecture Type Option [RFC4578] is used by DHCP 267 client to send a list of supported architecture types to the DHCP 268 server. It is used to provide configuration information for a node 269 that must be booted using the network rather than from local storage. 271 4. Existing Mechanisms That Affect Privacy 273 This section describes available DHCP mechanisms that one can use to 274 protect or enhance one's privacy. 276 4.1. DNS Updates 278 DNS Updates [RFC4704] defines a mechanism that allows both clients 279 and server to insert into DNS domain information about clients. Both 280 forward (AAAA) and reverse (PTR) resource records can be updated. 281 This allows other nodes to conveniently refer to a host, despite the 282 fact that its IP address may be changing. 284 This mechanism exposes two important pieces of information: current 285 address (which can be mapped to current location) and client's 286 hostname. The stable hostname can then by used to correlate the 287 client across different network attachments even when its IP 288 addresses keep changing. 290 4.2. Allocation strategies 292 A DHCP server running in typical, stateful mode is given a task of 293 managing one or more pools of IP address resources. When a client 294 requests a resource, server must pick a resource out of configured 295 pool. Depending on the server's implementation, various allocation 296 strategies are possible. Choices in this regard may have privacy 297 implications. 299 Iterative allocation - a server may choose to allocate addresses one 300 by one. That strategy has the benefit of being very fast, thus can 301 be favored in deployments that prefer performance. However, it makes 302 the resources very predictable. Also, since the resources allocated 303 tend to be clustered at the beginning of available pool, it makes 304 scanning attacks much easier. 306 Identifier-based allocation - a server may choose to allocate an 307 address that is based on one of available identifiers, e.g. client 308 identifier or MAC address. It is also convenient, as returning 309 client is very likely to get the same address. Those properties are 310 convenient for system administrators, so DHCP server implementors are 311 often requested to implement it. On the other hand, the downside of 312 such allocation is that the client has a very stable IP address. 313 That means that correlation of activities over time, location 314 tracking, address scanning and OS/vendor discovery apply. 316 Hash allocation - it's an extension of identifier based allocation. 317 Instead of using the identifier directly, it is being hashed first. 318 If the hash is implemented correctly, it removes the flaw of 319 disclosing the identifier, a property that eliminates susceptibility 320 to address scanning and OS/vendor discovery. If the hash is poorly 321 implemented (e.g. can be reverted), it introduces no improvement over 322 identifier-based allocation. 324 Random allocation - a server can pick a resource randomly out of 325 available pool. That strategy works well in scenarios where pool 326 utilization is small, as the likelihood of collision (resulting in 327 the server needing to repeat randomization) is small. With the pool 328 allocation increasing, the collision is disproportionally large, due 329 to birthday paradox. With high pool utilization (e.g. when 90% of 330 available resources being allocated already), the server will use 331 most computational resources to repeatedly pick a random resource, 332 which will degrade its performance. This allocation scheme 333 essentially prevents returning clients from getting the same address 334 again. On the other hand, it is beneficial from privacy perspective 335 as addresses generated that way are not susceptible to correlation 336 attacks, OS/vendor discovery attacks or identity discovery attacks. 337 Note that even though the address itself may be resilient to a given 338 attack, the client may still be susceptible if additional information 339 is disclosed other way, e.g. client's address can be randomized, but 340 it still can leak its MAC address in client-id option. 342 Other allocation strategies may be implemented. 344 However, giving the limited resource of IPv4 public address pool, 345 allocation mechanism in IPv4 may not provide much protection, while 346 in IPv6, the network has very large address space to distribute the 347 address allocation. 349 5. Attacks 351 5.1. Device type discovery 353 The type of device used by the client can be guessed by the attacker 354 using the Vendor Class Option, the 'chaddr' field, and by parsing the 355 Client ID Option. All of those options may contain Organizationally 356 Unique Identifier (OUI) that represents the device's vendor. That 357 knowledge can be used for device-specific vulnerability exploitation 358 attacks. 360 5.2. Operating system discovery 362 The operating system running on a client can be guessed using the 363 Vendor Class option, the Client System Architecture Type option, or 364 by using fingerprinting techniques on the combination of options 365 requested using the Parameter Request List option. 367 5.3. Finding location information 369 The location information can be obtained by the attacker by many 370 means. The most direct way to obtain this information is by looking 371 into a server initiated message that contains the Civic Location, 372 GeoConf, or GeoLoc options. It can also be indirectly inferred using 373 the Relay Agent Information option, with the remote ID sub-option 374 (e.g. using a telephone number), the circuit ID option (e.g. if an 375 access circuit on an Access Node corresponds to a civic location), or 376 the Subscriber ID Option (if the attacker has access to subscriber 377 info). 379 5.4. Finding previously visited networks 381 When DHCP clients connect to a network, they attempt to obtain the 382 same address they had used before they attached to the network. They 383 do this by putting the previously assigned address in the requested 384 IP address option. By observing these addresses, an attacker can 385 identify the network the client had previously visited. 387 5.5. Finding a stable identity 389 An attacker might use a stable identity gleaned from DHCP messages to 390 correlate activities of a given client on unrelated networks. The 391 Client FQDN option, the Subscriber ID Option and the Client ID 392 options can serve as long lived identifiers of DHCP clients. The 393 Client FQDN option can also provide an identity that can easily be 394 correlated with web server activity logs. 396 5.6. Pervasive monitoring 398 This is an enhancement, or a combination of most aforementioned 399 mechanisms. Operator who controls non-trivial number of access 400 points or network segments, may use obtained information about a 401 single client and observer client's habits. 403 5.7. Finding client's IP address or hostname 405 Many DHCP deployments use DNS Updates [RFC4702] that put client's 406 information (current IP address, client's hostname). Client ID is 407 also disclosed, able it in not easily accessible form (SHA-256 digest 408 of the client-id). Although SHA-256 is irreversible, so DHCID can't 409 be converted back to client-id. However, SHA-256 digest can be used 410 as a unique identifier that is accessible by any host. 412 5.8. Correlation of activities over time 414 As with other identifiers, an IP address can be used to correlate the 415 activities of a host for at least as long as the lifetime of the 416 address. If that address was generated from some other, stable 417 identifier and that generation scheme can be deducted by an attacker, 418 the duration of correlation attack extends to that identifier. In 419 many cases, its lifetime is equal to the lifetime of the device 420 itself. 422 5.9. Location tracking 424 If a stable identifier is used for assigning an address and such 425 mapping is discovered by an attacker. In particular both passive (a 426 service that the client connects to can log client's address and draw 427 conclusions regarding its location and movement patterns based on 428 address it is connecting from) and active (attacker can send ICMP 429 echo requests or other probe packets to networks of suspected client 430 locations). 432 5.10. Leasequery & bulk leasequery 434 Attackers may pretend as an access concentrator, either DHCP relay 435 agent or DHCP client, to obtain location information directly from 436 the DHCP server(s) using the DHCP leasequery [RFC4388], [RFC6148] 437 mechanism. 439 Location information is information needed by the access concentrator 440 to forward traffic to a broadband-accessible host. This information 441 includes knowledge of the host hardware address, the port or virtual 442 circuit that leads to the host, and/or the hardware address of the 443 intervening subscriber modem. 445 Furthermore, the attackers may use DHCP bulk leasequery [RFC6926] 446 mechanism to obtain bulk information about DHCP bindings, even 447 without knowing the target bindings. 449 6. Security Considerations 451 In current practice, the client privacy and the client authentication 452 are mutually exclusive. The client authentication procedure reveals 453 additional client information in their certificates/identifiers. 454 Full privacy for the clients may mean the clients are also anonymous 455 for the server and the network. 457 7. Privacy Considerations 459 This document at its entirety discusses privacy considerations in 460 DHCP. As such, no separate section about this is needed. 462 8. IANA Considerations 464 This draft does not request any IANA action. 466 9. Acknowledgements 468 The authors would like to thanks the valuable comments made by 469 Stephen Farrell, Ted Lemon, Ines Robles, Russ White, Christian 470 Huitema, Bernie Volz and other members of DHC WG. 472 This document was produced using the xml2rfc tool [RFC2629]. 474 10. References 476 10.1. Normative References 478 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 479 Requirement Levels", BCP 14, RFC 2119, March 1997. 481 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 482 2131, March 1997. 484 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 485 3046, January 2001. 487 [RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, 488 "Link Selection sub-option for the Relay Agent Information 489 Option for DHCPv4", RFC 3527, April 2003. 491 [RFC3925] Littlefield, J., "Vendor-Identifying Vendor Options for 492 Dynamic Host Configuration Protocol version 4 (DHCPv4)", 493 RFC 3925, October 2004. 495 [RFC3993] Johnson, R., Palaniappan, T., and M. Stapp, "Subscriber-ID 496 Suboption for the Dynamic Host Configuration Protocol 497 (DHCP) Relay Agent Option", RFC 3993, March 2005. 499 [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client 500 Identifiers for Dynamic Host Configuration Protocol 501 Version Four (DHCPv4)", RFC 4361, February 2006. 503 [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration 504 Protocol (DHCP) Leasequery", RFC 4388, February 2006. 506 [RFC4702] Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host 507 Configuration Protocol (DHCP) Client Fully Qualified 508 Domain Name (FQDN) Option", RFC 4702, October 2006. 510 [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for 511 IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) 512 Option", RFC 4704, October 2006. 514 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 515 (DHCPv4 and DHCPv6) Option for Civic Addresses 516 Configuration Information", RFC 4776, November 2006. 518 [RFC6148] Kurapati, P., Desetti, R., and B. Joshi, "DHCPv4 Lease 519 Query by Relay Agent Remote ID", RFC 6148, February 2011. 521 [RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, "Dynamic 522 Host Configuration Protocol Options for Coordinate-Based 523 Location Configuration Information", RFC 6225, July 2011. 525 [RFC6926] Kinnear, K., Stapp, M., Desetti, R., Joshi, B., Russell, 526 N., Kurapati, P., and B. Volz, "DHCPv4 Bulk Leasequery", 527 RFC 6926, April 2013. 529 10.2. Informative References 531 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 532 June 1999. 534 [RFC4578] Johnston, M. and S. Venaas, "Dynamic Host Configuration 535 Protocol (DHCP) Options for the Intel Preboot eXecution 536 Environment (PXE)", RFC 4578, November 2006. 538 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 539 Morris, J., Hansen, M., and R. Smith, "Privacy 540 Considerations for Internet Protocols", RFC 6973, July 541 2013. 543 Authors' Addresses 545 Sheng Jiang 546 Huawei Technologies Co., Ltd 547 Q14, Huawei Campus, No.156 Beiqing Road 548 Hai-Dian District, Beijing, 100095 549 P.R. China 551 Email: jiangsheng@huawei.com 553 Suresh Krishnan 554 Ericsson 555 8400 Decarie Blvd. 556 Town of Mount Royal, QC 557 Canada 559 Phone: +1 514 345 7900 x42871 560 Email: suresh.krishnan@ericsson.com 561 Tomek Mrugalski 562 Internet Systems Consortium, Inc. 563 950 Charter Street 564 Redwood City, CA 94063 565 USA 567 Phone: +1 650 423 1345 568 Email: tomasz.mrugalski@gmail.com