idnits 2.17.1 draft-ietf-behave-turn-tcp-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 -- 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 (July 8, 2010) is 5040 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 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Behave S. Perreault, Ed. 3 Internet-Draft Viagenie 4 Intended status: Standards Track J. Rosenberg 5 Expires: January 9, 2011 jdrosen.net 6 July 8, 2010 8 Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations 9 draft-ietf-behave-turn-tcp-07.txt 11 Abstract 13 This specification defines an extension of Traversal Using Relays 14 around NAT (TURN), a relay protocol for Network Address Translation 15 (NAT) traversal, to allow a TURN client to request TCP allocations, 16 and defines new requests and indications for the TURN server to open 17 and accept TCP connections with the client's peers. TURN and this 18 extension both purposefully restrict the ways in which the relayed 19 address can be used. In particular, it prevents users from running 20 general purpose servers from ports obtained from the TURN server. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 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 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on January 9, 2011. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4 65 4. Client Processing . . . . . . . . . . . . . . . . . . . . . . 6 66 4.1. Creating an Allocation . . . . . . . . . . . . . . . . . . 6 67 4.2. Refreshing an Allocation . . . . . . . . . . . . . . . . . 7 68 4.3. Initiating a Connection . . . . . . . . . . . . . . . . . 7 69 4.4. Receiving a Connection . . . . . . . . . . . . . . . . . . 7 70 4.5. Sending and Receiving Data . . . . . . . . . . . . . . . . 8 71 4.6. Data Connection Maintenance . . . . . . . . . . . . . . . 8 72 5. TURN Server Behavior . . . . . . . . . . . . . . . . . . . . . 8 73 5.1. Receiving a TCP Allocate Request . . . . . . . . . . . . . 8 74 5.2. Receiving a Connect Request . . . . . . . . . . . . . . . 9 75 5.3. Receiving a TCP Connection on a Relayed Transport 76 Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 5.4. Receiving a ConnectionBind Request . . . . . . . . . . . . 11 78 5.5. Data Connection Maintenance . . . . . . . . . . . . . . . 11 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 80 6.1. New STUN Methods . . . . . . . . . . . . . . . . . . . . . 11 81 6.2. New STUN Attributes . . . . . . . . . . . . . . . . . . . 12 82 6.2.1. CONNECTION-ID . . . . . . . . . . . . . . . . . . . . 12 83 6.3. New STUN Error Codes . . . . . . . . . . . . . . . . . . . 12 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 85 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 87 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 88 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 91 1. Introduction 93 Traversal Using Relays around NAT (TURN) [RFC5766] is an extension to 94 the Session Traversal Utilities for NAT [RFC5389] protocol. TURN 95 allows for clients to communicate with a TURN server, and ask it to 96 allocate ports on one of its host interfaces, and then relay traffic 97 between that port and the client itself. TURN, when used in concert 98 with STUN and Interactive Connectivity Establishment (ICE) [RFC5245] 99 form a solution for NAT traversal for UDP-based media sessions. 101 However, TURN itself does not provide a way for a client to allocate 102 a TCP-based port on a TURN server. Such an allocation is needed for 103 cases where a TCP-based session is desired with a peer, and NATs 104 prevent a direct TCP connection. Examples include application 105 sharing between desktop softphones, or transmission of pictures 106 during a voice communications session. 108 This document defines an extension to TURN which allows a client to 109 obtain a TCP allocation. It also allows the client to initiate 110 outgoing TCP connections from that allocation to peers, and accept 111 incoming TCP connection requests from peers made towards that 112 allocation. 114 The term "TCP allocation" means a TURN allocation where TCP is used 115 as the transport protocol instead of UDP. Such an allocation is 116 uniquely identified by its relayed transport address, which consists 117 of an IP address and TCP port (defined in [RFC5766]). 119 2. Conventions 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 3. Overview of Operation 127 +--------+ 128 | | 129 | Peer1 | 130 / | | 131 / | | 132 / +--------+ 133 / 134 / 135 / Peer Data 1 136 / 137 +--------+ Control +--------+ / 138 | | -------------- | | / 139 | Client | Client Data 1 | TURN | 140 | | -------------- | Server | \ 141 | | -------------- | | \ 142 +--------+ Client Data 2 +--------+ \ 143 \ 144 \ 145 \ +--------+ 146 \ | | 147 Peer Data 2 \ | Peer2 | 148 \ | | 149 | | 150 +--------+ 152 Figure 1: TURN TCP Model 154 The overall model for TURN-TCP is shown in Figure 1. The client will 155 have two different types of connections to its TURN server. For each 156 allocated relayed transport address, it will have a single control 157 connection. Control connections are used to obtain allocations and 158 open up new connections. Furthermore, for each connection to a peer, 159 the client will have a single connection to its TURN server. These 160 connections are called data connections. Consequently, there is a 161 data connection from the client to its TURN server (the client data 162 connection) and one from the TURN server to a peer (the peer data 163 connection). Actual application data is sent on these connections. 164 Indeed, after an initial TURN message which binds the client data 165 connection to a peer data connection, only application data can be 166 sent - no TURN messaging. This is in contrast to the control 167 connection, which only allows TURN messages and not application data. 169 To obtain a TCP-based allocation, a client first opens a TCP or TLS 170 connection to its TURN server. The client then sends an Allocate 171 request over that control connection. That request contains a 172 REQUESTED-TRANSPORT attribute, which indicates a TCP-based allocation 173 is desired. A server which supports this extension will allocate a 174 TCP relayed transport address and begin listening for connection 175 requests on it. It then returns the allocated relayed transport 176 address to the client in the response to the Allocate request. The 177 connection on which the Allocate request was sent is the control 178 connection. 180 If a client wishes to establish a TCP connection to a peer from that 181 relayed transport address, it issues a Connect request to the TURN 182 server over the control connection. That request contains a XOR- 183 PEER-ADDRESS attribute identifying the peer IP address and port (i.e. 184 its "transport address") to which a connection is to be made. The 185 TURN server attempts to open the TCP connection, and assuming it 186 succeeds, then responds to the Connect request with a success 187 response. The server also creates a connection identifier associated 188 with this connection, and passes that connection identifier back to 189 the client in the success response. Note that a maximum of one 190 connection to a given peer transport address can be established per 191 allocation. 193 Note: Establishing a relayed connection from the client to a peer 194 is done in two steps. First, the allocation is created, and 195 second, the connection is established. Combining the two is not 196 desirable for NAT traversal. It is expected that, between the 197 first and second steps, the client will communicate off-band with 198 the peer (e.g. using ICE [RFC5245]) and tell it the relayed 199 transport address that the TURN server allocated and from which it 200 is about to initiate a connection. The peer can then "get ready": 201 open holes in its firewall, try to poke holes in a NAT, attempt a 202 TCP simultaneous open, etc. 204 In order to actually send data on the new connection or otherwise 205 utilize it in any way, the client establishes a new TCP connection to 206 its TURN server. Once established, it issues a ConnectionBind 207 request to the server over this new connection. That request echoes 208 back the connection identifier to the TURN server. The TURN server 209 uses it to correlate the two connections. As a consequence, the TCP 210 connection to the peer is associated with a TCP connection to the 211 client 1-to-1. The two connections are now data connections. At 212 this point, if the server receives data from the peer, it forwards 213 that data towards the client, without any kind of encapsulation. Any 214 data received by the TURN server from the client over the client data 215 connection are forwarded to the peer, again without encapsulation or 216 framing of any kind. Once a connection has been bound using the 217 ConnectionBind request, TURN messaging is no longer permitted on the 218 connection. 220 In a similar way, when a peer opens a TCP connection towards the 221 relayed transport address, the server checks if there is a permission 222 in place for that peer. If there is none, the connection is closed. 223 Permissions are created with the CreatePermission request sent over 224 the control connection, just as for UDP TURN. If there is a 225 permission in place, the TURN server sends, to the client, a 226 ConnectionAttempt Indication over the control connection. That 227 indication contains a connection identifier. Once again, the client 228 initiates a separate TCP connection to its TURN server, and over that 229 connection, issues a ConnectionBind request. Once received, the TURN 230 server will begin relaying data back and forth. The server closes 231 the peer data connection if no ConnectionBind request is received 232 after a timeout. 234 If the client closes a client data connection, the corresponding peer 235 data connection is closed. If the peer closes a peer data 236 connection, the corresponding client data connection is closed. In 237 this way, the status of the connection is directly known to the 238 client. 240 The TURN server will relay the data between the client and peer data 241 connections. End-to-end flow control is maintained by the relay 242 process: if the relay process is no longer able to write data to the 243 destination of the relayed data, the relay process stops reading data 244 from the source. 246 4. Client Processing 248 4.1. Creating an Allocation 250 To create a TCP allocation, a client MUST initiate a new TCP or TLS 251 connection to its TURN server, identical to the TCP or TLS procedures 252 defined in [RFC5766]. TCP allocations cannot be obtained using a UDP 253 association between client and server. 255 Once set up, a client MUST send a TURN Allocate request. That 256 request MUST contain a REQUESTED-TRANSPORT attribute whose value is 257 6, corresponding to TCP. 259 The request MUST NOT include a DONT-FRAGMENT, RESERVATION-TOKEN or 260 EVEN-PORT attribute. The corresponding features are specific to UDP 261 based capabilities and are not utilized by TURN-TCP. However, a 262 LIFETIME attribute MAY be included, with semantics identical to the 263 UDP case. 265 The procedures for authentication of the Allocate request and 266 processing of success and failure responses are identical to those 267 for UDP. 269 Once a success response is received, the TCP connection to the TURN 270 server is called the control connection for that allocation. 272 4.2. Refreshing an Allocation 274 The procedures for refreshing an allocation are identical to those 275 for UDP. Note that the Refresh MUST be sent on the control 276 connection. 278 4.3. Initiating a Connection 280 To initiate a TCP connection to a peer, a client MUST send a Connect 281 request over the control connection for the desired allocation. The 282 Connect request MUST include a XOR-PEER-ADDRESS attribute containing 283 the transport address of the peer to which a connection is desired. 285 If the connection is successfully established, the client will 286 receive a success response. That response will contain a 287 CONNECTION-ID attribute. The client MUST initiate a new TCP 288 connection to the server, utilizing the same destination transport 289 address to which the control connection was established. This 290 connection MUST be made using a different local transport address. 291 Authentication of the client by the server MUST use the same method 292 and credentials as for the control connection. Once established, the 293 client MUST send a ConnectionBind request over the new connection. 294 That request MUST include the CONNECTION-ID attribute, echoed from 295 the Connect Success response. When a response to the ConnectionBind 296 request is received, if it is a success, the TCP connection on which 297 it was sent is called the client data connection corresponding to the 298 peer. 300 If the result of the Connect request was a Error Response, and the 301 response code was 447 (Connection Timeout or Failure), it means that 302 the TURN server was unable to connect to the peer. The client MAY 303 retry with the same XOR-PEER-ADDRESS attribute, but MUST wait at 304 least 10 seconds. 306 As with any other request, multiple Connect requests MAY be sent 307 simultaneously. However, Connect requests with the same XOR-PEER- 308 ADDRESS parameter MUST NOT be sent simultaneously. 310 4.4. Receiving a Connection 312 After an Allocate request is successfully processed by the server, 313 the client will start receiving a ConnectionAttempt indication each 314 time a peer for which a permission has been installed attempts a new 315 connection to the relayed transport address. This indication will 316 contain a CONNECTION-ID and a XOR-PEER-ADDRESS attributes. If the 317 client wishes to accept this connection, it MUST initiate a new TCP 318 connection to the server, utilizing the same destination transport 319 address to which the control connection was established. This 320 connection MUST be made using a different local transport address. 321 Authentication of the client by the server MUST use the same method 322 and credentials as for the control connection. Once established, the 323 client MUST send a ConnectionBind request over the new connection. 324 That request MUST include the CONNECTION-ID attribute, echoed from 325 the ConnectionAttempt indication. When a response to the 326 ConnectionBind request is received, if it is a success, the TCP 327 connection on which it was sent is called the client data connection 328 corresponding to the peer. 330 4.5. Sending and Receiving Data 332 Once a client data connection is established, data sent on it by the 333 client will be relayed as-is to the peer by the server. Similarly, 334 data sent by the peer to the server will be relayed as-is to the 335 client over the data connection. 337 4.6. Data Connection Maintenance 339 The client MUST refresh the allocation corresponding to a data 340 connection, using the Refresh request as defined in [RFC5766], for as 341 long as it wants to keep the data connection alive. 343 When the client wishes to terminate its relayed connection to the 344 peer, it closes the data connection to the server. 346 Note: No mechanism for keeping alive the NAT bindings (potentially 347 on the client data connection as well as on the peer data 348 connection) is included. This service is not provided by TURN- 349 TCP. If such a feature is deemed necessary, it can be implemented 350 higher up the stack, in the application protocol being tunneled 351 inside TURN-TCP. Also, TCP keep-alives MAY be used to keep the 352 NAT bindings on the client data connection alive. 354 5. TURN Server Behavior 356 5.1. Receiving a TCP Allocate Request 358 The process is similar to that defined in [RFC5766], Section 6.2, 359 with the following exceptions: 361 1. If the REQUESTED-TRANSPORT attribute is included and specifies a 362 protocol other than UDP or TCP, the server MUST reject the 363 request with a 442 (Unsupported Transport Protocol) error. If 364 the value is UDP, and if UDP transport is allowed by local 365 policy, the server MUST continue with the procedures of [RFC5766] 366 instead of this document. If the value is UDP, and if UDP 367 transport is forbidden by local policy, the server MUST reject 368 the request with a 403 (Forbidden) error. 370 2. If the client connection transport is not TCP or TLS, the server 371 MUST reject the request with a 400 (Bad Request) error. 373 3. If the request contains the DONT-FRAGMENT, EVEN-PORT, or 374 RESERVATION-TOKEN attribute, the server MUST reject the request 375 with a 400 (Bad Request) error. 377 4. A TCP relayed transport address MUST be allocated instead of a 378 UDP one. 380 5. The RESERVATION-TOKEN attribute MUST NOT be present in the 381 success response. 383 If all checks pass, the server MUST start accepting incoming TCP 384 connections on the relayed transport address. Refer to Section 5.3 385 for details. 387 5.2. Receiving a Connect Request 389 When the server receives a Connect request, it processes as follows. 391 If the request is received on a TCP connection for which no 392 allocation exists, the server MUST return a 437 (Allocation Mismatch) 393 error. 395 If the server is currently processing a Connect request for this 396 allocation with the same XOR-PEER-ADDRESS, it MUST return a 446 397 (Connection Already Exists) error. 399 If the server has already successfully processed a Connect request 400 for this allocation with the same XOR-PEER-ADDRESS, and the resulting 401 client and peer data connections are either pending or active, it 402 MUST return a 446 (Connection Already Exists) error. 404 If the request does not contain a XOR-PEER-ADDRESS attribute, or if 405 such attribute is invalid, the server MUST return a 400 (Bad Request) 406 error. 408 If the new connection is forbidden by local policy, the server MUST 409 reject the request with a 403 (Forbidden) error. 411 Otherwise, the server MUST initiate an outgoing TCP connection. The 412 local endpoint is the relayed transport address associated with the 413 allocation. The remote endpoint is the one indicated by the XOR- 414 PEER-ADDRESS attribute. If the connection attempt fails or times 415 out, the server MUST return a 447 (Connection Timeout or Failure) 416 error. The timeout value MUST be at least 30 seconds. 418 If the connection is successful, it is now called a peer data 419 connection. The server MUST buffer any data received from the 420 client. The server adjusts its advertised TCP receive window to 421 reflect the amount of empty buffer space. 423 The server MUST include the CONNECTION-ID attribute in the Connect 424 success response. The attribute's value MUST uniquely identify the 425 peer data connection. 427 If no ConnectionBind request associated with this peer data 428 connection is received after 30 seconds, the peer data connection 429 MUST be closed. 431 5.3. Receiving a TCP Connection on a Relayed Transport Address 433 When a server receives an incoming TCP connection on a relayed 434 transport address, it processes as follows. 436 The server MUST accept the connection. If it is not successful, 437 nothing is sent to the client over the control connection. 439 If the connection is successfully accepted, it is now called a peer 440 data connection. The server MUST buffer any data received from the 441 peer. The server adjusts its advertised TCP receive window to 442 reflect the amount of empty buffer space. 444 If no permission for this peer has been installed for this 445 allocation, the server MUST close the connection with the peer 446 immediately after it has been accepted. 448 Otherwise, the server sends a ConnectionAttempt indication to the 449 client over the control connection. The indication MUST include a 450 XOR-PEER-ADDRESS attribute containing the peer's transport address, 451 as well as a CONNECTION-ID attribute uniquely identifying the peer 452 data connection. 454 If no ConnectionBind request associated with this peer data 455 connection is received after 30 seconds, the peer data connection 456 MUST be closed. 458 5.4. Receiving a ConnectionBind Request 460 When a server receives a ConnectionBind request, it processes as 461 follows. 463 If the client connection transport is not TCP or TLS, the server MUST 464 return a 400 (Bad Request) error. 466 If the request does not contain the CONNECTION-ID attribute, or if 467 this attribute does not refer to an existing pending connection, the 468 server MUST return a 400 (Bad Request) error. 470 Otherwise, the client connection is now called a client data 471 connection. Data received on it MUST be sent as-is to the associated 472 peer data connection. 474 Data received on the associated peer data connection MUST be sent 475 as-is on this client data connection. This includes data that was 476 received after the associated Connect or request was successfully 477 processed and before this ConnectionBind request was received. 479 5.5. Data Connection Maintenance 481 If the allocation associated with a data connection expires, the data 482 connection MUST be closed. 484 When a client data connection is closed, the server MUST close the 485 corresponding peer data connection. 487 When a peer data connection is closed, the server MUST close the 488 corresponding client data connection. 490 6. IANA Considerations 492 This specification defines several new STUN methods, STUN attributes, 493 and STUN error codes. This section directs IANA to add these new 494 protocol elements to the IANA registry of STUN protocol elements. 496 6.1. New STUN Methods 498 This section lists the codepoints for the new STUN methods defined in 499 this specification. See Section 4 and Section 5 for the semantics of 500 these new methods. 502 0x000A : Connect 503 0x000B : ConnectionBind 504 0x000C : ConnectionAttempt 506 6.2. New STUN Attributes 508 This STUN extension defines the following new attributes: 510 0x002A : CONNECTION-ID 512 6.2.1. CONNECTION-ID 514 The CONNECTION-ID attributes uniquely identifies a peer data 515 connection. It is a 32-bit unsigned integral value. 517 6.3. New STUN Error Codes 519 446 Connection Already Exists 520 447 Connection Timeout or Failure 522 7. Security Considerations 524 After a TCP connection is established between the server and a peer, 525 and before a ConnectionBind request is received from the client, the 526 server buffers all data received from the peer. This protocol 527 specification lets the server drop the connection if the buffer size 528 is about to exceed a limit defined by local policy. This policy 529 should ensure that memory resources are not exceeded. See also 530 [RFC4732], Section 2.1.3. 532 All the security considerations applicable to STUN [RFC5389] and TURN 533 [RFC5766] are applicable to this document as well. 535 8. Acknowledgements 537 Thanks to Rohan Mahy and Philip Matthews for their initial work on 538 getting this document started. 540 The authors would also like to thank Alfred E. Heggestad, Ari 541 Keranen, Marc Petit-Huguenin, Dave Thaler, and Dan Wing for their 542 comments and suggestions. 544 9. References 546 9.1. Normative References 548 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 549 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 550 October 2008. 552 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 553 Relays around NAT (TURN): Relay Extensions to Session 554 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 556 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 557 Requirement Levels", BCP 14, RFC 2119, March 1997. 559 9.2. Informative References 561 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 562 (ICE): A Protocol for Network Address Translator (NAT) 563 Traversal for Offer/Answer Protocols", RFC 5245, 564 April 2010. 566 [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- 567 Service Considerations", RFC 4732, December 2006. 569 Authors' Addresses 571 Simon Perreault (editor) 572 Viagenie 573 2600 boul. Laurier, suite 625 574 Quebec, QC G1V 4W1 575 Canada 577 Phone: +1 418 656 9254 578 Email: simon.perreault@viagenie.ca 579 URI: http://www.viagenie.ca 581 Jonathan Rosenberg 582 jdrosen.net 583 Monmouth, NJ 584 US 586 Email: jdrosen@jdrosen.net 587 URI: http://www.jdrosen.net