TCPM WG J. Touch Internet Draft USC/ISI Expires: October 2006 April 14, 2006 A TCP Option for Port Names draft-touch-tcp-portnames-00.txt 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- Drafts. 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 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on October 14, 2006. Abstract 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 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 Acknowledgment...................................................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: >> (TO BE COMPLETED PRIOR TO FINAL SUBMISSION) 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 service: 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 [RFC2780]: 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 example. 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. 2.4. TCPMUX 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" in the data stream; the destination replies with either "+" (yes, the service is available) or "-" (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 message). 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 semantics. 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 destination. 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- ACKs. 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 services. >> 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 available. 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 particular: 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 unreachable. 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 conventionally. 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 summary. 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: . 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 benefit. 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 space. 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 suggested. [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 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 (STANDARD). [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, http://www.caida.org/analysis/workload/byapplication/oc48/ [IANA] Internet Assigned Numbers Authority, www.iana.org [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 STANDARD). [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 STANDARD). [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 STANDARD). [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 USC/ISI 4676 Admiralty Way Marina del Rey, CA 90292-6695 U.S.A. Phone: +1 (310) 448-9151 Email: touch@isi.edu URL: http://www.isi.edu/touch 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 http://www.ietf.org/ipr. 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 ietf-ipr@ietf.org. 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 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Touch Expires October 14, 2006 [Page 21]