idnits 2.17.1
draft-ietf-idwg-beep-tunnel-05.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 :
----------------------------------------------------------------------------
** There are 8 instances of too long lines in the document, the longest one
being 3 characters in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
== Line 175 has weird spacing: '...- xport conne...'
== Line 307 has weird spacing: '...- xport conne...'
== Line 362 has weird spacing: '...- xport conne...'
== Line 581 has weird spacing: '... code mean...'
== Line 632 has weird spacing: '...P peers can...'
-- 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 (December 5, 2002) is 7805 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 2373 (ref. '4') (Obsoleted by RFC 3513)
** Obsolete normative reference: RFC 2396 (ref. '5') (Obsoleted by RFC 3986)
Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group D. New
3 Internet-Draft December 5, 2002
4 Expires: June 5, 2003
6 The TUNNEL Profile
7 draft-ietf-idwg-beep-tunnel-05
9 Status of this Memo
11 This document is an Internet-Draft and is in full conformance with
12 all provisions of Section 10 of RFC2026.
14 Internet-Drafts are working documents of the Internet Engineering
15 Task Force (IETF), its areas, and its working groups. Note that
16 other groups may also distribute working documents as Internet-
17 Drafts.
19 Internet-Drafts are draft documents valid for a maximum of six months
20 and may be updated, replaced, or obsoleted by other documents at any
21 time. It is inappropriate to use Internet-Drafts as reference
22 material or to cite them other than as "work in progress."
24 The list of current Internet-Drafts can be accessed at http://
25 www.ietf.org/ietf/1id-abstracts.txt.
27 The list of Internet-Draft Shadow Directories can be accessed at
28 http://www.ietf.org/shadow.html.
30 This Internet-Draft will expire on June 5, 2003.
32 Copyright Notice
34 Copyright (C) The Internet Society (2002). All Rights Reserved.
36 Abstract
38 This memo describes a BEEP profile that allows a BEEP peer to serve
39 as an application-layer proxy. It allows authorized users to access
40 services through a firewall.
42 Table of Contents
44 1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 3
45 2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
46 2.1 One-Hop Example . . . . . . . . . . . . . . . . . . . . . . . 4
47 2.2 Two-Hop Example . . . . . . . . . . . . . . . . . . . . . . . 5
48 2.3 Failed Set-Up Example . . . . . . . . . . . . . . . . . . . . 6
49 2.4 Non-BEEP Example . . . . . . . . . . . . . . . . . . . . . . . 7
50 2.5 Profile Example . . . . . . . . . . . . . . . . . . . . . . . 8
51 2.6 Endpoint Example . . . . . . . . . . . . . . . . . . . . . . . 9
52 3. Message Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11
53 4. Message Semantics . . . . . . . . . . . . . . . . . . . . . . 13
54 5. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . 15
55 6. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . . . 16
56 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
57 Normative References . . . . . . . . . . . . . . . . . . . . . 18
58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 18
59 A. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
60 A.1 Registration: BEEP Profile . . . . . . . . . . . . . . . . . . 19
61 A.2 Registration: The System (Well-Known) TCP port number for
62 TUNNEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
63 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
64 C. Changes from Previous Version . . . . . . . . . . . . . . . . 22
65 C.1 Changes since -04 . . . . . . . . . . . . . . . . . . . . . . 22
66 C.2 Changes since -03 . . . . . . . . . . . . . . . . . . . . . . 22
67 C.3 Changes since -02 . . . . . . . . . . . . . . . . . . . . . . 22
68 C.4 Changes since -01 . . . . . . . . . . . . . . . . . . . . . . 22
69 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 23
71 1. Rationale
73 The TUNNEL profile provides a mechanism for cooperating BEEP peers to
74 form an application-layer tunnel. The peers exchange "tunnel"
75 elements that specify a source route, with the outermost element
76 being stripped off and used to decide the next hop. The innermost,
77 empty "tunnel" element tells the final destination that it is,
78 indeed, the final destination. The term "proxy" is used to refer any
79 of the BEEP peers other than the initiator and the final destination.
81 In one use of this profile, a BEEP peer implementing the TUNNEL
82 profile is co-resident with a firewall. An initiating machine inside
83 the firewall makes a connection to the proxy, then ask that proxy to
84 make a connection to an endpoint outside the firewall. Once this
85 connection is established, the proxy tells the outside endpoint that
86 it will be tunneling. If the outside machine agrees, the proxy "gets
87 out of the way," simply passing octets transparently, and both the
88 initiating and terminating machines perform a "tuning reset," not
89 unlike the way starting a TLS negotiation discards cached session
90 state and starts anew.
92 Another use for this profile is to limit connections to outside
93 servers based on the user identity negotiated via SASL. For example,
94 a manager may connect to a proxy, authenticate herself with SASL,
95 then instruct the proxy to tunnel to an information service
96 restricted to managers. Since each proxy knows the identity of the
97 next proxy being requested, it can refuse to tunnel connections if
98 inadequate levels of authorization have been established. It is also
99 possible to use the TUNNEL profile to anonymize the true source of a
100 BEEP connection, in much the way a NAT translates IP addresses.
101 However, detailed discussion of such uses is beyond the scope of this
102 document.
104 Once both endpoint machines are connected, the tunneling proxy
105 machine does no further interpretation of the data. In particular,
106 it does not look for any BEEP framing. The two endpoint machines may
107 therefore negotiate TLS between them, passing certificates
108 appropriate to the endpoints rather than the proxy, with the
109 assurance that even the proxy cannot access the information
110 exchanged.
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 RFC 2119 [1].
116 2. Examples
118 While the semantics described in Section 4 may seem complex, the
119 results are actually relatively simple. A few examples will show the
120 operation and use of this profile. In these examples, the machine
121 attempting to establish the connection is named "initial", while the
122 intermediate proxies are "proxy1" or "proxy2", and the machine with
123 the service that "initial" wishes to access is called "final". The
124 examples also assume that the BEEP framework [2] is implemented on
125 top of TCP [3], or some other mapping where one transport connection
126 carries all channels.
128 2.1 One-Hop Example
130 A simple one-hop connection through a single proxy is illustrated
131 first.
133 initial proxy1 final
134 ----- xport connect ----->
135 <------- greeting -------->
136 --- start TUNNEL [1] ---->
137 ----- xport connect ------>
138 <-------- greeting -------->
139 ---- start TUNNEL [2] ---->
140 <---------- ok ------------
141 <------- ok -------------- [3]
142 <------------- greeting [4]-------------------------->
144 Notes:
145 [1] The TUNNEL element looks like this:
146
147
148
150 [2] The TUNNEL element looks like this:
151
153 [3] At this point, immediately after sending the
154 element, proxy1 starts passing octets transparently.
155 It continues to do so until either transport connection
156 is closed, after which it closes the other.
158 [4] This greeting may include the TLS profile, allowing
159 initial and final to communicate without proxy1
160 understanding or interfering without being caught.
162 2.2 Two-Hop Example
164 The second example shows the initiator connecting to its proxy, that
165 proxy connecting to another, and finally that second proxy finding a
166 service outside.
168 initial proxy1 proxy2 final
169 --- xport connect -->
170 <---- greeting ------>
171 --start TUNNEL [1]-->
172 -- xport connect --->
173 <----- greeting ----->
174 --start TUNNEL [2]-->
175 --- xport connect --->
176 <------- greeting ----->
177 ---start TUNNEL [3]--->
178 <-------- ok ----------
179 <------- ok --------- [4]
180 <------- ok --------- [5]
181 <-------------------------- greeting ---------------------------->
183 Notes:
184 [1] The TUNNEL element looks like this:
185
186
187
188
189
191 [2] The TUNNEL element looks like this:
192
193
194
196 [3] The TUNNEL element looks like this:
197
199 [4] Proxy2 starts passing octets transparently after
200 sending the .
202 [5] Proxy1 starts passing octets transparently after
203 sending the .
205 2.3 Failed Set-Up Example
207 The third example shows the initiator connecting through two proxys,
208 the second proxy attempting to connect to the specified service and
209 finding the destination is not a BEEP server. (Of course, specifying
210 the telnet service can be expected to lead to this error.) The same
211 would result if the destination did not support the TUNNEL profile.
213 initial proxy1 proxy2 final
214 --- xport connect -->
215 <---- greeting ------>
216 --start TUNNEL [1]-->
217 --- xport connect -->
218 <----- greeting ----->
219 --start TUNNEL [2]-->
220 ---- xport connect --->
221 <------- login: -------
222 ----- xport close ---->
223 <---- -------
224 --- xport close ---->
225 <---- ------
226 --- xport close ---> [3]
228 Notes:
229 [1] The TUNNEL element looks like this:
230
231
232
233
234
236 [2] The TUNNEL element looks like this:
237
238
239
241 [3] This close is optional. "Initial" may also send another
242 element, attempting to contact a different
243 server, for example.
245 2.4 Non-BEEP Example
247 This example shows the initiator connecting through two proxys, the
248 second proxy attempting to connect to the specified service and
249 accepting that the destination is not a BEEP server. The difference
250 at the protocol level is two-fold: The "initial" machine does not
251 include the innermost "tunnel" element, and the final proxy
252 ("proxy2") therefore does not expect a BEEP greeting.
254 initial proxy1 proxy2 final
255 --- xport connect -->
256 <---- greeting ------>
257 --start TUNNEL [1]-->
258 --- xport connect -->
259 <----- greeting ----->
260 --start TUNNEL [2]-->
261 ---- xport connect --->
262 <------- login: -------
263 <------ ------- [3]
264 <----- login: ------ [4]
265 <------ --------- [3]
266 <----- login: -------- [4] [5]
268 Notes:
269 [1] The TUNNEL element looks like this:
270
271
272
273
274 Note the lack of an innermost no-attribute element.
276 [2] The TUNNEL element looks like this:
277
278
279 Note the lack of an innermost no-attribute element.
281 [3] Each proxy starts transparently forwarding octets after this .
283 [4] Each proxy forwards any data it received from the final host,
284 even if that data arrived before the was sent.
286 [5] After receiving the "ok" message, the "initial" peer can expect
287 raw, non-BEEP data to be sent to and received from the "final"
288 machine.
290 2.5 Profile Example
292 This example shows the initiator connecting through two proxys. The
293 initial machine knows there is a server offering the SEP2 profile
294 somewhere beyond proxy1, but it need not know where. Proxy1 has been
295 locally configured to know that all SEP2 servers are beyond proxy2.
296 Proxy2 has been locally configured to chose "final" as the server of
297 choice for SEP2 services. Note that "final" does not necessarily
298 need to offer the requested profile in its initial greeting.
300 initial proxy1 proxy2 final
301 --- xport connect -->
302 <---- greeting ------>
303 --start TUNNEL [1]-->
304 -- xport connect --->
305 <----- greeting ----->
306 --start TUNNEL [2]-->
307 --- xport connect --->
308 <------- greeting ----->
309 ---start TUNNEL [3]--->
310 <-------- ok ----------
311 <------- ok --------- [4]
312 <------- ok --------- [5]
313 <-------------------------- greeting ---------------------------->
315 Notes:
316 [1] The TUNNEL element looks like this:
317
318 Note the lack of an innermost no-attribute element.
320 [2] Proxy1 maps this to
321
322
323
324 based on local configuration, then processes the new
325 element, stripping off the outer element and routing
326
327 to proxy2.
329 [3] Proxy2 receives the TUNNEL element with simply the SEP2
330 URI specified. Local provisioning maps this to
331
332
333
334 Note the presence of an innermost no-attribute element.
335 Proxy2 then strips the outermost element, looking up the
336 appropriate address and port, and forwards the
337 element to the final machine.
339 [4] Proxy2 starts transparently forwarding octets after this .
341 [5] Proxy1 starts transparently forwarding octets after this .
343 2.6 Endpoint Example
345 This example shows the initiator connecting through two proxys. The
346 initial machine knows there is a server known as "operator console"
347 somewhere beyond proxy1, but it need not know where. Proxy1 has been
348 locally configured to know that "operator console" is beyond proxy2.
349 Proxy2 has been locally configured to use "final" as "operator
350 console". This example is almost identical to the previous example,
351 except that "endpoint" is intended to route to a particular server,
352 while "profile" is intended to route to a particular service.
353 Otherwise, these two attributes are very similar.
355 initial proxy1 proxy2 final
356 --- xport connect -->
357 <---- greeting ------>
358 --start TUNNEL [1]-->
359 -- xport connect --->
360 <----- greeting ----->
361 --start TUNNEL [2]-->
362 --- xport connect --->
363 <------- greeting ----->
364 ---start TUNNEL [3]--->
365 <-------- ok ----------
366 <------- ok --------- [4]
367 <------- ok --------- [5]
368 <-------------------------- greeting ---------------------------->
370 Notes:
371 [1] The TUNNEL element looks like this:
372
373
374 Note the lack of an innermost no-attribute element.
376 [2] Proxy1 maps this to
377
378
379
380
381 based on local configuration, then processes the new
382 element, stripping off the outer element and routing
383
384
385 to proxy2.
387 [3] Proxy2 receives the TUNNEL element with simply the endpoint
388 specified. Local provisioning maps this to
389
390
391
392 Note the presence of an innermost no-attribute element.
393 Proxy2 then strips the outermost element, looking up the
394 appropriate address and port, and forwards the
395 element to the final machine.
397 [4] Proxy2 starts transparently forwarding octets after this .
399 [5] Proxy1 starts transparently forwarding octets after this .
401 3. Message Syntax
403 The only element defined in this profile is the "tunnel" element. It
404 is described in the following DTD, with additional limitations as
405 described afterwards.
407
417
426
427
437 The format of the "fqdn" attribute is a fully qualified domain name,
438 such as "proxy.example.com". The format of the "ip4" attribute is
439 four sets of decimal numbers separated by periods, such as
440 "10.23.34.45". The format of the "ip6" attribute is as specified in
441 RFC2373 [4]. The format of the "port" attribute is a decimal number
442 between one and 65535, inclusive. The format of the "srv" attribute
443 is a pair of identifiers each starting with an underline and
444 separated by a period, such as "_sep._tcp". The format of the
445 "profile" attribute is a URI [5]. The format of the "endpoint"
446 attribute is any string that may appear as an attribute value.
448 The only allowable combinations of attributes are as follows:
450 o fqdn + port;
452 o fqdn + srv;
454 o fqdn + srv + port;
456 o ip4 + port;
458 o ip6 + port;
460 o profile, but only on the innermost element;
462 o endpoint, but only on the innermost element; or,
464 o no attributes, but only on the innermost element.
466 4. Message Semantics
468 When a TUNNEL channel is started, the listener expects a "tunnel"
469 element from the initiator, either in the "start" element on channel
470 zero or on the new channel created. As usual, if it arrives on
471 channel zero, it is processed before the reply is returned.
473 In either case, the outermost "tunnel" element is examined. If it
474 has no attributes, then this peer is hosting the BEEP service that
475 the initiator wishes to use. In this case, the listener performs a
476 tuning reset:
478 o All channels, including channel zero, are implicitly closed.
480 o Any previously cached information about the BEEP session is
481 discarded.
483 o A new plaintext greeting is sent.
485 If the outermost element has a "port" attribute and an "fqdn"
486 attribute but no "srv" attribute, then "fqdn" is looked up as an A
487 record via DNS, translated to an IP number. An "ip4" attribute is
488 interpreted as the dotted-quad representation of an IPv4 address. An
489 "ip6" attribute is interpreted as a text representation of an IPv6
490 address. In each of these cases, a transport connection is
491 established to the so-identified server. If the outermost element
492 has a "srv" attribute, the concatenation of the "srv" attribute and
493 the "fqdn" attribute (with a period between) is looked up in the DNS
494 for a SRV record [6], and the appropriate server is contacted; if
495 that lookup fails and a "port" attribute is present, the connection
496 is attempted as if the "srv" attribute were not specified.
498 Alternately, if the outermost element has a "profile" attribute, then
499 it must have no nested elements. The proxy processing this element
500 is responsible for determining the appropriate routing to reach a
501 peer serving the BEEP profile indicated by the URI in the attribute's
502 value. Rather than source routing, this provides a hop-by-hop
503 routing mechanism to a desired service.
505 Similarly, if the outermost element has an "endpoint" attribute, then
506 it must have no nested elements. The proxy processing this element
507 is responsible for determining the appropriate routing to reach a
508 peer indicated by the value of the "endpoint" attribute. Rather than
509 source routing, this provides a hop-by-hop routing mechanism to a
510 desired machine. There are no restrictions on how machines are
511 identified.
513 Then, if the outermost element has no nested elements, but it does
514 have attributes other than "profile" or "endpoint", then this peer is
515 the final BEEP hop. (This corresponds to "proxy2" in the "Non-BEEP"
516 example above.) In this case, as soon as the final underlying
517 transport connection is established, an "ok" element is returned over
518 the listening session, and the tunneling of data starts. No BEEP
519 greeting (or indeed any data) from the final hop is expected.
520 Starting with the octet following the END(CR)(LF) trailer of the
521 frame with the completion flag set (more=".") of the RPY carrying the
522 "ok" element, the proxy begins copying octets directly and without
523 any interpretation between the two underlying transport connections.
525 If the identified server cannot be contacted, an "error" element is
526 returned over the listening channel and any connection established as
527 an initiator is closed. If there is a nested "tunnel" element, and
528 the server that has been contacted does not offer a BEEP greeting, or
529 the BEEP greeting offered does not include the TUNNEL profile, then
530 this too is treated as an error: the initiating transport connection
531 is closed, and an error is returned.
533 If there is a nested "tunnel" element, and the identified server is
534 contacted and offers a BEEP greeting including the TUNNEL profile,
535 then the outermost element from the "tunnel" element received is
536 stripped off, a new TUNNEL channel is started on the initiating
537 session, and the stripped (inner) element is sent to start the next
538 hop. In this case, the peer is considered a "proxy" (meaning that
539 the next paragraph is applicable).
541 Once the proxy has passed the "tunnel" element on the TUNNEL channel,
542 it awaits an "error" or an "ok" element in response. If it receives
543 an "error" element, it closes the initiated session and it's
544 underlying transport connection. It then passes the "error" element
545 unchanged back on the listening session. If, on the other hand, it
546 receives an "ok" element, it passes the "ok" element back on the
547 listening session. Starting with the octet following the END(CR)(LF)
548 trailer of the frame with the completion flag set (more=".") of the
549 RPY carrying the "ok" element, the proxyy begins copying octets
550 directly and without any interpretation between the two underlying
551 transport connections.
553 5. Provisioning
555 While the BEEP Framework [2] is used, the attributes described are
556 sufficient for the TCP mapping [3] of BEEP. The attributes on the
557 "tunnel" element may need to be extended to handle other transport
558 layers.
560 In a mapping where multiple underlying transport connections are
561 used, once the "ok" element is passed, all channels are closed,
562 including channel zero. Thus, only the underlying transport
563 connection initially established remains, and all other underlying
564 transport connections for the session should be closed as well.
566 If a transport security layer (such as TLS) has been negotiated over
567 the session, the semantics for the TUNNEL profile are ill-defined.
568 The TUNNEL profile MUST NOT be advertised in any greetings after
569 transport security has been negotiated.
571 An SRV identifier of "_tunnel" is reserved by IANA for use with this
572 profile. Hence, the "srv" attribute "_tunnel._tcp" MAY be used as a
573 default for finding the appropriate address for tunneling into a
574 particular domain.
576 6. Reply Codes
578 This section lists the three-digit error codes the TUNNEL profile may
579 generate.
581 code meaning
582 ==== =======
583 421 Service not available
584 (E.g., the proxy does not have sufficient resources.)
586 450 Requested action not taken
587 (E.g., DNS lookup failed or connection could not
588 be established. See too 550.)
590 500 General syntax error (E.g., poorly-formed XML)
592 501 Syntax error in parameters
593 (E.g., non-valid XML, letters in "ip4" attribute, etc.)
595 504 Parameter not implemented
597 530 Authentication required
599 534 Authentication mechanism insufficient
600 (E.g., too weak, sequence exhausted, etc.)
602 537 Action not authorized for user
604 538 Encryption already enabled
605 (E.g., TLS already negotiated, or a SASL that
606 provides encryption already negotiated.)
608 550 Requested action not taken
609 (E.g., next hop could be contacted, but
610 malformed greeting or no TUNNEL profile advertised.)
612 553 Parameter invalid
614 554 Transaction failed (E.g., policy violation)
616 Note that the 450 error code is appropriate when the destination
617 machine could not be contacted, while the 550 error code is
618 appropriate when the destination machine could be contacted but the
619 next phase of the protocol could not be negotiated. It is suggested
620 that the beginning of any reply from the destination machine be
621 included as part of the CDATA text of the error element, for
622 debugging purposes.
624 7. Security Considerations
626 The TUNNEL profile is a profile of BEEP. In BEEP, transport
627 security, user authentication, and data exchange are orthogonal.
628 Refer to Section 8 of [2] for a discussion of this.
630 However, the intent of the TUNNEL profile is to allow bidirectional
631 contact between two machines normally separated by a firewall. Since
632 TUNNEL allows this connection between BEEP peers, and BEEP peers can
633 offer a range of services with appropriate greetings, the TUNNEL
634 profile should be configured with care. It is reasonable to strictly
635 limit the hosts and services that a proxy is allowed to contact. It
636 is also reasonable to limit the use of the TUNNEL profile to
637 authorized users, as identified by a SASL profile.
639 Negotiation of a TLS profile in an end-to-end manner after a TUNNEL
640 has been established will prevent intermediate proxies from observing
641 or modifying the cleartext information exchanged, but only if TLS
642 certificates are properly configured during the negotiation. The
643 proxy could mount a "man in the middle" attack if public key
644 infrastructure is not deployed.
646 In some environments, it is undesirable to expose the names of
647 machines on one side of a firewall in unencrypted messages on the
648 other side of that firewall. In this case, source routing (using the
649 "fqdn", "ip4", "ip6", "port" and "srv" attributes) can route a
650 connection to the firewall proxy, with an innermost "profile" or
651 "endpoint" attribute which the firewall proxy understands. Local
652 provisioning can allow a proxy to translate a particular "profile"
653 or "endpoint" element into a new source route to reach the desired
654 service. This can prevents two attacks:
656 o Attackers sniffing packets on one side of the firewall cannot see
657 IP addresses or FQDNs of machines on the other side of the
658 firewall; and,
660 o Attackers cannot exhaustively attempt to connect to many FQDNs or
661 IP addresses via source routing and use the error messages as an
662 indication of whether the queried machine exists. For this attack
663 to be prevented, the proxy must allow only "profile" or "endpoint"
664 connections, always refusing to even attempt source-routed
665 connections. This latter attack can also be thwarted by requiring
666 a SASL identification before allowing a TUNNEL channel to be
667 started, but this can have higher overhead.
669 Normative References
671 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
672 Levels", BCP 14, RFC 2119, March 1997.
674 [2] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC
675 3080, March 2001.
677 [3] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March
678 2001.
680 [4] Hinden, R. and S. Deering, "IP Version 6 Addressing
681 Architecture", RFC 2373, July 1998.
683 [5] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
684 Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
686 [6] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
687 specifying the location of services (DNS SRV)", RFC 2782,
688 February 2000.
690 Author's Address
692 Darren New
693 5390 Caminito Exquisito
694 San Diego, CA 92130
695 US
697 Phone: +1 858 350 9733
698 EMail: dnew@san.rr.com
700 Appendix A. IANA Considerations
702 A.1 Registration: BEEP Profile
704 If the IESG approves this memo for publication, then the IANA
705 registers the profiles specified in this section and selects an IANA-
706 specific URI, e.g., "http://iana.org/beep/TUNNEL".
708 Profile identification: http://xml.resource.org/profiles/TUNNEL
710 Message exchanged during channel creation: "tunnel"
712 Messages starting one-to-one exchanges: "tunnel"
714 Messages in positive replies: "ok"
716 Messages in negative replies: "error"
718 Messages in one-to-many exchanges: None.
720 Message syntax: See Section Section 3 of this document.
722 Message semantics: See Section Section 4 of this document.
724 Contact information: See the Author's Address appendix of this
725 document.
727 Any extensions to this protocol MUST be documented in a Standards
728 track RFC."
730 A.2 Registration: The System (Well-Known) TCP port number for TUNNEL
732 A single well-known port is allocated to the TUNNEL profile. Upon
733 allocation, Section 5 will be updated to reflect the correct
734 allocated port.
736 Protocol Number: TCP
738 Message Formats, Types, Opcodes, and Sequences: See Section 3.
740 Functions: See Section 4.
742 Use of Broadcast/Multicast: none
744 Proposed Name: TUNNEL Profile
746 Short name: tunnel
747 Contact Information: See the "Authors' Addresses" section of this
748 memo
750 Appendix B. Acknowledgements
752 The author gratefully acknowledges the contributions of Marshall
753 Rose, Greg Matthews, and Ben Feinstein.
755 Inspiration for this profile comes from the Intrusion Detection
756 Working Group of the IETF.
758 Appendix C. Changes from Previous Version
760 The RFC editor is requested to remove this section and its entry in
761 the table of contents before publication.
763 C.1 Changes since -04
765 Added support for IPv6 address literals.
767 C.2 Changes since -03
769 Added IESG suggested text regarding protocol extensions.
771 C.3 Changes since -02
773 Addition of port number to elements with "srv" since srv is optional.
774 Correction of minor typo's in that area.
776 Renamed "References" section to "Normative References".
778 C.4 Changes since -01
780 Reference to RFC 2119 added.
782 Updated DTD identification headers.
784 Minor typographical changes.
786 Full Copyright Statement
788 Copyright (C) The Internet Society (2002). All Rights Reserved.
790 This document and translations of it may be copied and furnished to
791 others, and derivative works that comment on or otherwise explain it
792 or assist in its implementation may be prepared, copied, published
793 and distributed, in whole or in part, without restriction of any
794 kind, provided that the above copyright notice and this paragraph are
795 included on all such copies and derivative works. However, this
796 document itself may not be modified in any way, such as by removing
797 the copyright notice or references to the Internet Society or other
798 Internet organizations, except as needed for the purpose of
799 developing Internet standards in which case the procedures for
800 copyrights defined in the Internet Standards process must be
801 followed, or as required to translate it into languages other than
802 English.
804 The limited permissions granted above are perpetual and will not be
805 revoked by the Internet Society or its successors or assigns.
807 This document and the information contained herein is provided on an
808 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
809 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
810 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
811 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
812 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
814 Acknowledgement
816 Funding for the RFC Editor function is currently provided by the
817 Internet Society.