diff options
Diffstat (limited to 'doc/rfc/rfc3620.txt')
| -rw-r--r-- | doc/rfc/rfc3620.txt | 1011 |
1 files changed, 1011 insertions, 0 deletions
diff --git a/doc/rfc/rfc3620.txt b/doc/rfc/rfc3620.txt new file mode 100644 index 0000000..7675e49 --- /dev/null +++ b/doc/rfc/rfc3620.txt @@ -0,0 +1,1011 @@ + + + + + + +Network Working Group D. New +Request for Comments: 3620 October 2003 +Category: Standards Track + + The TUNNEL Profile + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This memo describes a Blocks Extensible Exchange Protocol (BEEP) + profile that allows a BEEP peer to serve as an application-layer + proxy. It allows authorized users to access services through a + firewall. + +Table of Contents + + 1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.1 One-Hop Example. . . . . . . . . . . . . . . . . . . . . . 3 + 2.2 Two-Hop Example. . . . . . . . . . . . . . . . . . . . . . 4 + 2.3 Failed Set-Up Example. . . . . . . . . . . . . . . . . . . 5 + 2.4 Non-BEEP Example . . . . . . . . . . . . . . . . . . . . . 5 + 2.5 Profile Example. . . . . . . . . . . . . . . . . . . . . . 6 + 2.6 Endpoint Example . . . . . . . . . . . . . . . . . . . . . 8 + 3. Message Syntax. . . . . . . . . . . . . . . . . . . . . . . . 9 + 4. Message Semantics . . . . . . . . . . . . . . . . . . . . . . 10 + 5. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 6. Reply Codes. . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 7. Security Considerations. . . . . . . . . . . . . . . . . . . . 14 + 8. Normative References . . . . . . . . . . . . . . . . . . . . . 15 + A. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 + A.1 Registration: BEEP Profile . . . . . . . . . . . . . . . . 16 + A.2 Registration: A System (Well-Known) TCP + port number for TUNNEL . . . . . . . . . . . . . . . . . . 16 + B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18 + + + +New Standards Track [Page 1] + +RFC 3620 The TUNNEL Profile October 2003 + + +1. Rationale + + The TUNNEL profile provides a mechanism for cooperating BEEP peers to + form an application-layer tunnel. The peers exchange "tunnel" + elements that specify a source route, with the outermost element + being stripped off and used to decide the next hop. The innermost, + empty "tunnel" element tells the final destination that it is, + indeed, the final destination. The term "proxy" is used to refer any + of the BEEP peers other than the initiator and the final destination. + + In one use of this profile, a BEEP peer implementing the TUNNEL + profile is co-resident with a firewall. An initiating machine inside + the firewall makes a connection to the proxy, then ask that proxy to + make a connection to an endpoint outside the firewall. Once this + connection is established, the proxy tells the outside endpoint that + it will be tunneling. If the outside machine agrees, the proxy "gets + out of the way," simply passing octets transparently, and both the + initiating and terminating machines perform a "tuning reset," not + unlike the way starting a TLS negotiation discards cached session + state and starts anew. + + Another use for this profile is to limit connections to outside + servers based on the user identity negotiated via SASL. For example, + a manager may connect to a proxy, authenticate herself with SASL, + then instruct the proxy to tunnel to an information service + restricted to managers. Since each proxy knows the identity of the + next proxy being requested, it can refuse to tunnel connections if + inadequate levels of authorization have been established. It is also + possible to use the TUNNEL profile to anonymize the true source of a + BEEP connection, in much the way a NAT translates IP addresses. + However, detailed discussion of such uses is beyond the scope of this + document. + + Once both endpoint machines are connected, the tunneling proxy + machine does no further interpretation of the data. In particular, + it does not look for any BEEP framing. The two endpoint machines may + therefore negotiate TLS between them, passing certificates + appropriate to the endpoints rather than the proxy, with the + assurance that even the proxy cannot access the information + exchanged. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 [1]. + + + + + + + +New Standards Track [Page 2] + +RFC 3620 The TUNNEL Profile October 2003 + + +2. Examples + + While the semantics described in Section 4 may seem complex, the + results are actually relatively simple. A few examples will show the + operation and use of this profile. In these examples, the machine + attempting to establish the connection is named "initial", while the + intermediate proxies are "proxy1" or "proxy2", and the machine with + the service that "initial" wishes to access is called "final". The + examples also assume that the BEEP framework [2] is implemented on + top of TCP [3], or some other mapping where one transport connection + carries all channels. + +2.1 One-Hop Example + + A simple one-hop connection through a single proxy is illustrated + first. + + initial proxy1 final + ----- xport connect -----> + <------- greeting --------> + --- start TUNNEL [1] ----> + ----- xport connect ------> + <-------- greeting --------> + ---- start TUNNEL [2] ----> + <---------- ok ------------ + <------- ok -------------- [3] + <------------- greeting [4]--------------------------> + + Notes: + + [1] The TUNNEL element looks like this: + <tunnel fqdn='final.example.com' port='604'> + <tunnel/> + </tunnel> + + [2] The TUNNEL element looks like this: + <tunnel/> + + [3] At this point, immediately after sending the <ok/> element, + proxy1 starts passing octets transparently. It continues to do + so until either transport connection is closed, after which it + closes the other. + + [4] This greeting may include the TLS profile, allowing initial and + final to communicate without proxy1 understanding or interfering + without being caught. + + + + + +New Standards Track [Page 3] + +RFC 3620 The TUNNEL Profile October 2003 + + +2.2 Two-Hop Example + + The second example shows the initiator connecting to its proxy, that + proxy connecting to another, and finally that second proxy finding a + service outside. + + initial proxy1 proxy2 final + --- xport connect --> + <---- greeting ------> + --start TUNNEL [1]--> + -- xport connect ---> + <----- greeting -----> + --start TUNNEL [2]--> + --- xport connect ---> + <------- greeting -----> + ---start TUNNEL [3]---> + <-------- ok ---------- + <------- ok --------- [4] + <------- ok --------- [5] + <-------------------------- greeting ----------------------------> + + Notes: + + [1] The TUNNEL element looks like this: + <tunnel fqdn='proxy2.example.com' port='604'> + <tunnel fqdn='final.example.com' port='10290'> + <tunnel/> + </tunnel> + </tunnel> + + [2] The TUNNEL element looks like this: + <tunnel fqdn='final.example.com' port='10290'> + <tunnel/> + </tunnel> + + [3] The TUNNEL element looks like this: + <tunnel/> + + [4] Proxy2 starts passing octets transparently after sending the + <ok/>. + + [5] Proxy1 starts passing octets transparently after sending the + <ok/>. + + + + + + + + +New Standards Track [Page 4] + +RFC 3620 The TUNNEL Profile October 2003 + + +2.3 Failed Set-Up Example + + The third example shows the initiator connecting through two proxys, + the second proxy attempting to connect to the specified service and + finding the destination is not a BEEP server. (Of course, specifying + the telnet service can be expected to lead to this error.) The same + would result if the destination did not support the TUNNEL profile. + + initial proxy1 proxy2 final + --- xport connect --> + <---- greeting ------> + --start TUNNEL [1]--> + --- xport connect --> + <----- greeting -----> + --start TUNNEL [2]--> + ---- xport connect ---> + <------- login: ------- + ----- xport close ----> + <---- <error> ------- + --- xport close ----> + <---- <error> ------ + --- xport close ---> [3] + + Notes: + + [1] The TUNNEL element looks like this: + <tunnel fqdn='proxy2.example.com' port='604'> + <tunnel fqdn='final.example.com' srv='_telnet._tcp'> + <tunnel/> + </tunnel> + </tunnel> + + [2] The TUNNEL element looks like this: + <tunnel fqdn='final.example.com' srv='_telnet._tcp'> + <tunnel/> + </tunnel> + + [3] This close is optional. "Initial" may also send another <tunnel> + element, attempting to contact a different server, for example. + +2.4 Non-BEEP Example + + This example shows the initiator connecting through two proxys, the + second proxy attempting to connect to the specified service and + accepting that the destination is not a BEEP server. The difference + at the protocol level is two-fold: The "initial" machine does not + include the innermost "tunnel" element, and the final proxy + ("proxy2") therefore does not expect a BEEP greeting. + + + +New Standards Track [Page 5] + +RFC 3620 The TUNNEL Profile October 2003 + + + initial proxy1 proxy2 final + --- xport connect --> + <---- greeting ------> + --start TUNNEL [1]--> + --- xport connect --> + <----- greeting -----> + --start TUNNEL [2]--> + ---- xport connect ---> + <------- login: ------- + <------ <ok> ------- [3] + <----- login: ------ [4] + <------ <ok> --------- [3] + <----- login: -------- [4] [5] + + Notes: + + [1] The TUNNEL element looks like this: + <tunnel fqdn='proxy2.example.com' port='604'> + <tunnel fqdn='final.example.com' svc='_telnet._tcp'> + </tunnel> + </tunnel> + Note the lack of an innermost no-attribute <tunnel> element. + + [2] The TUNNEL element looks like this: + <tunnel fqdn='final.example.com' srv='_telnet._tcp'> + </tunnel> + Note the lack of an innermost no-attribute <tunnel> element. + + [3] Each proxy starts transparently forwarding octets after this + <ok>. + + [4] Each proxy forwards any data it received from the final host, + even if that data arrived before the <ok> was sent. + + [5] After receiving the "ok" message, the "initial" peer can expect + raw, non-BEEP data to be sent to and received from the "final" + machine. + +2.5 Profile Example + + This example shows the initiator connecting through two proxys. The + initial machine knows there is a server offering the SEP2 profile + somewhere beyond proxy1, but it need not know where. Proxy1 has been + locally configured to know that all SEP2 servers are beyond proxy2. + Proxy2 has been locally configured to chose "final" as the server of + choice for SEP2 services. Note that "final" does not necessarily + need to offer the requested profile in its initial greeting. + + + + +New Standards Track [Page 6] + +RFC 3620 The TUNNEL Profile October 2003 + + + initial proxy1 proxy2 final + --- xport connect --> + <---- greeting ------> + --start TUNNEL [1]--> + -- xport connect ---> + <----- greeting -----> + --start TUNNEL [2]--> + --- xport connect ---> + <------- greeting -----> + ---start TUNNEL [3]---> + <-------- ok ---------- + <------- ok --------- [4] + <------- ok --------- [5] + <-------------------------- greeting ----------------------------> + + Notes: + + [1] The TUNNEL element looks like this: + <tunnel profile="http://xml.resource/org/profiles/SEP2"/> + Note the lack of an innermost no-attribute <tunnel> element. + + [2] Proxy1 maps this to + <tunnel fqdn="proxy2.example.com" port="604"> + <tunnel profile="http://xml.resource/org/profiles/SEP2"/> + </tunnel> + based on local configuration, then processes the new + element, stripping off the outer element and routing + <tunnel profile="http://xml.resource/org/profiles/SEP2"/> + to proxy2. + + [3] Proxy2 receives the TUNNEL element with simply the SEP2 + URI specified. Local provisioning maps this to + <tunnel fqdn='final.example.com' srv='_beep._tcp'> + <tunnel/> + </tunnel> + Note the presence of an innermost no-attribute <tunnel> element. + Proxy2 then strips the outermost element, looking up the + appropriate address and port, and forwards the <tunnel/> + element to the final machine. + + [4] Proxy2 starts transparently forwarding octets after this <ok>. + + [5] Proxy1 starts transparently forwarding octets after this <ok>. + + + + + + + + +New Standards Track [Page 7] + +RFC 3620 The TUNNEL Profile October 2003 + + +2.6 Endpoint Example + + This example shows the initiator connecting through two proxys. The + initial machine knows there is a server known as "operator console" + somewhere beyond proxy1, but it needs not know where. Proxy1 has + been locally configured to know that "operator console" is beyond + proxy2. Proxy2 has been locally configured to use "final" as + "operator console". This example is almost identical to the previous + example, except that "endpoint" is intended to route to a particular + server, while "profile" is intended to route to a particular service. + Otherwise, these two attributes are very similar. + + initial proxy1 proxy2 final + --- xport connect --> + <---- greeting ------> + --start TUNNEL [1]--> + -- xport connect ---> + <----- greeting -----> + --start TUNNEL [2]--> + --- xport connect ---> + <------- greeting -----> + ---start TUNNEL [3]---> + <-------- ok ---------- + <------- ok --------- [4] + <------- ok --------- [5] + <-------------------------- greeting ----------------------------> + + Notes: + + [1] The TUNNEL element looks like this: + <tunnel endpoint="operator console"> + </tunnel> + Note the lack of an innermost no-attribute <tunnel> element. + + [2] Proxy1 maps this to + <tunnel fqdn="proxy2.example.com" port="604"> + <tunnel endpoint="operator console"> + </tunnel> + </tunnel> + based on local configuration, then processes the new + element, stripping off the outer element and routing + <tunnel endpoint="operator console"> + </tunnel> + to proxy2. + + + + + + + +New Standards Track [Page 8] + +RFC 3620 The TUNNEL Profile October 2003 + + + [3] Proxy2 receives the TUNNEL element with simply the endpoint + specified. Local provisioning maps this to + <tunnel fqdn='final.example.com' srv='_beep._tcp'> + <tunnel/> + </tunnel> + Note the presence of an innermost no-attribute <tunnel> element. + Proxy2 then strips the outermost element, looking up the + appropriate address and port, and forwards the <tunnel/> + element to the final machine. + + [4] Proxy2 starts transparently forwarding octets after this <ok>. + + [5] Proxy1 starts transparently forwarding octets after this <ok>. + +3. Message Syntax + + The only element defined in this profile is the "tunnel" element. It + is described in the following DTD, with additional limitations as + described afterwards. + + <!-- + DTD for the TUNNEL Profile, as of 2001-02-03 + + Refer to this DTD as: + + <!ENTITY % TUNNEL PUBLIC "-//IETF//DTD TUNNEL//EN" ""> + %TUNNEL; + --> + + <!-- + TUNNEL messages + + role MSG RPY + ====== === === + I or L TUNNEL +: ok + -: error + --> + + <!ELEMENT tunnel (tunnel?)> + <!ATTLIST tunnel + fqdn CDATA #IMPLIED + ip4 CDATA #IMPLIED + ip6 CDATA #IMPLIED + port CDATA #IMPLIED + srv CDATA #IMPLIED + profile CDATA #IMPLIED + endpoint CDATA #IMPLIED + > + + + +New Standards Track [Page 9] + +RFC 3620 The TUNNEL Profile October 2003 + + + The format of the "fqdn" attribute is a fully qualified domain name, + such as "proxy.example.com". The format of the "ip4" attribute is + four sets of decimal numbers separated by periods, such as + "10.23.34.45". The format of the "ip6" attribute is as specified in + RFC2373 [4]. The format of the "port" attribute is a decimal number + between one and 65535, inclusive. The format of the "srv" attribute + is a pair of identifiers each starting with an underline and + separated by a period, such as "_sep._tcp". The format of the + "profile" attribute is a URI [5]. The format of the "endpoint" + attribute is any string that may appear as an attribute value. + + The only allowable combinations of attributes are as follows: + + o fqdn + port; + + o fqdn + srv; + + o fqdn + srv + port; + + o ip4 + port; + + o ip6 + port; + + o profile, but only on the innermost element; + + o endpoint, but only on the innermost element; or, + + o no attributes, but only on the innermost element. + +4. Message Semantics + + When a TUNNEL channel is started, the listener expects a "tunnel" + element from the initiator, either in the "start" element on channel + zero or on the new channel created. As usual, if it arrives on + channel zero, it is processed before the reply is returned. + + In either case, the outermost "tunnel" element is examined. If it + has no attributes, then this peer is hosting the BEEP service that + the initiator wishes to use. In this case, the listener performs a + tuning reset: + + o All channels, including channel zero, are implicitly closed. + + o Any previously cached information about the BEEP session is + discarded. + + o A new plaintext greeting is sent. + + + + +New Standards Track [Page 10] + +RFC 3620 The TUNNEL Profile October 2003 + + + If the outermost element has a "port" attribute and an "fqdn" + attribute but no "srv" attribute, then "fqdn" is looked up as an A + record via DNS for translation to an IP number. An "ip4" attribute + is interpreted as the dotted-quad representation of an IPv4 address. + An "ip6" attribute is interpreted as a text representation of an IPv6 + address. In each of these cases, a transport connection is + established to the so-identified server. If the outermost element + has a "srv" attribute, the concatenation of the "srv" attribute and + the "fqdn" attribute (with a period between) is looked up in the DNS + for a SRV record [6], and the appropriate server is contacted; if + that lookup fails and a "port" attribute is present, the connection + is attempted as if the "srv" attribute were not specified. + + Alternately, if the outermost element has a "profile" attribute, then + it must have no nested elements. The proxy processing this element + is responsible for determining the appropriate routing to reach a + peer serving the BEEP profile indicated by the URI in the attribute's + value. Rather than source routing, this provides a hop-by-hop + routing mechanism to a desired service. + + Similarly, if the outermost element has an "endpoint" attribute, then + it must have no nested elements. The proxy processing this element + is responsible for determining the appropriate routing to reach a + peer indicated by the value of the "endpoint" attribute. Rather than + source routing, this provides a hop-by-hop routing mechanism to a + desired machine. There are no restrictions on how machines are + identified. + + Then, if the outermost element has no nested elements, but it does + have attributes other than "profile" or "endpoint", then this peer is + the final BEEP hop. (This corresponds to "proxy2" in the "Non-BEEP" + example above.) In this case, as soon as the final underlying + transport connection is established, an "ok" element is returned over + the listening session, and the tunneling of data starts. No BEEP + greeting (or indeed any data) from the final hop is expected. + Starting with the octet following the END(CR)(LF) trailer of the + frame with the completion flag set (more=".") of the RPY carrying the + "ok" element, the proxy begins copying octets directly and without + any interpretation between the two underlying transport connections. + + If the identified server cannot be contacted, an "error" element is + returned over the listening channel and any connection established as + an initiator is closed. If there is a nested "tunnel" element, and + the server that has been contacted does not offer a BEEP greeting, or + the BEEP greeting offered does not include the TUNNEL profile, then + this too is treated as an error: the initiating transport connection + is closed, and an error is returned. + + + + +New Standards Track [Page 11] + +RFC 3620 The TUNNEL Profile October 2003 + + + If there is a nested "tunnel" element, and the identified server is + contacted and offers a BEEP greeting including the TUNNEL profile, + then the outermost element from the "tunnel" element received is + stripped off, a new TUNNEL channel is started on the initiating + session, and the stripped (inner) element is sent to start the next + hop. In this case, the peer is considered a "proxy" (meaning that + the next paragraph is applicable). + + Once the proxy has passed the "tunnel" element on the TUNNEL channel, + it awaits an "error" or an "ok" element in response. If it receives + an "error" element, it closes the initiated session and its + underlying transport connection. It then passes the "error" element + unchanged back on the listening session. If, on the other hand, it + receives an "ok" element, it passes the "ok" element back on the + listening session. Starting with the octet following the END(CR)(LF) + trailer of the frame with the completion flag set (more=".") of the + RPY carrying the "ok" element, the proxy begins copying octets + directly and without any interpretation between the two underlying + transport connections. + +5. Provisioning + + While the BEEP Framework [2] is used, the attributes described are + sufficient for the TCP mapping [3] of BEEP. The attributes on the + "tunnel" element may need to be extended to handle other transport + layers. + + In a mapping where multiple underlying transport connections are + used, once the "ok" element is passed, all channels are closed, + including channel zero. Thus, only the underlying transport + connection initially established remains, and all other underlying + transport connections for the session should be closed as well. + + If a transport security layer (such as TLS) has been negotiated over + the session, the semantics for the TUNNEL profile are ill-defined. + The TUNNEL profile MUST NOT be advertised in any greetings after + transport security has been negotiated. + + An SRV identifier of "_tunnel" is reserved by IANA for use with this + profile. Hence, the "srv" attribute "_tunnel._tcp" MAY be used as a + default for finding the appropriate address for tunneling into a + particular domain. + + System port number 604 has been allocated by the IANA for TUNNEL. + + + + + + + +New Standards Track [Page 12] + +RFC 3620 The TUNNEL Profile October 2003 + + +6. Reply Codes + + This section lists the three-digit error codes the TUNNEL profile may + generate. + + code meaning + ==== ======= + 421 Service not available + (E.g., the proxy does not have sufficient resources.) + + 450 Requested action not taken + (E.g., DNS lookup failed or connection could not + be established. See too 550.) + + 500 General syntax error (E.g., poorly-formed XML) + + 501 Syntax error in parameters + (E.g., non-valid XML, letters in "ip4" attribute, etc.) + + 504 Parameter not implemented + + 530 Authentication required + + 534 Authentication mechanism insufficient + (E.g., too weak, sequence exhausted, etc.) + + 537 Action not authorized for user + + 538 Encryption already enabled + (E.g., TLS already negotiated, or a SASL that + provides encryption already negotiated.) + + 550 Requested action not taken + (E.g., next hop could be contacted, but + malformed greeting or no TUNNEL profile advertised.) + + 553 Parameter invalid + + 554 Transaction failed (E.g., policy violation) + + Note that the 450 error code is appropriate when the destination + machine could not be contacted, while the 550 error code is + appropriate when the destination machine could be contacted but the + next phase of the protocol could not be negotiated. It is suggested + that the beginning of any reply from the destination machine be + included as part of the CDATA text of the error element, for + debugging purposes. + + + + +New Standards Track [Page 13] + +RFC 3620 The TUNNEL Profile October 2003 + + +7. Security Considerations + + The TUNNEL profile is a profile of BEEP. In BEEP, transport + security, user authentication, and data exchange are orthogonal. + Refer to Section 8 of [2] for a discussion of this. + + However, the intent of the TUNNEL profile is to allow bidirectional + contact between two machines normally separated by a firewall. Since + TUNNEL allows this connection between BEEP peers, and BEEP peers can + offer a range of services with appropriate greetings, the TUNNEL + profile should be configured with care. It is reasonable to strictly + limit the hosts and services that a proxy is allowed to contact. It + is also reasonable to limit the use of the TUNNEL profile to + authorized users, as identified by a SASL profile. + + Negotiation of a TLS profile in an end-to-end manner after a TUNNEL + has been established will prevent intermediate proxies from observing + or modifying the cleartext information exchanged, but only if TLS + certificates are properly configured during the negotiation. The + proxy could mount a "man in the middle" attack if public key + infrastructure is not deployed. + + In some environments, it is undesirable to expose the names of + machines on one side of a firewall in unencrypted messages on the + other side of that firewall. In this case, source routing (using the + "fqdn", "ip4", "ip6", "port" and "srv" attributes) can route a + connection to the firewall proxy, with an innermost "profile" or + "endpoint" attribute which the firewall proxy understands. Local + provisioning can allow a proxy to translate a particular "profile" + or "endpoint" element into a new source route to reach the desired + service. This can prevents two attacks: + + o Attackers sniffing packets on one side of the firewall cannot see + IP addresses or FQDNs of machines on the other side of the + firewall; and, + + o Attackers cannot exhaustively attempt to connect to many FQDNs or + IP addresses via source routing and use the error messages as an + indication of whether the queried machine exists. For this attack + to be prevented, the proxy must allow only "profile" or "endpoint" + connections, always refusing to even attempt source-routed + connections. This latter attack can also be thwarted by requiring + a SASL identification before allowing a TUNNEL channel to be + started, but this can have higher overhead. + + + + + + + +New Standards Track [Page 14] + +RFC 3620 The TUNNEL Profile October 2003 + + +8. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC + 3080, March 2001. + + [3] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March + 2001. + + [4] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 2373, July 1998. + + [5] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource + Identifiers (URI): Generic Syntax", RFC 2396, August 1998. + + [6] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for + specifying the location of services (DNS SRV)", RFC 2782, + February 2000. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +New Standards Track [Page 15] + +RFC 3620 The TUNNEL Profile October 2003 + + +Appendix A. IANA Considerations + +A.1 Registration: BEEP Profile + + The IANA has registered the profiles specified in this section and + has selected an IANA-specific URI: "http://iana.org/beep/TUNNEL". + + Profile identification: http://iana.org/beep/TUNNEL + + Message exchanged during channel creation: "tunnel" + + Messages starting one-to-one exchanges: "tunnel" + + Messages in positive replies: "ok" + + Messages in negative replies: "error" + + Messages in one-to-many exchanges: None. + + Message syntax: See Section 3 of this document. + + Message semantics: See Section 4 of this document. + + Contact information: See the Author's Address appendix of this + document. + + Any extensions to this protocol MUST be documented in a Standards + track RFC. + +A.2 Registration: The System (Well-Known) TCP port number for TUNNEL + + A single well-known port, 604, is allocated by the IANA to the TUNNEL + profile. + + Protocol Number: TCP + + Message Formats, Types, Opcodes, and Sequences: See Section 3. + + Functions: See Section 4. + + Use of Broadcast/Multicast: none + + Proposed Name: TUNNEL Profile + + Short name: tunnel + + Contact Information: See the "Authors' Addresses" section of this + memo + + + +New Standards Track [Page 16] + +RFC 3620 The TUNNEL Profile October 2003 + + +Appendix B. Acknowledgements + + The author gratefully acknowledges the contributions of Marshall + Rose, Greg Matthews, and Ben Feinstein. + + Inspiration for this profile comes from the Intrusion Detection + Working Group of the IETF. + +Author's Address + + Darren New + 5390 Caminito Exquisito + San Diego, CA 92130 + US + + Phone: +1 858 350 9733 + EMail: dnew@san.rr.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +New Standards Track [Page 17] + +RFC 3620 The TUNNEL Profile October 2003 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). 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. + + + + + + + + + + + + + + + + + + + +New Standards Track [Page 18] + |