rfc/etsn-01.txt - third_party/nanomsg - Git at Google



 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]




	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]