idnits 2.17.1 draft-gont-6man-non-stable-iids-01.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 : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The abstract seems to indicate that this document updates RFC4941, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2017) is 2600 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) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) == Outdated reference: A later version (-05) exists of draft-gont-6man-address-usage-recommendations-01 == Outdated reference: A later version (-03) exists of draft-gont-predictable-numeric-ids-00 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 maintenance Working Group (6man) F. Gont 3 Internet-Draft SI6 Networks / UTN-FRH 4 Updates: RFC4941 (if approved) C. Huitema 5 Intended status: Standards Track Private Octopus Inc. 6 Expires: September 14, 2017 G. Gont 7 SI6 Networks 8 M. Garcia Corbo 9 SITRANS 10 March 13, 2017 12 Recommendation on Temporary IPv6 Interface Identifiers 13 draft-gont-6man-non-stable-iids-01 15 Abstract 17 This document clarifies the stability requirements for IPv6 18 addresses, and provides recommendations regarding the generation of 19 Temporary addresses. Finally, it formally updates RFC4941 such that 20 nodes are allowed to configure only temporary addresses. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 14, 2017. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Generation of Temporary IPv6 Addresses . . . . . . . . . . . 6 60 5. Update to existing RFCs . . . . . . . . . . . . . . . . . . . 8 61 6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 64 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 65 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 68 1. Introduction 70 IPv6 StateLess Address AutoConfiguration (SLAAC) [RFC4862] has 71 traditionally resulted in stable addresses, since the Interface 72 Identifier (IID) has been generated by embedding a stable layer-2 73 numeric identifier (e.g., a MAC address). [RFC4941] implies, 74 throughout the specification, that temporary addresses are generated 75 and employed along with temporary addresses. 77 While the use of stable addresses (only) or mixed stable and 78 temporary addresses can be desirable in a number of scenarios, there 79 are other scenarios in which, for security and privacy reasons, a 80 node may want to use only Temporary address (e.g., a temporary 81 address). 83 This document clarifies the requirements for stability of IPv6 84 addresses, such that nodes are not required to configure stable 85 addresses. It also specifies a set of requirements for the 86 generation of Temporary addresses, and also specifies some sample 87 algorithms that may be employed to generate temporary addresses that 88 comply with the aforementioned requirements. Finally, it formally 89 updates [RFC4941] such that temporary addresses can be employed 90 without the need to configure a stable address along side. 92 2. Terminology 94 This document employs the terms defined in [RFC7721]. 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC 2119 [RFC2119]. 100 3. Problem statement 102 When [RFC4941] was written, its authors wanted to prevent privacy and 103 security attacks enabled by addresses that contain "an embedded 104 interface identifier, which remains constant over time". They 105 observed that "Anytime a fixed identifier is used in multiple 106 contexts, it becomes possible to correlate seemingly unrelated 107 activity using this identifier." They were concerned with both on- 108 path attackers who would observe the IP addresses of packets observed 109 in transit, and attackers that would have access to the logs of 110 servers. 112 Since the publication of [RFC4941] in September 2007, our 113 understanding of threats and mitigations has evolved. The IETF is 114 now officially concerned with Pervasive Monitoring [RFC7258], as well 115 as the wide spread collection of information for advertising and 116 other purposes, for example through the Real Time Bidding protocol 117 used for advertising auctions [RTB25]. 119 3.1. Privacy requirements 121 The widespread deployment of encryption advocated in [RFC7624] is a 122 response to Pervasive Monitoring. Encryption of communication 123 reduces the amount of information that can be collected by monitoring 124 data links, but does not prevent monitoring of IPv6 addresses 125 embedded in clear text packet headers. Stable IPv6 addresses enable 126 the correlation of such data over time. 128 MAC Address Randomization [IETFMACRandom] is another response to 129 pervasive monitoring. In conjunction with DHCP Anonymity [RFC7844], 130 it ensures that devices cannot be tracked by their MAC Address or 131 their DHCP identifiers when they connect to "hot spots". However, 132 the privacy effects of MAC Address Randomization would be nullified 133 if a device kept using the same IPv6 address before and after a MAC- 134 address randomization event. 136 Many Web Browsers have options enabling browsing "in private". 137 However, if the web connections during the private mode use the same 138 IPv6 address as those in the public mode, web tracking systems 139 similar to [RTB25] will quickly find the correlation between the 140 public personna of the user and the supposedly private connection. 141 Similarly, many web browsers have options to "delete history", 142 including deleting "cookies" and other persistent data. Again, if 143 the same IPv6 address is used before and after the deletion of 144 cookies, web tracking systems will easily correlate the new activity 145 with the prior data collection. 147 Using temporary address alone may not be sufficient to prevent all 148 forms of tracking. It is however quite clear that some usage of 149 temporary addresses is necessary to provide user privacy. It is also 150 clear that the usage of temporary addresses needs to be synchronized 151 with other privacy defining event such as moving to a new network, 152 performing MAC Address Randomization, or changing the privacy posture 153 of a node. 155 3.2. Stability Requirements for IPv6 Addresses 157 Nodes are not required to generate addresses with any specific 158 stability properties. That is, the generation of stable addresses is 159 OPTIONAL. This means that a node may end up configuring only stable 160 addresses, only Temporary, or both stable and temporary addresses. 162 3.3. Requirements for Temporary IPv6 Addresses 164 The requirements for temporary IPv6 addresses are as follows: 166 1. Temporary addresses MUST have a limited lifetime, which should be 167 different for different addresses. The lifetime of an address 168 essentially limits the extent to which network activity 169 correlation can be performed based on such address. 171 2. The lifetime of an address MUST be further reduced when privacy- 172 meaningful events (such as a node attaching to a new network) 173 takes place. 175 3. The resulting Interface Identifiers MUST be different when 176 addresses are configured for different prefixes. That is, if 177 different autoconfiguration prefixes are used to configure 178 addresses for the same network interface card, the resulting 179 Interface Identifiers must be (statistically) different. This 180 means that, given two addresses that employ different prefixes, 181 it must be difficult for an outside entity to tell whether the 182 addresses correspond to the same network interface or even 183 whether they have been generated by the same host. 185 4. The resulting interface identifiers MUST NOT embed layer-2 186 identifiers (e.g. MAC addresses). 188 5. It must be difficult for an outside entity to predict the 189 Interface Identifiers that will be generated by the algorithm, 190 even with knowledge of the Interface Identifiers generated for 191 configuring other addresses. 193 6. The resulting Interface Identifiers MUST be semantically opaque 194 [RFC7136] and MUST NOT follow any specific patterns. 196 By definition, temporary addresses have a limited lifetime. This is 197 in contrast with e.g. stable addresses [RFC7217], that do not have 198 have a limited lifetime. Having a variable maximum lifetime prevents 199 an observer from synchronizing with the temporary address 200 regeneration; that is, from being able to expect when address will be 201 regenerated, and thus infer that one newly observed addresses is the 202 result of regenerating a previously observed one. 204 The lifetime of an address should be further reduced by privacy- 205 meaningful events. For example, a host should not employ the same 206 address across network attachment events. That is, a host that de- 207 attaches from a network and subsequently re-attaches to a (possibly 208 different) network should regenerate all of its temporary addresses. 209 Similarly, a host that implements MAC address randomization should 210 regenerate all of its temporary addresses. Other events, such as 211 those discussed in Section 3.1 should also trigger the regeneration 212 of all temporary addresses. 214 The IIDs of addresses configured for different autoconfiguration 215 prefixes must be different, such that traffic for those addresses 216 cannot be correlated. 218 The reuse of identifiers that have their own semantics or properties 219 across different contexts or scopes can be detrimental for security 220 and privacy [I-D.gont-predictable-numeric-ids] [RFC6973] [RFC4941]. 221 For example, if two different layer-3 protocols generate their 222 addresses by embedding a layer-2 identifier (e.g., a MAC address), 223 then the traffic for such protocols could be correlated (irrespective 224 of whether the aforementioned layer-2 identifier has been randomized 225 or not). Besides, a node that generates an IPv6 address by embedding 226 a link-layer address in the IPv6 address will, when configuring 227 addresses for different prefixes, result in the same IID being used 228 for such prefixes, thus allowing the corresponding traffic to be 229 correlated. 231 For security and privacy reasons, the IIDs generated for temporary 232 addresses must not be predictable. Otherwise, the node may be 233 subject to many (if not all) of the security and privacy issues that 234 are meant to be mitigated (please see [RFC7721]. 236 Any semantics or patterns in an IID might be leveraged by an attacker 237 to e.g. reduce the search space when performing address-scanning 238 attacks, infer the identity of the node, etc. 240 4. Generation of Temporary IPv6 Addresses 242 The following subsections specify algorithms that may be employed to 243 generate temporary addresses that comply with the requirements 244 specified in Section 3.3. 246 4.1. RFC 4941 248 One possible algorithm for generating temporary IPv6 addresses is 249 that specified in [RFC4941]. 251 We note that, since the publication of [RFC4941], a number of issues 252 have been found in common implementations of such algorithm 253 [RAID2015]. 255 TODO: It remains an open question what to do with respect to 256 RFC4941. If this draft was to obsolete RFC4941, instead of merely 257 update it, we would need to include here the actual specification 258 of the address generation algorithm. 260 4.2. Randomized IIDs 262 Another possible approach would be to select a random IID when 263 performing SLAAC. A node employing this algorithm should generate 264 IIDs as follows: 266 1. Obtain a random number (see [RFC4086] for randomness requirements 267 for security) 269 2. The Interface Identifier is obtained by taking as many bits from 270 the aforementioned random number (obtained in the previous step) 271 as necessary. 273 We note that [RFC4291] requires that the Interface IDs of all 274 unicast addresses (except those that start with the binary 275 value 000) be 64 bits long. However, the method discussed in 276 this document could be employed for generating Interface IDs 277 of any arbitrary length, albeit at the expense of reduced 278 entropy (when employing Interface IDs smaller than 64 bits). 280 The resulting Interface Identifier SHOULD be compared against the 281 reserved IPv6 Interface Identifiers [RFC5453] [IANA-RESERVED-IID] 282 and against those Interface Identifiers already employed in an 283 address of the same network interface and the same network 284 prefix. In the event that an unacceptable identifier has been 285 generated, this situation SHOULD be handled in the same way as 286 the case of duplicate addresses. 288 A node that disconnects from the network and subsequently reconnects 289 would employ a (statistically different) IID for the same prefix. 290 Similarly, a different (random) IID should be employed for each 291 autoconfiguration prefix. In the event of Duplicate Address 292 Detection (DAD) [RFC4862] failures, another random number should be 293 selected to recover from the DAD failure. 295 4.3. Hash-based generation of temporary address generation 297 The algorithm in [RFC7217] can be augmented for the generation of 298 temporary addresses. The benefit of this would be that a node could 299 employ a single algorithm for generating stable and temporary 300 addresses, by employing appropriate parameters. 302 Nodes would employ the following algorithm for generating the 303 temporary IID: 305 1. Compute a random identifier with the expression: 307 RID = F(Prefix, MAC_Address, Network_ID, Time, DAD_Counter, 308 secret_key) 310 Where: 312 RID: 313 Random Identifier 315 F(): 316 A pseudorandom function (PRF) that MUST NOT be computable from 317 the outside (without knowledge of the secret key). F() MUST 318 also be difficult to reverse, such that it resists attempts to 319 obtain the secret_key, even when given samples of the output 320 of F() and knowledge or control of the other input parameters. 321 F() SHOULD produce an output of at least 64 bits. F() could 322 be implemented as a cryptographic hash of the concatenation of 323 each of the function parameters. SHA-1 [FIPS-SHS] and SHA-256 324 are two possible options for F(). Note: MD5 [RFC1321] is 325 considered unacceptable for F() [RFC6151]. 327 Prefix: 328 The prefix to be used for SLAAC, as learned from an ICMPv6 329 Router Advertisement message, or the link-local IPv6 unicast 330 prefix [RFC4291]. 332 MAC_Address: 333 The MAC address corresponding to the underlying network 334 interface card. Employing the MAC address in this expression 335 (in replacement of the Net_Iface parameter of the expression 336 in RFC7217) means that the re-generation of a randomized MAC 337 address will result in a different temporary address. 339 Network_ID: 340 Some network-specific data that identifies the subnet to which 341 this interface is attached -- for example, the IEEE 802.11 342 Service Set Identifier (SSID) corresponding to the network to 343 which this interface is associated. Additionally, Simple DNA 344 [RFC6059] describes ideas that could be leveraged to generate 345 a Network_ID parameter. This parameter is SHOULD be employed 346 if some form of "Network_ID" is available. 348 Time: 349 An implementation-dependent representation of time. One 350 possible example is the representation in UNIX-like systems 351 [OPEN-GROUP], that measure time in terms of the number of 352 seconds elapsed since the Epoch (00:00:00 Coordinated 353 Universal Time (UTC), 1 January 1970). 355 DAD_Counter: 356 A counter that is employed to resolve Duplicate Address 357 Detection (DAD) conflicts. 359 secret_key: 360 A secret key that is not known by the attacker. The secret 361 key SHOULD be of at least 128 bits. It MUST be initialized to 362 a pseudo-random number (see [RFC4086] for randomness 363 requirements for security) when the operating system is 364 installed or when the IPv6 protocol stack is "bootstrapped" 365 for the first time. 367 2. The Interface Identifier is finally obtained by taking as many 368 bits from the RID value (computed in the previous step) as 369 necessary, starting from the least significant bit. The 370 resulting Interface Identifier SHOULD be compared against the 371 reserved IPv6 Interface Identifiers [RFC5453] [IANA-RESERVED-IID] 372 and against those Interface Identifiers already employed in an 373 address of the same network interface and the same network 374 prefix. In the event that an unacceptable identifier has been 375 generated, this situation SHOULD be handled in the same way as 376 the case of duplicate addresses. 378 5. Update to existing RFCs 380 The following subsections clarify how each of the RFCs affected by 381 this document are updated. 383 5.1. Update to RFC4941 385 The temporary addresses specified in [RFC4941] MAY be used in 386 replacement of the stable addresses [RFC8064]. That is, a node MAY 387 configure temporary addresses only, without configuring any stable 388 addresses. 390 6. Future Work 392 This document clarifies the requirements for stability requirements 393 for IPv6 addresses, and specifies requirements for temporary 394 addresses. A separate document 395 ([I-D.gont-6man-address-usage-recommendations]) discusses the 396 tradeoffs involved when considering different stability properties of 397 IPv6 addresses, and and the different configuration setups such as: 398 stable addresses only, temporary addresses only, or mixed stable and 399 temporary addresses. 401 7. IANA Considerations 403 There are no IANA registries within this document. The RFC-Editor 404 can remove this section before publication of this document as an 405 RFC. 407 8. Security Considerations 409 This document clarifies the stability requirements for IPv6 410 addresses, and specifies requirements for the generation of temporary 411 addresses. Additionally, it formally updates [RFC4941] such that 412 stable addresses are not required to be configured along with the 413 temporary addresses. 415 The security and privacy properties of IPv6 addresses have been 416 discussed in detail in [RFC7721] and [RFC7707]. 418 9. Acknowledgements 420 The authors would like to thank (in alphabetical order) Brian 421 Carpenter and Lorenzo Colitti for providing valuable feedback on 422 earlier versions of this document. 424 10. References 426 10.1. Normative References 428 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 429 Requirement Levels", BCP 14, RFC 2119, 430 DOI 10.17487/RFC2119, March 1997, 431 . 433 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 434 "Randomness Requirements for Security", BCP 106, RFC 4086, 435 DOI 10.17487/RFC4086, June 2005, 436 . 438 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 439 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 440 2006, . 442 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 443 Address Autoconfiguration", RFC 4862, 444 DOI 10.17487/RFC4862, September 2007, 445 . 447 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 448 Extensions for Stateless Address Autoconfiguration in 449 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 450 . 452 [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", 453 RFC 5453, DOI 10.17487/RFC5453, February 2009, 454 . 456 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 457 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 458 February 2014, . 460 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 461 Interface Identifiers with IPv6 Stateless Address 462 Autoconfiguration (SLAAC)", RFC 7217, 463 DOI 10.17487/RFC7217, April 2014, 464 . 466 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 467 "Recommendation on Stable IPv6 Interface Identifiers", 468 RFC 8064, DOI 10.17487/RFC8064, February 2017, 469 . 471 10.2. Informative References 473 [FIPS-SHS] 474 NIST, "Secure Hash Standard (SHS)", FIPS 475 Publication 180-4, March 2012, 476 . 479 [I-D.gont-6man-address-usage-recommendations] 480 Gont, F., Gont, G., and M. Corbo, "IPv6 Address Usage 481 Recommendations", draft-gont-6man-address-usage- 482 recommendations-01 (work in progress), February 2017. 484 [I-D.gont-predictable-numeric-ids] 485 Gont, F. and I. Arce, "Security and Privacy Implications 486 of Numeric Identifiers Employed in Network Protocols", 487 draft-gont-predictable-numeric-ids-00 (work in progress), 488 February 2016. 490 [IANA-RESERVED-IID] 491 IANA, "Reserved IPv6 Interface Identifiers", 492 . 494 [IETFMACRandom] 495 Zuniga, JC., "MAC Privacy", November 2014, 496 . 498 [OPEN-GROUP] 499 The Open Group, "The Open Group Base Specifications Issue 500 7 / IEEE Std 1003.1-2008, 2016 Edition", 501 Section 4.16 Seconds Since the Epoch, 2016, 502 . 505 [RAID2015] 506 Ullrich, J. and E. Weippl, "Privacy is Not an Option: 507 Attacking the IPv6 Privacy Extension", International 508 Symposium on Recent Advances in Intrusion Detection 509 (RAID), 2015, . 512 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 513 DOI 10.17487/RFC1321, April 1992, 514 . 516 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 517 Detecting Network Attachment in IPv6", RFC 6059, 518 DOI 10.17487/RFC6059, November 2010, 519 . 521 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 522 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 523 RFC 6151, DOI 10.17487/RFC6151, March 2011, 524 . 526 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 527 Morris, J., Hansen, M., and R. Smith, "Privacy 528 Considerations for Internet Protocols", RFC 6973, 529 DOI 10.17487/RFC6973, July 2013, 530 . 532 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 533 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 534 2014, . 536 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 537 Trammell, B., Huitema, C., and D. Borkmann, 538 "Confidentiality in the Face of Pervasive Surveillance: A 539 Threat Model and Problem Statement", RFC 7624, 540 DOI 10.17487/RFC7624, August 2015, 541 . 543 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 544 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 545 . 547 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 548 Considerations for IPv6 Address Generation Mechanisms", 549 RFC 7721, DOI 10.17487/RFC7721, March 2016, 550 . 552 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 553 Profiles for DHCP Clients", RFC 7844, 554 DOI 10.17487/RFC7844, May 2016, 555 . 557 [RTB25] Interactive Advertising Bureau (IAB), "Real Time Bidding 558 (RTB) project, OpenRTB API Specification Version 2.5", 559 December 2016, . 563 Authors' Addresses 564 Fernando Gont 565 SI6 Networks / UTN-FRH 566 Evaristo Carriego 2644 567 Haedo, Provincia de Buenos Aires 1706 568 Argentina 570 Phone: +54 11 4650 8472 571 Email: fgont@si6networks.com 572 URI: http://www.si6networks.com 574 Christian Huitema 575 Private Octopus Inc. 576 Friday Harbor, WA 98250 577 U.S.A. 579 Email: huitema@huitema.net 580 URI: http://privateoctopus.com/ 582 Guillermo Gont 583 SI6 Networks 584 Evaristo Carriego 2644 585 Haedo, Provincia de Buenos Aires 1706 586 Argentina 588 Phone: +54 11 4650 8472 589 Email: ggont@si6networks.com 590 URI: https://www.si6networks.com 592 Madeleine Garcia Corbo 593 Servicios de Informacion del Transporte 594 Neptuno 358 595 Havana City 10400 596 Cuba 598 Email: madelen.garcia16@gmail.com