Network Working Group M. Blanchet Internet-Draft R. Desmeules Expires: November 30, 2001 A. Cormier Viagenie inc. June 2001 Tunnel Setup Protocol (TSP) draft-vg-ngtrans-tsp-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 30, 2001. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document proposes a control protocol to setup tunnels between a client and a tunnel server or broker. It provides a framework for the negociation of tunnel parameters between the two entities. It is a generic TCP protocol based on simple XML messaging. This framework protocol enables the negociation of any kind of tunnel, and is extensible to support new parameters or extensions. The first target application is to setup IPv6 over IPv4 tunnels which is one of the transition mechanism identified by the ngtrans and ipv6 working groups. This IPv6 over IPv4 tunnel setup application of the generic TSP protocol is defined by a profile of the TSP protocol, in a Blanchet, et. al. Expires November 30, 2001 [Page 1] Internet-Draft TSP June 2001 companion document. Table of Contents 1. Rationale for a tunnel setup protocol . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 4 3.1 Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.3 Authentication phase . . . . . . . . . . . . . . . . . . . . . 5 3.4 Command phase . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Error codes . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security considerations . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 A. DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 12 Blanchet, et. al. Expires November 30, 2001 [Page 2] Internet-Draft TSP June 2001 1. Rationale for a tunnel setup protocol Tunnelling techniques are often used to enable new networking functions while still preserving the underlying network as is. Configuring tunnels means handling many static parameters (IP address of the end-points, address or overlay network info), which is a tedious task for a network manager for a large number of tunnels. Some of those parameters may change over time, like the IPv4 address of a client node, which means changing the configuration on the other end. A tunnel broker model (RFC3053) [1] has been defined in the context of IPv6 over IPv4 tunnels, where the tunnel broker enables the use of tunnels from a client using a web interface to tunnel servers. Attempts have been made to generalize the idea using a MIME-type [8], but still no protocol has been defined to enable the negociation of parameters over time for a given tunnel. This draft generalize the concept of the tunnel broker model by having a control protocol between the broker and the client. It enables negociation between the two parties: for example, a client might request a feature that the server can not provide. In this context, the client may decide to continue anyway without using that feature or the server could send a list of other servers who might offer the service to the client. The control protocol can optionaly be used to verify the sustainability of the underlying network: similar to the PPP control protocols who verify the link and close the connection when the link is down. It also enables the concept of the degenerated case where the broker and the server are together. This framework protocol enables any kind of current and future tunnel techniques to be defined by a profile of this protocol. 2. Terminology Tunnel Broker (TB) In a Tunnel Broker model, the broker is taking charge of all communication between Tunnel Servers (TS) and Tunnel Clients (TC). Tunnel clients query brokers for a tunnel and the broker find a suitable tunnel server, ask the Tunnel server to setup the tunnel and send the tunnel information to the Tunnel Client. Tunnel Server (TS) Tunnel Servers are providing the specific tunnel service to a Tunnel Client. It can reveive the tunnel request from a Tunnel Broker (as in the Tunnel Broker model) or directly from the Tunnel Client as in the Tunnel Setup Protocol option. Tunnel Client (TC) The Tunnel Client is the entity that need a tunnel for a particular service or connectivity. A Tunnel Client can be Blanchet, et. al. Expires November 30, 2001 [Page 3] Internet-Draft TSP June 2001 either a host or a router. 3. Protocol Description 3.1 Topology The following diagrams describe typical TSP scenarios. The goal is to establish a tunnel between Tunnel client and Tunnel server. Tunnel Setup Protocol used on Tunnel Broker model _______________ | TUNNEL BROKER |--> Databases (dns, whois) | | | TSP TSP | | SERVER CLIENT | |_______________| | | __________ | | ________ | | | | | TSP | | TSP |--[TSP]-- +--[TSP]--| SERVER | | CLIENT | | |--[NETWORK]-- [HOST]--| |<==[CONFIGURED TUNNEL]==>| TUNNEL | |___________| | SERVER | |________| Tunnel Setup Protocol used on Tunnel Server model ___________ ________ | | | TSP | | TSP |-----------[TSP]---------| SERVER | | CLIENT | | |--[NETWORK]-- [HOST]--| |<==[CONFIGURED TUNNEL]==>| TUNNEL | |___________| | SERVER | |________| 3.2 Overview The Tunnel Setup Protocol has three phases: Authentication phase: The Authentication phase is when the Tunnel Brokers/Servers advertises their capability to Tunnel Clients and when Tunnel clients authenticate to the server. Command phase: The command phase is where the client requests or updates a tunnel. Blanchet, et. al. Expires November 30, 2001 [Page 4] Internet-Draft TSP June 2001 For each command sent by a Tunnel Client their is an expected response by the server. 3.3 Authentication phase The authentication phase has 3 steps : o Client's protocol version identification o Server's capability advertisement o Client authentication When a TCP session is established to a Tunnel Server, the Tunnel Client sends the current protocol version it is supporting. The version number syntax is: VERSION=1.0 CR LF Version 1.0 is the version number of this specification. If the server doesn't support the protocol version it sends an error message and closes the session. The server can optionally send a server list that may support the protocol version of the client. Example of a Version not supported (without a server list) -- Successful TCP Connection -- C:VERSION=0.1 CR LF S:302 Unsupported client version CR LF -- Connection closed -- Blanchet, et. al. Expires November 30, 2001 [Page 5] Internet-Draft TSP June 2001 Example of a Version not supported (with a server list) -- Successful TCP Connection -- C:VERSION=1.1 CR LF S:1302 Unsupported client version CR LF
1.2.3.4
ts1.isp1.com
-- Connection closed -- If the server supports the version sent by the client, then the server sends a list of the capabilities supported for authentication and tunnels. CAPABILITY TUNNEL=V6V4 AUTH=DIGEST-MD5 AUTH=ANONYMOUS CR LF Tunnel types must be registered with IANA and their profiles are defined in other documents. Authentication is done using SASL (RFC2222) [3]. Each authentication mechanism must be a registered SASL mechanism. Description of such mechanism is not in the scope of this document. The Tunnel Client can then choose to close the session if none of the capabilities fits its needs. If the Tunnel Client chooses to continue, it must authenticate itself to the server using one of the adevertised mechanism. If the authentication fails the server sends an error message and closes the session. Example of failed authentication -- Successful TCP Connection -- C:VERSION=0.1 CR LF S:CAPABILITY TUNNEL=V6V4 AUTH=DIGEST-MD5 CR LF C:AUTHENTICATE ANONYMOUS CR LF S:300 Authentication failed CR LF If the authentication succeed, the server sends a success return code and the protocol enter the Command phase. Blanchet, et. al. Expires November 30, 2001 [Page 6] Internet-Draft TSP June 2001 Successful authentication -- Successful TCP Connection -- C:VERSION=0.1 CR LF S:CAPABILITY TUNNEL=V6V4 AUTH=DIGEST-MD5 AUTH=ANONYMOUS CR LF C:AUTHENTICATE ANONYMOUS CR LF S:200 Authentication successful CR LF Upon successful authentication the protocol enters the command phase as described in the next section. 3.4 Command phase The Command phase is where the Tunnel Client send a tunnel request or a tunnel update to the server. In this phase, commands are sent as XML messages. The first line is a "Content-length" directive that tells the size of the following XML message. This makes it easier for protocol implementation to tell when they got the whole XML message. When the server sends a response, the first line is the "Content-length" directive, the second is the return code and third one is the XML message if any. The size of the response for the "Content-length" directive is the first character of the return code line to the last character of the XML message. Spaces can be inserted freely. Blanchet, et. al. Expires November 30, 2001 [Page 7] Internet-Draft TSP June 2001 Example of a command/response sequence -- Successful TCP Connection -- C:VERSION=0.1 CR LF S:CAPABILITY TUNNEL=V6V4 AUTH=DIGEST-MD5 AUTH=ANONYMOUS CR LF C:AUTHENTICATE ANONYMOUS CR LF S:200 Authentication successful CR LF C: Content-length: 123 CR LF
1.1.1.1
CR LF S: Content-length: 234 CR LF 200 OK CR LF
206.123.31.114
3ffe:b00:c18:ffff:0000:0000:0000:0000
1.1.1.1
3ffe:b00:c18:ffff::0000:0000:0000:0001
userid.domain
CR LF -- TCP Connection closed -- 4. Error codes Error codes are sent as a numeric value followed by a text message describing the code. The Tunnel Setup Protocol defines error code numbers 1 through 499 and 1000 through 1499. Profile dependant error codes are defined within the 500 through 999 and 1500 through 1999 range. The predifined values are : 200 Success Successful operation 300 Authentication failed Invalid userid, password or authentication mechanism. Blanchet, et. al. Expires November 30, 2001 [Page 8] Internet-Draft TSP June 2001 301 No more tunnels available The server as reach its capacity limit. 302 Unsupported client version The client version is not supported by the server. 303 Unsupported tunnel type The server does not provide the requested tunnel type. if a list of tunnel servers is following the error code as a referal service, then 1000 is added to the error code. 5. Issues This protocol could be extended to use the Blocks Extensible Exchange Protocol (RFC3080) [5]. 6. IANA Considerations Tunnel types should be assigned by IANA based on a published RFC document. A port number must be assigned for that protocol. 7. Security considerations This protocol does not have encryption. When authenticating clients, SASL provides the necessary mechanism for negociating the authentication mechanism. As stated in SASL, the PLAIN authentication must not be used. The suggested method is DIGEST-MD5 (RFC2831) [4]. Tunnels generate routing entries that may be abused [7], while this is not specific to this TSP protocol 8. Acknowledgements Alain Durand was the author of the seminal idea of tunnel brokers. While researching a way to enhance the function, we were convinced about the need of a control protocol and worked on it. At the same time, Peter Tattam published a proposal on an IETF IPv6 mailing list. This work is a merge between the Tattam's proposal and our own proposal. Jun-Ichiro Itojun Hagino was, as usual, a great helper in refining Blanchet, et. al. Expires November 30, 2001 [Page 9] Internet-Draft TSP June 2001 and commenting this work. This work has been done on a team basis so all people here contributed to the original work: Andre Cormier, Regis Desmeules, Florent Parent, Jocelyn Picard, Guy Turcotte. References [1] Durand, A., Fasano, P., Guardini, I. and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001. [2] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [3] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997. [4] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000. [5] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001. [6] Durand, A., "IPv6 over IPv4 tunnels for home to Internet access method", July 2000. [7] Hagino, J., "Possible abuse against IPv6 transition technologies", July 2000. [8] "MIME-type extension for IPv6 configured tunnels". Authors' Addresses Marc Blanchet Viagenie inc. 2875 boul. Laurier, bureau 300 Sainte-Foy, QC G1V 2M2 Canada Phone: +1 418 656 9254 EMail: Marc.Blanchet@viagenie.qc.ca URI: http://www.viagenie.qc.ca/ Blanchet, et. al. Expires November 30, 2001 [Page 10] Internet-Draft TSP June 2001 Regis Desmeules Viagenie inc. 2875 boul. Laurier, bureau 300 Sainte-Foy, QC G1V 2M2 Canada Phone: +1 418 656 9254 EMail: Regis.Desmeules@viagenie.qc.ca URI: http://www.viagenie.qc.ca/ Andre Cormier Viagenie inc. 2875 boul. Laurier, bureau 300 Sainte-Foy, QC G1V 2M2 Canada Phone: +1 418 656 9254 EMail: Andre.Cormier@viagenie.qc.ca URI: http://www.viagenie.qc.ca/ Appendix A. DTD A DTD should be placed here for the protocol. Blanchet, et. al. Expires November 30, 2001 [Page 11] Internet-Draft TSP June 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.