TCPM WG                                                        J. Touch
Internet Draft                                                  USC/ISI
Expires: October 2006                                    April 14, 2006

                        A TCP Option for Port Names

Status of this Memo

   By submitting this Internet-Draft, each author represents that
   any applicable patent or other IPR claims of which he or she is
   aware have been or will be disclosed, and any of which he or she
   becomes aware will be disclosed, in accordance with Section 6 of
   BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

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

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on October 14, 2006.


   This document specifies a new TCP option that specifies services by a
   string name. This option separates the use of port numbers for
   connection demultiplexing from their use as a service identifier. The
   option allows a larger number of concurrent connections for a
   particular service, as well as potentially enabling more explicitly
   coordination of services behind NATs and firewalls. This option
   should be supported in new TCP implementations.

Touch                  Expires October 14, 2006                [Page 1]

Internet-Draft       A TCP Option for Port Names             April 2006

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119. [RFC2119]

   ">>" precedes all RFC-2119 recommendations, which are listed
   separately at the end of Section 1: Introduction.

Table of Contents

   1. Introduction...................................................2
   2. Motivation.....................................................3
      2.1. IANA Port Numbers.........................................4
      2.2. DNS SRV Records...........................................5
      2.3. RPC Portmapper and RPCBIND................................5
      2.4. TCPMUX....................................................6
      2.5. Summary and Proposal......................................6
   3. The TCP Portname Option........................................8
      3.1. Interactions Between Portnames and Port Numbers...........9
      3.2. Error Conditions.........................................10
      3.3. Backward Compatibility...................................10
   4. Issues........................................................11
      4.1. API Support..............................................11
      4.2. Interaction with Other Protocols.........................11
      4.3. Potential Use in Other Transport Protocols...............13
      4.4. Discussion of Alternative Approaches.....................14
   5. The Portname Name Space.......................................14
   6. Security Considerations.......................................16
   7. IANA Considerations...........................................17
   8. Conclusions...................................................17
   9. Acknowledgments...............................................17
   10. References...................................................18
      10.1. Normative References....................................18
      10.2. Informative References..................................18
   Author's Addresses...............................................20
   Intellectual Property Statement..................................20
   Disclaimer of Validity...........................................21
   Copyright Statement..............................................21

1. Introduction

   Most Internet transport protocols use "well-known" port numbers to
   indicate which application service is associated with a connection or
   message; this includes TCP, UDP, SCTP, and DCCP [RFC768] [RFC793]

Touch                  Expires October 14, 2006                [Page 2]

Internet-Draft       A TCP Option for Port Names             April 2006

   [RFC2960] [RFC4340]. Making a port number well-known involves
   registration with the Internet Assigned Numbers Authority (IANA),
   which includes defining a service by a unique keyword and reserving a
   port number from among a fixed pool [IANA].

   This document specifies the TCP portname option, which allows
   services to be specified by a string. This decouples the use of ports
   for connection demultiplexing and state management from their use to
   indicate a desired endpoint service. It also conserves port numbers
   by allowing endpoints to allocate their own port numbers separately,
   based on services they deploy.

   This option allows a flexible correspondence between services and
   port numbers, which affects how applications interact with TCP, as
   well as how services can be deployed behind NATs and firewalls.
   Although it changes certain TCP segments (SYNs), it does not
   otherwise affect the processing of TCP segments or the TCP state
   machine. The option must be implemented at both ends of a TCP
   connection for benefit. The option affects only the initiator of a
   TCP connection, and fails as if the service were not available when
   not supported at the receiver.

   The following is a summary of the RFC2119-level recommendations of
   this document:


2. Motivation

   TCP supports multiplexing as one of its six core services, allowing a
   single pair of hosts to have multiple concurrent TCP sessions
   [RFC793]. An endpoint address is associated with a port number,
   forming a socket; and "A pair of sockets uniquely identifies each
   connection." Although ports can be bound to services uniquely at each
   endpoint, RFC 793 notes that it is useful to attach frequently-used
   services to fixed ports which are publicly known, but that other
   services may be discovered by dynamic means. This document considers
   the impact of that suggestion, and specifies an alternative which
   achieves similar coordination.

   The Internet currently relies on the use of fixed, publicly-known
   ports for most services, whether intended for public access (e.g.,
   HTTP, FTP, DNS) or for services typically used between pre-arranged
   pairs (e.g., X11, SSL). Some of these services use one public port to
   negotiate other ports for further exchanges (e.g., FTP, H.323, RPC).

