| <?xml version="1.0" encoding="US-ASCII"?> |
| <!DOCTYPE rfc SYSTEM "rfc2629.dtd"> |
| |
| <rfc category="info" docName="etsn-01"> |
| |
| <front> |
| |
| <title abbrev="ETSN"> |
| Extended TCP Service Naming |
| </title> |
| |
| <author fullname="Martin Sustrik" initials="M." role="editor" |
| surname="Sustrik"> |
| <organization>GoPivotal Inc.</organization> |
| <address> |
| <email>msustrik@gopivotal.com</email> |
| </address> |
| </author> |
| |
| <date month="August" year="2013" /> |
| |
| <area>Applications</area> |
| <workgroup>Internet Engineering Task Force</workgroup> |
| |
| <keyword>TCP</keyword> |
| <keyword>service</keyword> |
| <keyword>port</keyword> |
| |
| <abstract> |
| <t>This doucment defines a way to extend the TCP service namespace |
| so that arbitrary names can be used instead of TCP ports.</t> |
| </abstract> |
| |
| </front> |
| |
| <middle> |
| |
| <section title = "Introduction"> |
| |
| <t>TCP ports serve double purpose. First, they uniquely identify |
| a TCP connection within the scope of network interface. Second, |
| they serve as symbolic names for network services, for example, |
| port 80 is a symbolic name for HTTP service.</t> |
| |
| <t>While the ports are a fitting solution for the former problem, |
| they are severely lacking in the latter case. Specifically, as |
| we move from generic-purpose IETF-defined and IANA-registered |
| services such as HTTP or SMTP to special-purpose ad hoc services, |
| often limited in use to few computers, a single company or |
| maybe few inter-communicating organisations the port numbers become |
| increasingly insufficient.</t> |
| |
| <t>In the crowded TCP port namespace developers often choose to use port |
| numbers that collide with existing IANA-registered services and even |
| in the cases where they take care to choose unassigned port numbers |
| the ad hoc services tend to collide each with another.</t> |
| |
| <t>To deal with the problem, some applications choose to use |
| ephemeral ports, i.e. port numbers assigned to the application |
| dynamically by the network stack from the pool of port numbers that |
| are not used at the moment.</t> |
| |
| <t>Given that ephemeral ports are not known in advance, this solution |
| requires an additional service to distribute the port numbers to the |
| potential peers and typically results in more complex and brittle |
| systems.</t> |
| |
| <t>Another problem arises if TCP service is shared among different |
| organisations. Ephemeral ports are not an option in that case |
| as the connections have to cross the firewalls. There's no way to open |
| the port in the firewall if it is not known in advance.</t> |
| |
| <t>If, on the other hand, the ports are assigned statically the practice |
| can severely hinder the development as every new service requires |
| opening a new port in the firewall and thus undergoing an approval |
| process that may take months in some organisations.</t> |
| |
| <t>This specification attemps to solve the problem by extending the |
| TCP service namespace to arbitrary strings. At the same time all |
| those services share a single fixed IANA-assigned TCP port number, |
| thus reducing the administrative overhead to one-off opening of a |
| single port in the firewall.</t> |
| |
| </section> |
| |
| <section title = "Connection Initiation"> |
| |
| <t>When new connection is being established, the party initiating the |
| connection connects to TCP port 5908 at given IP address and sends |
| the following protocol header to the peer:</t> |
| |
| <figure> |
| <artwork> |
| +--------------+-----------+--------------+ |
| | version (8b) | size (8b) | service name | |
| +--------------+-----------+--------------+ |
| </artwork> |
| </figure> |
| |
| <t>The first byte is the version of this protocol and MUST be set |
| to 0x01.</t> |
| |
| <t>If the version number is not equal to 0x01 the accepting party MUST |
| close the underlying TCP connection.</t> |
| |
| <t>Second byte is the length of the subsequent service name. Thus, |
| the service names are 0 to 255 bytes long.</t> |
| |
| <t>The assumption here is that namespace of all strings up to 255 bytes |
| long is large enough to prevent service name clashes. On the other |
| hand, 257 bytes (maximum size of the protocol header) is not long |
| enough to be exploited in any kind of DoS attack.</t> |
| |
| <t>Note that the service name may consist of arbitrary bytes and is not |
| restricted to ASCII strings or similar.</t> |
| |
| <t>If the party accepting the connection doesn't receive the entire |
| protocol header within a reasonable time (e.g. 1 second) it SHOULD |
| close the underlying TCP connection. This rule prevents DoS attacks |
| based on opening large number of TCP connections that would linger |
| around and never be handed to the user.</t> |
| |
| <t>After receiving the entire protocol header, the accepting party |
| looks up the service name in its table of available services. |
| If there's no corresponding service registered it MUST close the |
| underlying TCP connection.</t> |
| |
| <t>Finally, if the service name is found in the table, the TCP connection |
| is handed to the process that registered the service name |
| in question.</t> |
| |
| <t>From that point on the connection behaves as an ordinary TCP |
| connection, both with respect to the data transfer and to the |
| connection shutdown.</t> |
| |
| </section> |
| |
| <section anchor="IANA" title="IANA Considerations"> |
| <t>This document requires that a fixed TCP port number is assigned |
| by IANA for extended service naming. For now the specification is |
| using port 5908.</t> |
| </section> |
| |
| <section anchor="Security" title="Security Considerations"> |
| <t>Longer service names may provide some opportunity for DoS attacks, |
| however, by limiting the service name to maximum of 255 bytes, |
| the risk should be negligible.</t> |
| </section> |
| |
| </middle> |
| |
| </rfc> |
| |
