idnits 2.17.1
draft-vg-ngtrans-tsp-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack separate sections for Informative/Normative
References. All references will be assumed normative when checking for
downward references.
** There are 2 instances of too long lines in the document, the longest one
being 11 characters in excess of 72.
** There are 4 instances of lines with control characters in the document.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 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 1, 2002) is 7971 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)
== Unused Reference: '2' is defined on line 370, but no explicit reference
was found in the text
== Unused Reference: '5' is defined on line 379, but no explicit reference
was found in the text
** Downref: Normative reference to an Informational RFC: RFC 3053 (ref. '1')
** Obsolete normative reference: RFC 2461 (ref. '2') (Obsoleted by RFC 4861)
** Obsolete normative reference: RFC 2222 (ref. '3') (Obsoleted by RFC
4422, RFC 4752)
** Obsolete normative reference: RFC 2831 (ref. '4') (Obsoleted by RFC 6331)
-- Possible downref: Non-RFC (?) normative reference: ref. '5'
-- Possible downref: Non-RFC (?) normative reference: ref. '6'
-- Possible downref: Non-RFC (?) normative reference: ref. '7'
Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group M. Blanchet
3 Internet-Draft Viagenie
4 Expires: December 30, 2002 July 1, 2002
6 Tunnel Setup Protocol (TSP): A Control Protocol to Setup IPv6 or IPv4
7 Tunnels
8 draft-vg-ngtrans-tsp-01
10 Status of this Memo
12 This document is an Internet-Draft and is in full conformance with
13 all provisions of Section 10 of RFC2026.
15 Internet-Drafts are working documents of the Internet Engineering
16 Task Force (IETF), its areas, and its working groups. Note that
17 other groups may also distribute working documents as Internet-
18 Drafts.
20 Internet-Drafts are draft documents valid for a maximum of six months
21 and may be updated, replaced, or obsoleted by other documents at any
22 time. It is inappropriate to use Internet-Drafts as reference
23 material or to cite them other than as "work in progress."
25 The list of current Internet-Drafts can be accessed at http://
26 www.ietf.org/ietf/1id-abstracts.txt.
28 The list of Internet-Draft Shadow Directories can be accessed at
29 http://www.ietf.org/shadow.html.
31 This Internet-Draft will expire on December 30, 2002.
33 Copyright Notice
35 Copyright (C) The Internet Society (2002). All Rights Reserved.
37 Abstract
39 This document proposes a control protocol to setup tunnels between a
40 client and a tunnel server or broker. It provides a framework for
41 the negociation of tunnel parameters between the two entities. It is
42 a generic TCP protocol based on simple XML messaging. This framework
43 protocol enables the negociation of any kind of tunnel, and is
44 extensible to support new parameters or extensions. The first target
45 application is to setup IPv6 over IPv4 tunnels which is one of the
46 transition mechanism identified by the ngtrans and ipv6 working
47 groups. This IPv6 over IPv4 tunnel setup application of the generic
48 TSP protocol is defined by a profile of the TSP protocol, in a
49 companion document.
51 Table of Contents
53 1. Rationale for a tunnel setup protocol . . . . . . . . . . . . 3
54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
55 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 4
56 3.1 Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
57 3.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
58 3.3 Authentication phase . . . . . . . . . . . . . . . . . . . . . 5
59 3.4 Command phase . . . . . . . . . . . . . . . . . . . . . . . . 7
60 4. Error codes . . . . . . . . . . . . . . . . . . . . . . . . . 8
61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
62 6. Security considerations . . . . . . . . . . . . . . . . . . . 9
63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
64 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10
66 A. DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
67 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 11
69 1. Rationale for a tunnel setup protocol
71 Tunnelling techniques are often used to enable new networking
72 functions while still preserving the underlying network as is.
73 Configuring tunnels means handling many static parameters (IP address
74 of the end-points, address or overlay network info), which is a
75 tedious task for a network manager for a large number of tunnels.
76 Some of those parameters may change over time, like the IPv4 address
77 of a client node, which means changing the configuration on the other
78 end.
80 A tunnel broker model (RFC3053) [1] has been defined in the context
81 of IPv6 over IPv4 tunnels, where the tunnel broker enables the use of
82 tunnels from a client using a web interface to tunnel servers.
83 Attempts have been made to generalize the idea using a MIME-type [7],
84 but still no protocol has been defined to enable the negociation of
85 parameters over time for a given tunnel. This draft generalize the
86 concept of the tunnel broker model by having a control protocol
87 between the broker and the client. It enables negociation between
88 the two parties: prefix assignment information, dns delegation,
89 routing information. As another example, a client might request a
90 feature that the server can not provide. In this context, the client
91 may decide to continue anyway without using that feature or the
92 server could send a list of other servers who might offer the service
93 to the client. The control protocol can optionaly be used to verify
94 the sustainability of the underlying network: similar to the PPP
95 control protocols who verify the link and close the connection when
96 the link is down. It also enables the concept of the degenerated
97 case where the broker and the server are together.
99 This framework protocol enables any kind of current and future tunnel
100 techniques to be defined by a profile of this protocol.
102 2. Terminology
104 Tunnel Broker (TB) In a Tunnel Broker model, the broker is taking
105 charge of all communication between Tunnel Servers (TS) and Tunnel
106 Clients (TC). Tunnel clients query brokers for a tunnel and the
107 broker find a suitable tunnel server, ask the Tunnel server to
108 setup the tunnel and send the tunnel information to the Tunnel
109 Client.
111 Tunnel Server (TS) Tunnel Servers are providing the specific tunnel
112 service to a Tunnel Client. It can reveive the tunnel request
113 from a Tunnel Broker (as in the Tunnel Broker model) or directly
114 from the Tunnel Client as in the Tunnel Setup Protocol option.
115 The Tunnel Server is the tunnel end-point.
117 Tunnel Client (TC) The Tunnel Client is the entity that need a tunnel
118 for a particular service or connectivity. A Tunnel Client can be
119 either a host or a router. The tunnel client is the other tunnel
120 end-point.
122 3. Protocol Description
124 3.1 Topology
126 The following diagrams describe typical TSP scenarios. The goal is
127 to establish a tunnel between Tunnel client and Tunnel server.
129 Tunnel Setup Protocol used on Tunnel Broker model
131 _______________
132 | TUNNEL BROKER |--> Databases (dns, whois)
133 | |
134 | TSP TSP |
135 | SERVER CLIENT |
136 |_______________|
137 | |
138 __________ | | ________
139 | | | | | TSP |
140 | TSP |--[TSP]-- +--[TSP]--| SERVER |
141 | CLIENT | | |--[NETWORK]--
142 [HOST]--| |<==[CONFIGURED TUNNEL]==>| TUNNEL |
143 |___________| | SERVER |
144 |________|
146 Tunnel Setup Protocol used on Tunnel Server model
148 ___________ ________
149 | | | TSP |
150 | TSP |-----------[TSP]---------| SERVER |
151 | CLIENT | | |--[NETWORK]--
152 [HOST]--| |<==[CONFIGURED TUNNEL]==>| TUNNEL |
153 |___________| | SERVER |
154 |________|
156 3.2 Overview
158 The Tunnel Setup Protocol has three phases:
160 Authentication phase: The Authentication phase is when the Tunnel
161 Brokers/Servers advertises their capability to Tunnel Clients and
162 when Tunnel clients authenticate to the server.
164 Command phase: The command phase is where the client requests or
165 updates a tunnel.
167 Response phase: The response phase is where the respond to the client
169 For each command sent by a Tunnel Client their is an expected
170 response by the server.
172 3.3 Authentication phase
174 The authentication phase has 3 steps :
176 o Client's protocol version identification
178 o Server's capability advertisement
180 o Client authentication
182 When a TCP session is established to a Tunnel Server, the Tunnel
183 Client sends the current protocol version it is supporting. The
184 version number syntax is:
186 VERSION=1.0 CR LF
188 Version 1.0 is the version number of this specification.
190 If the server doesn't support the protocol version it sends an error
191 message and closes the session. The server can optionally send a
192 server list that may support the protocol version of the client.
194 Example of a Version not supported (without a server list)
196 -- Successful TCP Connection --
197 C:VERSION=0.1 CR LF
198 S:302 Unsupported client version CR LF
199 -- Connection closed --
201 Example of a Version not supported (with a server list)
203 -- Successful TCP Connection --
204 C:VERSION=1.1 CR LF
205 S:1302 Unsupported client version CR LF
206
207
208 1.2.3.4
209
210
211 ts1.isp1.com
212
213
214 -- Connection closed --
216 If the server supports the version sent by the client, then the
217 server sends a list of the capabilities supported for authentication
218 and tunnels.
220 CAPABILITY TUNNEL=V6V4 AUTH=DIGEST-MD5 AUTH=ANONYMOUS CR LF
222 Tunnel types must be registered with IANA and their profiles are
223 defined in other documents. Authentication is done using SASL
224 (RFC2222) [3]. Each authentication mechanism must be a registered
225 SASL mechanism. Description of such mechanism is not in the scope of
226 this document.
228 The Tunnel Client can then choose to close the session if none of the
229 capabilities fits its needs. If the Tunnel Client chooses to
230 continue, it must authenticate itself to the server using one of the
231 adevertised mechanism. If the authentication fails the server sends
232 an error message and closes the session.
234 Example of failed authentication
236 -- Successful TCP Connection --
237 C:VERSION=0.1 CR LF
238 S:CAPABILITY TUNNEL=V6V4 AUTH=DIGEST-MD5 CR LF
239 C:AUTHENTICATE ANONYMOUS CR LF
240 S:300 Authentication failed CR LF
242 If the authentication succeed, the server sends a success return code
243 and the protocol enter the Command phase.
245 Successful authentication
247 -- Successful TCP Connection --
248 C:VERSION=0.1 CR LF
249 S:CAPABILITY TUNNEL=V6V4 AUTH=DIGEST-MD5 AUTH=ANONYMOUS CR LF
250 C:AUTHENTICATE ANONYMOUS CR LF
251 S:200 Authentication successful CR LF
253 Upon successful authentication the protocol enters the command phase
254 as described in the next section.
256 3.4 Command phase
258 The Command phase is where the Tunnel Client send a tunnel request or
259 a tunnel update to the server. In this phase, commands are sent as
260 XML messages. The first line is a "Content-length" directive that
261 tells the size of the following XML message. This makes it easier
262 for protocol implementation to tell when they got the whole XML
263 message. When the server sends a response, the first line is the
264 "Content-length" directive, the second is the return code and third
265 one is the XML message if any. The size of the response for the
266 "Content-length" directive is the first character of the return code
267 line to the last character of the XML message.
269 Spaces can be inserted freely.
271 Example of a command/response sequence
273 -- Successful TCP Connection --
274 C:VERSION=0.1 CR LF
275 S:CAPABILITY TUNNEL=V6V4 AUTH=DIGEST-MD5 AUTH=ANONYMOUS CR LF
276 C:AUTHENTICATE ANONYMOUS CR LF
277 S:200 Authentication successful CR LF
278 C: Content-length: 123 CR LF
279
280
281 1.1.1.1
282
283 CR LF
285 S: Content-length: 234 CR LF
286 200 OK CR LF
287
288
289 206.123.31.114
290 3ffe:b00:c18:ffff:0000:0000:0000:0000
291
292
293 1.1.1.1
294 3ffe:b00:c18:ffff::0000:0000:0000:0001
295 userid.domain
296
297 CR LF
298 -- TCP Connection closed --
300 4. Error codes
302 Error codes are sent as a numeric value followed by a text message
303 describing the code. The Tunnel Setup Protocol defines error code
304 numbers 1 through 499 and 1000 through 1499. Profile dependant error
305 codes are defined within the 500 through 999 and 1500 through 1999
306 range.
308 The predifined values are :
310 200 Success
312 Successful operation
314 300 Authentication failed
316 Invalid userid, password or authentication mechanism.
318 301 No more tunnels available
320 The server as reach its capacity limit.
322 302 Unsupported client version
324 The client version is not supported by the server.
326 303 Unsupported tunnel type
328 The server does not provide the requested tunnel type.
330 if a list of tunnel servers is following the error code as a referal
331 service, then 1000 is added to the error code.
333 5. IANA Considerations
335 Tunnel types should be assigned by IANA based on a published RFC
336 document.
338 A port number must be assigned for that protocol.
340 6. Security considerations
342 This protocol does not have encryption. When authenticating clients,
343 SASL provides the necessary mechanism for negociating the
344 authentication mechanism. As stated in SASL, the PLAIN
345 authentication must not be used. The suggested method is DIGEST-MD5
346 (RFC2831) [4].
348 Tunnels generate routing entries that may be abused [6], while this
349 is not specific to this TSP protocol
351 7. Acknowledgements
353 Alain Durand is the author of the seminal idea of tunnel brokers.
354 This work is a follow-up based on many years of operating the
355 freenet6.net tunnel broker where we saw additional needs for a
356 control protocol to establish the tunnels.
358 Jun-Ichiro Itojun Hagino was, as usual, a great helper in refining
359 and commenting this work.
361 This work has been done on a team basis so all people here
362 contributed to the original work: Andre Cormier, Regis Desmeules,
363 Florent Parent, Jocelyn Picard, Guy Turcotte.
365 References
367 [1] Durand, A., Fasano, P., Guardini, I. and D. Lento, "IPv6 Tunnel
368 Broker", RFC 3053, January 2001.
370 [2] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
371 IP Version 6 (IPv6)", RFC 2461, December 1998.
373 [3] Myers, J., "Simple Authentication and Security Layer (SASL)",
374 RFC 2222, October 1997.
376 [4] Leach, P. and C. Newman, "Using Digest Authentication as a SASL
377 Mechanism", RFC 2831, May 2000.
379 [5] Durand, A., "IPv6 over IPv4 tunnels for home to Internet access
380 method", July 2000.
382 [6] Hagino, J., "Possible abuse against IPv6 transition
383 technologies", July 2000.
385 [7] "MIME-type extension for IPv6 configured tunnels".
387 Author's Address
389 Marc Blanchet
390 Viagenie
391 2875 boul. Laurier, bureau 300
392 Sainte-Foy, QC G1V 2M2
393 Canada
395 Phone: +1 418 656 9254
396 EMail: Marc.Blanchet@viagenie.qc.ca
397 URI: http://www.viagenie.qc.ca/
399 Appendix A. DTD
401 A DTD should be placed here for the protocol.
403 Full Copyright Statement
405 Copyright (C) The Internet Society (2002). All Rights Reserved.
407 This document and translations of it may be copied and furnished to
408 others, and derivative works that comment on or otherwise explain it
409 or assist in its implementation may be prepared, copied, published
410 and distributed, in whole or in part, without restriction of any
411 kind, provided that the above copyright notice and this paragraph are
412 included on all such copies and derivative works. However, this
413 document itself may not be modified in any way, such as by removing
414 the copyright notice or references to the Internet Society or other
415 Internet organizations, except as needed for the purpose of
416 developing Internet standards in which case the procedures for
417 copyrights defined in the Internet Standards process must be
418 followed, or as required to translate it into languages other than
419 English.
421 The limited permissions granted above are perpetual and will not be
422 revoked by the Internet Society or its successors or assigns.
424 This document and the information contained herein is provided on an
425 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
426 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
427 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
428 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
429 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
431 Acknowledgement
433 Funding for the RFC Editor function is currently provided by the
434 Internet Society.