

Internet Engineering Task Force                          M. Sustrik, Ed.
Internet-Draft                                            GoPivotal Inc.
Intended status: Informational                           August 05, 2013
Expires: February 06, 2014


                      Extended TCP Service Naming
                                etsn-01

Abstract

   This doucment defines a way to extend the TCP service namespace so
   that arbitrary names can be used instead of TCP ports.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on February 06, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

1.  Introduction


Sustrik                 Expires February 06, 2014               [Page 1]

Internet-Draft                    ETSN                       August 2013


   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.

   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.

   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.

   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.

   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.

   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.

   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.

   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.

2.  Connection Initiation


Sustrik                 Expires February 06, 2014               [Page 2]

Internet-Draft                    ETSN                       August 2013


   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:

   +--------------+-----------+--------------+
   | version (8b) | size (8b) | service name |
   +--------------+-----------+--------------+


   The first byte is the version of this protocol and MUST be set to
   0x01.

   If the version number is not equal to 0x01 the accepting party MUST
   close the underlying TCP connection.

   Second byte is the length of the subsequent service name.  Thus, the
   service names are 0 to 255 bytes long.

   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.

   Note that the service name may consist of arbitrary bytes and is not
   restricted to ASCII strings or similar.

   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.

   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.

   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.

   From that point on the connection behaves as an ordinary TCP connection,
   both with respect to the data transfer and to the connection
   shutdown.

3.  IANA Considerations


Sustrik                 Expires February 06, 2014               [Page 3]

Internet-Draft                    ETSN                       August 2013


   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.

4.  Security Considerations

   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.

5.  References

Author's Address

   Martin Sustrik (editor)
   GoPivotal Inc.

   Email: msustrik@gopivotal.com


Sustrik                 Expires February 06, 2014               [Page 4]