Touch                  Expires October 14, 2006                [Page 3]

Internet-Draft       A TCP Option for Port Names             April 2006

   There are three current methods for determining the port for a public

   o  Index the service in IANA's port registry

   o  Index the service in the host's DNS SRV records

   o  Ask the host directly using an RPC portmapper/bind-like service

   o  Ask the host for a hand-off using the TCPMUX port (port #1)

   Many of these alternatives, including the use of strings as service
   identifiers, were described in principle in RFC 814, and have evolved
   into deployed capabilities [RFC814]. Each of these alternatives is
   summarized below, and each either limits the number of concurrent
   connections for a service unnecessarily or incurs additional latency
   or management overhead compared to the portname option presented in
   Section 3.

2.1. IANA Port Numbers

   The Internet Assigned Numbers Authority currently manages globally
   reserved port numbers [IANA]. The desired port number for a service
   is determined either by an operating system index to a copy of IANA's
   table (e.g., getportbyname() in Unix, which indexes the /etc/services
   file), or is fixed in inside the application.

   The port number space - 0..65536 - is split into three ranges

   o  0..1023 "well-known", also called "system" ports

   o  1024..49151 "registered", also called "user" ports

   o  49152..65535 "dynamic", also called "private" ports

   The terms "well-known" and "registered" are misnomers; both of those
   port ranges are managed by IANA, and are equally registered and well-
   known. System ports are intended for services that run in privileged
   mode, sometimes known as "root", although that distinction is blurred
   in current operating systems.

   The larger challenge with IANA-managed ports is that it allocates
   ports globally, for all hosts everywhere on the public Internet, even
   though the meaning of a port need be known only for a particular
   host. As a result, the fixed space of port numbers is being globally
   reserved unnecessarily. It would be more useful to allocate this name

Touch                  Expires October 14, 2006                [Page 4]

Internet-Draft       A TCP Option for Port Names             April 2006

   space on a per-host basis. It is optional whether such a name space
   would retain any of the system/user/dynamic distinctions of the
   current port number space.

2.2. DNS SRV Records

   DNS SRV resource records provide a way to find the port number for a
   service based on its string name [RFC2782]. A host asks the DNS to
   index "_portname_.hostname" (underscores required) and the response
   is a record that includes both the port number and host's IP address.

   SRV records allow port numbers to be allocated on a per-host basis.
   This lookup requires an additional protocol exchange for each first-
   time access, which can traverse much of the same path the TCP SYN
   will, i.e., incurring an additional round-trip time of delay (because
   DNS servers are often located near the hosts they serve).

   The larger challenges for DNS SRV records are autonomy, robustness,
   and size of the name space. Many hosts do not have control over their
   DNS entries; moving port lookup into the DNS could limit the services
   that a host can deploy for public access. This solution also makes
   the DNS a required part of the Internet architecture, even for
   accessing services on hosts with well-known IP addresses (e.g., the
   DNS itself). This decreases network robustness, because access of
   services on a host depends on access to the DNS. A more efficient,
   fate-sharing approach is desired. Finally, DNS SRV records return a
   conventional port, limiting the number of available services on a DNS
   name to 65,536.

2.3. RPC Portmapper and RPCBIND

   An alternative to indexing the portname at a separate host via the
   DNS would be to contact the intended host directly and request the
   lookup there. This is how the RPC portmapper (v2) and RPCBIND (v3 and
   v4) services work, where the source host contacts the destination on
   port #111 [RFC1831][RFC1833]. This service was designed for the same
   basic reason as the TCP portname option of this document: to allow a
   small subset of a potentially large set of services to be dynamically
   bound to a small number of ports. The differences between portmapper
   and RPCBIND are not important here, so they are discussed as a single

   In both portmapper and RPCBIND the source host contacts the
   destination host on port 111, and issues a request including the
   desired destination RPC service name. A response indicates the
   appropriate port for that RPC service.

Touch                  Expires October 14, 2006                [Page 5]

Internet-Draft       A TCP Option for Port Names             April 2006

   Like the DNS SRV solution, portmapper/RPCBIND requires a separate
   round-trip (one for UDP; more for TCP) to perform the lookup
   operation. This adds to both the communication overhead and
   connection establishment latency.

   The portmapper service also allows services to be selected on
   version, i.e., to have different versions of a service on different
   ports, accessed using the same version name but a different version
   number. This is handled in IANA, DNS SRV records, and TCPMUX by using
   a port keyword that embeds the version number in the name, e.g.,
   "imap" vs. "imap3"; the remainder of this document considers this a
   sufficient solution to versioning.


   TCPMUX is a service on TCP port #1 which allows a host to provide a
   port name handoff service for itself [RFC1078]. A source host opens a
   connection to port 1 on a destination host and transmits
   "portname<CR><LF>" in the data stream; the destination replies with
   either "+<CR><LF>" (yes, the service is available) or "-<CR><LF>"
   (no, the service is not available). If the service is available, the
   connection is transferred to the desired service while still in the
   OPEN state.

   TCPMUX modifies the semantics of TCP connection establishment; its
   connections always succeed, and upon receipt of the named service the
   application must determine whether to proceed or not. This document
   seeks a more conventional TCP semantics, where unavailable services
   result in a rejected connection (e.g., RST in reply and/or ICMP error

   TCPMUX further requires all new connections to be received on a
   single port; this limits the number of connections between two
   machines to 65,536; while this is a reasonably high number, it may
   not be appropriate for services with connection-per-transaction

2.5. Summary and Proposal

   Each of the alternatives presented has a significant limitation.
   These limits are summarized as follows:

   o  IANA ports: limited to 65,536 services throughout the Internet;
      fewer if system/user/dynamic boundaries are preserved

Touch                  Expires October 14, 2006                [Page 6]

Internet-Draft       A TCP Option for Port Names             April 2006

   o  DNS SRV records: requires an extra round-trip exchange for lookup,
      not typically under host control, limited to 65,536 services per
      DNS name (fewer if system/user/dynamic boundaries are preserved)

   o  Portmapper: requires an extra round-trip exchange for lookup

   o  TCPMUX: destroys semantics of TCP connection establishment, limits
      services and connections per endpoint pair to 65,536

   The TCP portname option allows the destination host to associate
   named services with processes on a per-connection basis, while
   avoiding unnecessary additional round-trips or connections and while
   also reducing message overhead.

   The basic operation of the portname option is as follows:

   o  The source host issues a SYN, picking both source and destination
      port numbers randomly that are not currently in-use to that

   o  The SYN includes the portname option, which contains the string
      name of the desired service.

   o  The destination host, upon receiving the SYN with the portname
      option, determines whether an available service matching the
      string is running which admits dynamically-bound port pairs. If
      so, a SYN-ACK is issued with a zero-length portname option,
      indicating success of the lookup and handoff. The service is bound
      to that connection at the destination.

   o  If the service is not available, the appropriate RST and/or ICMP
      error messages are returned.

   The benefits to the TCP portname option are that:

   o  The number of services available is no longer limited by 65,536;
      the limit is based solely on the number of unique connections
      between two hosts (i.e., 4,294,967,296)

   o  Portname support is provided at the same host as the intended
      service, so the fate of both is shared (more robust)

   o  The option is embedded in the TCP SYN segment, avoiding extra
      round trips and messages.

   o  TCP connection semantics are maintained, i.e., services not
      available never connect.

Touch                  Expires October 14, 2006                [Page 7]

Internet-Draft       A TCP Option for Port Names             April 2006

3. The TCP Portname Option

   The TCP portname option extends the TCP header to include a string
   indicating the name of a service, as shown in Figure 1.

   >> New implementations of TCP SHOULD implement the portname option.

   >> The TCP portname option MAY appear in any TCP segment, but it
   SHOULD NOT be added any segments except SYNs and SYN-ACKs.

   >> The option MUST be ignored if in any segments except SYNs and SYN-

   The option includes the mandatory KIND and LENGTH fields, as well as
   the string name. The KIND is a single octet (byte) which indicates
   that this option is the TCP portname option. The LENGTH is a single
   octet (byte) interpreted as an unsigned number that indicates the
   length of this option in octets (bytes), including the KIND and
   LENGTH fields, as well as the octets of the name string.

   >> The LENGTH field MUST be greater than or equal to 2.

   The NAMESTRING field is a variable-length UTF-8 string that
   represents the name of a service; for most typical services, this is
   equivalent to a US ASCII string.

   >> The NAMESTRING MAY be of any length that fits in the available TCP
   header space, including zero.

                    |  KIND  | LENGTH |  NAMESTRING
                     Kind    Length

                    Figure 1 TCP portname option format

   Upon receipt of a TCP SYN segment including the portname option ("TCP
   SYN/portname"), the NAMESTRING is matched against a list of available

   >> The NAMESTRING MUST match the service name exactly to consider the
   indexing valid.

   The way in which the portname option and TCP destination port numbers
   interacts is described in Section 3.1.  When an incoming TCP
   SYN/portname is considered valid, the connection is completed by
   returning a SYN-ACK with the TCP portname option.

Touch                  Expires October 14, 2006                [Page 8]

Internet-Draft       A TCP Option for Port Names             April 2006

   >> A TCP SYN-ACK in response to a TCP SYN/portname MUST include a
   null portname option, i.e., with LENGTH=2.

   >> A TCP SYN/portname answered with a TCP SYN with a non-null
   portname option (LENGTH > 2) or lacking the portname option MUST
   cause the initiator to abort the connection via issuing a RST and by
   reporting an error to the application as if the port were not

   The TCB for that connection is then associated with the process for
   the matching service, which then handles all further interactions
   with the connection.

3.1. Interactions Between Portnames and Port Numbers

   TCP currently uses TCP port numbers to demultiplex connections as
   well as to indicate the desired service at the destination. The
   portname option retains the demultiplexing capability, but overrides
   service identification.

   TCP specifies port numbers in the OPEN command, which corresponds to
   Unix bind() and connect() system calls. The current OPEN command is
   described in RFC 793 Sections 2.7 and 3.8 as:

        OPEN (local port, foreign socket, active/passive
           [, timeout] [, precedence] [, security/compartment]
           [, options])
           -> local connection name

   >> The portname option requires the TCP OPEN call to be augmented so
   that the local port and foreign socket parameters include portnames
   as well as port numbers, e.g., "portname.portnumber".

   In specific, this modifies RFC 793 to refer to "port indicator"
   rather than local port or remote port, where a port indicator would
   be the pair "portname.portnumber". In such a port indicator, either
   the portname or portnumber could be indeterminate (e.g., "DNS.*", or
   "*.80". E.g., an incoming connection to port 28 with a portname of
   "DNS" would be interpreted as "DNS.28".

   >> Existing application bind requests to port numbers, in the absence
   of the portname option, MUST be interpreted as if the keyword for
   that port number were prepended to the port number.

   E.g., an application binding to port 80, using no portname option,
   would be equivalent to "HTTP.80". For ports lacking existing
   keywords, the portname is substituted with "UNKNOWN".

Touch                  Expires October 14, 2006                [Page 9]

Internet-Draft       A TCP Option for Port Names             April 2006

   >> An implementation MUST allow applications to bind to a portname on
   a fixed port.

   E.g., an application could bind to port 80 and indicate portname
   "DNS" to bind to "DNS.80".

   >> An implementation MUST allow applications to bind to a portname
   without specifying a fixed port.

   E.g., an application could bind to port INPORT_ANY and indicate
   portname "DNS" to bind to "DNS.INPORT_ANY".

   As with INADDR_ANY, we anticipate that INPORT_ANY will be overridden
   by more specific port identifiers.

3.2. Error Conditions

   There are a number of error conditions for a SYN segment with the
   portname option to be considered:

   o  Invalid NAMESTRING

   o  Invalid service

   o  Invalid port

   In all three cases, the receiving TCP should act as it would if the
   service were not available, i.e., it SHOULD return an ICMP port
   unreachable error message [RFC1122]. This message MUST include the
   received TCP header including the portname option in its entirety.
   The destination TCP MUST also send a RST in response. Other
   interactions are the result of backward compatibility, and are
   discussed in Section 3.3.

3.3. Backward Compatibility

   The TCP portname option is designed to interact correctly only with
   portname-supporting implementations, and will fail to connect with
   non-portname implementations. Applications intended to be compatible
   with both implementations MUST either attempt both portname and non-
   portname connections in parallel or retry a failed portname attempt
   with a non-portname attempt.

   There are two error conditions due to the interaction of TCPs
   supporting the portname option with TCPs which lack that support. In

Touch                  Expires October 14, 2006               [Page 10]

Internet-Draft       A TCP Option for Port Names             April 2006

   o  As per existing RFC793 requirements TCP SYN segments received by a
      non-portname TCP MUST be ignored, and will return a SYN-ACK if any
      service bound to that port. The source TCP will thus receive a
      SYN-ACK without the required null portname option (i.e.,
      LENGTH=2), which will cause the connection attempt to be aborted
      via a RST and an error sent to the application as if the port were

   o  Conventional TCP SYN received by portname TCP: A portname-capable
      TCP MUST allow conventional binding of services to fixed ports.
      TCP SYNs lacking the portname option MUST be handled

4. Issues

   The TCP portname option requires API support, one variant of which is
   informally presented here. The option interacts with some other IP
   and TCP services, notably security services. Variants of the option
   may be useful in other transport protocols. Also, there were a number
   of alternate designs considered which this document captures in

4.1. API Support

   The TCP portname option requires an API to allow a service to bind to
   a port NAMESTRING rather than just a port number. One approach would
   be to extend the existing port number fields to allow the
   "portname.portnumber" format. A simpler approach is to use separate
   commands as follows:

   Use the existing port number indicator command (e.g., Unix bind() or
   connect() calls) to select a specific port number where desired.

   Use the existing socket parameterization command (e.g., Unix
   setsockopt()) to set the portname option, e.g., TCP_PORTNAME).

   We propose to extend the semantics of 'all zeroes' as used to
   indicate floating/dynamically selected IP addresses and port numbers
   to be used for the unspecified port number INPORT_ANY.

4.2. Interaction with Other Protocols

   The TCP portname option potentially interacts with any other protocol
   that interprets or modifies TCP port numbers. This includes IPsec and
   other firewall systems, TCP/MD5 and other TCP security mechanisms,
   FTP and other in-band exchange of ports, and network address
   translators (NATs).

Touch                  Expires October 14, 2006               [Page 11]

Internet-Draft       A TCP Option for Port Names             April 2006

   IPsec uses port numbers to perform access control in transport mode
   [RFC4301].  Security policies can define port-specific access control
   (PROTECT, BYPASS, DISCARD), as well as port-specific algorithms and
   keys. Similarly, firewall policies allow or block traffic based on
   port numbers.

   Use of port numbers in IPsec selectors and firewalls may assume that
   the numbers correspond to well-known services. It is useful to note
   that there is no such requirement; any service may run on any port,
   subject to mutual agreement between the endpoint hosts.  Use of the
   portname option may interfere with this assumption both within IPsec
   and in other firewalling systems, but it does not add a new
   vulnerability. New implementations of IPsec and firewall systems may
   want to interpret the portname option for use in these policy rules,
   but again should not rely on either port numbers or portnames to
   indicate a specific service.

   The TCP portname option occupies space in the TCP SYN segment. Such
   space is severely limited in cases where TCP-level security is
   present, as noted in detail in Section 5.

   >> The portname option MUST be protected in the same way that the
   existing SYN destination port is protected.

   For IPsec, this is not an issue because the entire TCP header and
   payload are protected by all IPsec modes. None of the TCP header is
   protected by application-layer security, e.g., TLS, so again this is
   not an issue [RFC2246].

   The resulting primary concern is TCP-level security, e.g., TCP/MD5
   and its proposed successors [RFC2385] [Bo05] [We06]. TCP/MD5 and
   [We06] exclude TCP options in their hash calculation; this is
   confusing, as it fails to protect current critical TCP options such
   as alternate checksums, window scale, and timestamp options [RFC793]
   [RFC1323]. [Bo05] allows options to be included or excluded,
   depending on a header parameter. This document recommends, as per
   above, that the portname option, as all options, be included in TCP-
   level protection.

   A number of protocols exchange port numbers in-band, notably to
   coordinate separate concurrent connections, e.g., FTP (file transfer)
   and SIP (teleconferencing). Because these protocols coordinate the
   specific port numbers in advance, there is no need for the portname
   option to indicate the desired service. As a result, it is unlikely
   that it would be useful to augment these protocols to support the
   portnames option.

Touch                  Expires October 14, 2006               [Page 12]

Internet-Draft       A TCP Option for Port Names             April 2006

   Network address and port translators, known collectively as NATs, not
   only read TCP ports, but may also translate them [RFC2993]. This
   interferes with the use of ports for service identification
   [RFC3234]. The portname option may allow services to be identified
   behind NATs if NATs are not further extended to translate portname
   options. It is thus unknown whether the portname option will help
   restore service identification in the presence of NATs.

   TCP connections using the portname option continue to use IP
   addresses and ports, although both port numbers are typically set
   arbitrarily. Translation of these ports should not interfere with the
   operation of NATs, though this has not been verified and is not a
   design requirement.

4.3. Potential Use in Other Transport Protocols

   As noted earlier, the portname option may be a useful addition to a
   variety of other transport protocols, such as UDP, SCTP and DCCP
   [RFC768] [RFC2960] [RFC4340]. Adding portname support to SCTP and
   DCCP should be straightforward because both already have an option
   space. These are not addressed further in this document, because this
   focuses on TCP only.

   UDP lacks options, so adding support for portnames is not
   straightforward. One possible approach uses the TCPMUX approach, in
   which the destination port is fixed to a reserved 'portname' port and
   the NAMESTRING and LENGTH appear in the data (Figure 2). The packet
   data is located immediately after the NAMESTRING field.

                     0      7 8     15 16    23 24    31
                    |     Source      |     portname    |
                    |      Port       |      Port       |
                    |   UDP message   |                 |
                    |     Length      |    Checksum     |
                    |        |
                    | LENGTH | NAMESTRING...
                    +---------------- ...

               Figure 2 Potential UDP portname option format

   This possible UDP format is viable because UDP has no connection
   semantics to violate by placing options in the UDP data area. Using a
   fixed portname port limits the number of outstanding UDP messages to
   65,536, but this is less of an issue because UDP has no address/port-

Touch                  Expires October 14, 2006               [Page 13]

Internet-Draft       A TCP Option for Port Names             April 2006

   tuple based semantics; any request/response exchange that uses UDP
   must include its own layer of message identifiers anyway.

4.4. Discussion of Alternative Approaches

   The current proposal assumes that the source TCP selects both source
   and destination port numbers randomly, that the portname option
   occurs only in SYN and SYN-ACKs, and that the binding of connection
   to service happens inside the destination at mapping of TCB-to-
   process. A number of alternative approaches were considered during
   the development of the approach presented herein. These include:

   o  A portmapper-like service that returns a specific port number

   o  Continued demuxing based on the portname option

   o  Dynamic overwriting of the destination port

   The first approach, of returning a specific port number for a
   service, requires a separate round trip and messages to initiate a
   connection. We avoid both the additional time and messages in the
   proposed solution which integrates the lookup in the SYN.

   Continued demultiplexing based on portname would violate TCP
   connection semantics, which indicate that a connection be uniquely
   identified by the 4-tuple: <src addr><src port><dst addr><dst port>.
   Although portname demuxing would increase the connection name space,
   this seems unnecessary as it is already over 4,000,000,000 even
   between a single pair of host addresses. Finally, this variant incurs
   the portname NAMESTRING overhead on every message, which seems
   unnecessarily inefficient. The proposed solution is more efficient
   and sufficiently increases the utility of the entire current
   connection name space.

   Dynamic overwriting of the destination port would allow late-binding
   of the destination port. This complicates the connection
   establishment on the source side, because the SYN-ACK would have a
   different port pair than the SYN. The primary utility for overwriting
   the port number would be to facilitate demultiplexing at the
   receiver, but this is should already include the entire 4-tuple
   anyway. Overall, this variant seems unnecessarily complex for no real

5. The Portname Name Space

   The portname option requires a new portname name space. IANA already
   manages an equivalent space, known as the "keyword" name of a port,

Touch                  Expires October 14, 2006               [Page 14]

Internet-Draft       A TCP Option for Port Names             April 2006

   which is allocated first-come, first-served, and whose strings
   typically already include both the protocol name and version number.
   The portname option is designed to use those same keywords, but
   renders the need for port number allocation unnecessary.

   Portnames need to fit inside the available TCP option space, which
   provides 40 bytes for options. It is useful to consider that TCP SYN
   packets may include other options consuming up to 33 bytes, notably:

   o  16 bytes of authentication [Bo05] [We06] [To06]

   o  4 bytes of MSS

   o  10 bytes of timestamp

   o  3 bytes of windowscale

   This leaves only 7 bytes for the portname option, or 5 bytes for the
   NAMESTRING. This would accommodate only 20% of existing port names,
   as port keywords are currently distributed nearly linearly from 2 to
   15 bytes long as follows:

               100% +---------------------------*-
                90% +                         * *
                80% +                       * * *
                70% +                     * * * *
                60% +                 * * * * * *
                50% +               * * * * * * *
                40% +             * * * * * * * *
                30% +           * * * * * * * * *
                20% +         * * * * * * * * * *
                10% +     * * * * * * * * * * * *
                 0% +-*-*-------------------------
                      0 0 0 0 0 0 0 0 0 1 1 1 1 1
                      1 2 3 4 5 6 7 8 9 0 1 2 3 4

                          Port keyword length

              Figure 3 Distribution of current port keywords

   Note that the most common ports used in the Internet are not
   necessarily those with the shortest names; although HTTP represents
   65% of traffic, services like Gnutella and Napster are also
   nontrivially represented. We note, however, that the use of TCP
   authentication is currently deprecated except for routing
   applications, most of which have short names (e.g., bgp, ldp, msdp).

Touch                  Expires October 14, 2006               [Page 15]

Internet-Draft       A TCP Option for Port Names             April 2006

   When non-TCP authentication is used - e.g., IPsec - the available
   portname name space is over 20 bytes; this accommodates 100% of
   current names, none of which is longer than 15 bytes.

   Portnames MUST be handled as an opaque sequence of bytes; note that
   this includes zero-valued bytes which some systems interpret as "end
   of string" characters". To support human-readable names, portnames
   are represented as UTF-8 [RFC3629].

6. Security Considerations

   There are four areas of security which the portname option raises:

   1. Interaction with IPsec and firewalls

   2. Interaction with TCP/MD5 and other TCP-level security

   3. Increased DOS impact

   The impact on IPsec and firewalls is discussed in detail in Section
   4.2. As noted there, the portname option defeats the assumption that
   port numbers correspond to specific services, an assumption that was
   already defeated between consenting hosts. The portname option raises
   no new vulnerability.

   The impact of the portname option on TCP/MD5 and other TCP-layer
   security services is also discussed in Sections 4.2 and 5. Use of
   these services without inclusion of TCP options makes all options
   vulnerable, including the portname option. Because the portname
   option places the service identifier in this insecure option space,
   it increases TCP's vulnerability. The appropriate solution would be
   to use a TCP-level security that covers options, such as [Bo05]. Use
   of these security options also reduces the space available for the
   portname option, but this affects only for a limited set of routing
   protocols that already have short port keywords, and thus should not
   be an issue.

   The use of strings as port identifiers means that TPC SYN segments
   are longer, requiring more space to buffer while processing. The port
   indexing is a more complex operation, requiring string lookup rather
   than 16-bit indexing. These two aspects cause TCP SYN flooding
   attacks to consume more space and processing resources when the
   portname option is used. Typical SYN flooding mitigations can be used
   here [Ed06]. The additional resources incurred by the portname option
   are minimal, and can be mitigated by separate limits on the rate of
   portname options processed.

Touch                  Expires October 14, 2006               [Page 16]

Internet-Draft       A TCP Option for Port Names             April 2006

7. IANA Considerations

   This document specifies a new TCP option. The KIND for this option
   must be assigned by IANA prior to this document's issuance as an RFC.

   This document requires IANA to manage a new name space of "TCP
   Portnames". This name space should be initially seeded with the
   "keywords" of current TCP ports. This namespace MUST include any UTF-
   8 encoded string. Although the current port keywords are limited to
   15 characters, portnames are limited only by available TCP option

   IANA should allocate a TCP destination port for the portname service,
   to allow applications to bind to that port and then receive on any
   incoming destination port. This is the port space equivalent of
   INADDR_ANY, and is thus called INPORT_ANY; the value "0" is

   [AUTHOR'S NOTE: if the UDP variant is included, the destination port
   should be INPORT_ANY; TCP connections to INPORT_ANY that lack the TCP
   portname option MUST be rejected.]

8. Conclusions

   <to be completed>

9. Acknowledgments

   This work was inspired by discussions on the IETF mailing list,
   notably by suggestions by Keith Moore and Noel Chiappa. Bob Braden
   noted some of the origins of the named service concept.

Touch                  Expires October 14, 2006               [Page 17]

Internet-Draft       A TCP Option for Port Names             April 2006

10. References

10.1. Normative References

   [RFC793]  Postel, J., "Transmission Control Protocol," STD 7, RFC
             793, Sept. 1981 (STANDARD).

   [RFC1122] Braden, R. (ed.), "Requirements for Internet Hosts -
             Communication Layers," STD 3, RFC 1122, Oct. 1989

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997 (BEST
             CURRENT PRACTICE).

   [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
             Signature Option," RFC 2385, Aug. 1998 (PROPOSED STANDARD).

   [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646,"
             STD 63, RFC3629, Nov. 2003 (STANDARD).

10.2. Informative References

   [CAIDA]   CAIDA 2002 workload analysis,

   [IANA]    Internet Assigned Numbers Authority,

   [RFC814]  Clark, D., "NAME, ADDRESSES, PORTS, AND ROUTES," RFC 814,
             July 1982 (UNKNOWN).

   [RFC959]  Postel, J., J. Reynolds, "FILE TRANSFER PROTOCOL (FTP),"
             STD 9, RFC 959, Oct. 1985 (STANDARD).

   [RFC1078] Lottor, M., "TCP Port Service Multiplexer (TCPMUX),"
             RFC1078, Nov. 1988 (UNKNOWN).

   [RFC1323] Jacobson, V., R. Braden, D. Borman, "TCP Extensions for
             High Performance," RFC 1323, May 1992 (PROPOSED STANDARD).

   [RFC1831] Srinivasan, R., "RPC: Remote Procedure Call Protocol
             Specification Version 2," RFC 1078, June 1995 (PROPOSED

   [RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2,"
             RFC 1833, August 1995 (PROPOSED STANDARD).

Touch                  Expires October 14, 2006               [Page 18]

Internet-Draft       A TCP Option for Port Names             April 2006

   [RFC2246] Dierks, T., C. Allen, "The TLS Protocol Version 1.0," RFC
             2246, Jan. 1999 (PROPOSED STANDARD).

   [RFC2780] Bradner, S., V. Paxson, "IANA Allocation Guidelines For
             Values In the Internet Protocol and Related Headers," BCP
             37, RFC 2780, March 2000 (BEST CURRENT PRACTICE).

   [RFC2782] Gulbrandsen, A., P. Vixie, L. Esibov, "A DNS RR for
             specifying the location of services (DNS SRV)," RFC 2782,
             Feb. 2000 (PROPOSED STANDARD).

   [RFC2960] Stewart, R., Q. Xie, K. Morneault, C. Sharp, H.
             Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, V.
             Paxson, "Stream Control Transmission Protocol," RFC 2960,
             Oct. 2000 (PROPOSED STANDARD).

   [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
             November 2000 (INFORMATIONAL).

   [RFC3261] Rosenberg, J., H. Schulzrinne, G. Camarillo, A. Johnston,
             J. Peterson, R. Sparks, M. Handley, E. Schooler, "SIP:
             Session Initiation Protocol," RFC 3261, June 2002 (PROPOSED

   [RFC3424] Daigle, L. and IAB, "IAB Considerations for Unilateral
             Self-Address Fixing (UNSAF) Across Network Address
             Translation", RFC 3424, November 2002 (INFORMATIONAL).

   [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5
             Signature Option," RFC 3562, July 2003(INFORMATIONAL).

   [RFC4278] Bellovin, S., A. Zinin, "Standards Maturity Variance
             Regarding the TCP MD5 Signature Option (RFC 2385) and the
             BGP-4 Specification," RFC 4278, Jan. 2006 (INFORMATIONAL).

   [RFC4301] Kent, S., K. Seo, "Security Architecture for the Internet
             Protocol," RFC4301, Dec. 2005 (PROPOSED STANDARD).

   [RFC4340] Kohler, E., M. Handley, S. Floyd, "Datagram Congestion
             Control Protocol (DCCP)," RFC 4340, Mar. 2006 (PROPOSED

   [Bo06]    Bonica, R., B. Weis, S. Viswanathan, A. Lange, O. Wheeler,
             "Authentication for TCP-based Routing and Management
             Protocols," Feb. 2006 (work in progress).

Touch                  Expires October 14, 2006               [Page 19]

Internet-Draft       A TCP Option for Port Names             April 2006

   [Ed06]    Eddy, W., "TCP SYN Flooding Attacks and Common
             Mitigations," Apr. 2006 (work in progress).

   [We05]    Weis, B., "TCP Message Authentication Code Option," Dec.
             2005(work in progress).

Author's Addresses

   Joe Touch
   4676 Admiralty Way
   Marina del Rey, CA 90292-6695

   Phone: +1 (310) 448-9151

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Touch                  Expires October 14, 2006               [Page 20]

Internet-Draft       A TCP Option for Port Names             April 2006

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Touch                  Expires October 14, 2006               [Page 21]