idnits 2.17.1 draft-touch-tcp-portnames-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 925. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 902. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 909. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 915. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 14, 2006) is 6577 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC768' is mentioned on line 580, but not defined == Missing Reference: 'Bo05' is mentioned on line 734, but not defined == Missing Reference: 'We06' is mentioned on line 665, but not defined == Missing Reference: 'RFC3234' is mentioned on line 565, but not defined == Missing Reference: 'To06' is mentioned on line 665, but not defined == Unused Reference: 'CAIDA' is defined on line 805, but no explicit reference was found in the text == Unused Reference: 'RFC959' is defined on line 813, but no explicit reference was found in the text == Unused Reference: 'RFC3261' is defined on line 848, but no explicit reference was found in the text == Unused Reference: 'RFC3424' is defined on line 853, but no explicit reference was found in the text == Unused Reference: 'RFC3562' is defined on line 857, but no explicit reference was found in the text == Unused Reference: 'RFC4278' is defined on line 860, but no explicit reference was found in the text == Unused Reference: 'Bo06' is defined on line 871, but no explicit reference was found in the text == Unused Reference: 'We05' is defined on line 878, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 1078 (Obsoleted by RFC 7805) -- Obsolete informational reference (is this intentional?): RFC 1323 (Obsoleted by RFC 7323) -- Duplicate reference: RFC1078, mentioned in 'RFC1831', was also mentioned in 'RFC1078'. -- Obsolete informational reference (is this intentional?): RFC 1078 (ref. 'RFC1831') (Obsoleted by RFC 7805) -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) Summary: 5 errors (**), 0 flaws (~~), 15 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TCPM WG J. Touch 2 Internet Draft USC/ISI 3 Expires: October 2006 April 14, 2006 5 A TCP Option for Port Names 6 draft-touch-tcp-portnames-00.txt 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that 11 any applicable patent or other IPR claims of which he or she is 12 aware have been or will be disclosed, and any of which he or she 13 becomes aware will be disclosed, in accordance with Section 6 of 14 BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on October 14, 2006. 34 Abstract 36 This document specifies a new TCP option that specifies services by a 37 string name. This option separates the use of port numbers for 38 connection demultiplexing from their use as a service identifier. The 39 option allows a larger number of concurrent connections for a 40 particular service, as well as potentially enabling more explicitly 41 coordination of services behind NATs and firewalls. This option 42 should be supported in new TCP implementations. 44 Conventions used in this document 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 48 document are to be interpreted as described in RFC 2119. [RFC2119] 50 ">>" precedes all RFC-2119 recommendations, which are listed 51 separately at the end of Section 1: Introduction. 53 Table of Contents 55 1. Introduction...................................................2 56 2. Motivation.....................................................3 57 2.1. IANA Port Numbers.........................................4 58 2.2. DNS SRV Records...........................................5 59 2.3. RPC Portmapper and RPCBIND................................5 60 2.4. TCPMUX....................................................6 61 2.5. Summary and Proposal......................................6 62 3. The TCP Portname Option........................................8 63 3.1. Interactions Between Portnames and Port Numbers...........9 64 3.2. Error Conditions.........................................10 65 3.3. Backward Compatibility...................................10 66 4. Issues........................................................11 67 4.1. API Support..............................................11 68 4.2. Interaction with Other Protocols.........................11 69 4.3. Potential Use in Other Transport Protocols...............13 70 4.4. Discussion of Alternative Approaches.....................14 71 5. The Portname Name Space.......................................14 72 6. Security Considerations.......................................16 73 7. IANA Considerations...........................................17 74 8. Conclusions...................................................17 75 9. Acknowledgments...............................................17 76 10. References...................................................18 77 10.1. Normative References....................................18 78 10.2. Informative References..................................18 79 Author's Addresses...............................................20 80 Intellectual Property Statement..................................20 81 Disclaimer of Validity...........................................21 82 Copyright Statement..............................................21 83 Acknowledgment...................................................21 85 1. Introduction 87 Most Internet transport protocols use "well-known" port numbers to 88 indicate which application service is associated with a connection or 89 message; this includes TCP, UDP, SCTP, and DCCP [RFC768] [RFC793] 91 [RFC2960] [RFC4340]. Making a port number well-known involves 92 registration with the Internet Assigned Numbers Authority (IANA), 93 which includes defining a service by a unique keyword and reserving a 94 port number from among a fixed pool [IANA]. 96 This document specifies the TCP portname option, which allows 97 services to be specified by a string. This decouples the use of ports 98 for connection demultiplexing and state management from their use to 99 indicate a desired endpoint service. It also conserves port numbers 100 by allowing endpoints to allocate their own port numbers separately, 101 based on services they deploy. 103 This option allows a flexible correspondence between services and 104 port numbers, which affects how applications interact with TCP, as 105 well as how services can be deployed behind NATs and firewalls. 106 Although it changes certain TCP segments (SYNs), it does not 107 otherwise affect the processing of TCP segments or the TCP state 108 machine. The option must be implemented at both ends of a TCP 109 connection for benefit. The option affects only the initiator of a 110 TCP connection, and fails as if the service were not available when 111 not supported at the receiver. 113 The following is a summary of the RFC2119-level recommendations of 114 this document: 116 >> (TO BE COMPLETED PRIOR TO FINAL SUBMISSION) 118 2. Motivation 120 TCP supports multiplexing as one of its six core services, allowing a 121 single pair of hosts to have multiple concurrent TCP sessions 122 [RFC793]. An endpoint address is associated with a port number, 123 forming a socket; and "A pair of sockets uniquely identifies each 124 connection." Although ports can be bound to services uniquely at each 125 endpoint, RFC 793 notes that it is useful to attach frequently-used 126 services to fixed ports which are publicly known, but that other 127 services may be discovered by dynamic means. This document considers 128 the impact of that suggestion, and specifies an alternative which 129 achieves similar coordination. 131 The Internet currently relies on the use of fixed, publicly-known 132 ports for most services, whether intended for public access (e.g., 133 HTTP, FTP, DNS) or for services typically used between pre-arranged 134 pairs (e.g., X11, SSL). Some of these services use one public port to 135 negotiate other ports for further exchanges (e.g., FTP, H.323, RPC). 137 There are three current methods for determining the port for a public 138 service: 140 o Index the service in IANA's port registry 142 o Index the service in the host's DNS SRV records 144 o Ask the host directly using an RPC portmapper/bind-like service 146 o Ask the host for a hand-off using the TCPMUX port (port #1) 148 Many of these alternatives, including the use of strings as service 149 identifiers, were described in principle in RFC 814, and have evolved 150 into deployed capabilities [RFC814]. Each of these alternatives is 151 summarized below, and each either limits the number of concurrent 152 connections for a service unnecessarily or incurs additional latency 153 or management overhead compared to the portname option presented in 154 Section 3. 156 2.1. IANA Port Numbers 158 The Internet Assigned Numbers Authority currently manages globally 159 reserved port numbers [IANA]. The desired port number for a service 160 is determined either by an operating system index to a copy of IANA's 161 table (e.g., getportbyname() in Unix, which indexes the /etc/services 162 file), or is fixed in inside the application. 164 The port number space - 0..65536 - is split into three ranges 165 [RFC2780]: 167 o 0..1023 "well-known", also called "system" ports 169 o 1024..49151 "registered", also called "user" ports 171 o 49152..65535 "dynamic", also called "private" ports 173 The terms "well-known" and "registered" are misnomers; both of those 174 port ranges are managed by IANA, and are equally registered and well- 175 known. System ports are intended for services that run in privileged 176 mode, sometimes known as "root", although that distinction is blurred 177 in current operating systems. 179 The larger challenge with IANA-managed ports is that it allocates 180 ports globally, for all hosts everywhere on the public Internet, even 181 though the meaning of a port need be known only for a particular 182 host. As a result, the fixed space of port numbers is being globally 183 reserved unnecessarily. It would be more useful to allocate this name 184 space on a per-host basis. It is optional whether such a name space 185 would retain any of the system/user/dynamic distinctions of the 186 current port number space. 188 2.2. DNS SRV Records 190 DNS SRV resource records provide a way to find the port number for a 191 service based on its string name [RFC2782]. A host asks the DNS to 192 index "_portname_.hostname" (underscores required) and the response 193 is a record that includes both the port number and host's IP address. 195 SRV records allow port numbers to be allocated on a per-host basis. 196 This lookup requires an additional protocol exchange for each first- 197 time access, which can traverse much of the same path the TCP SYN 198 will, i.e., incurring an additional round-trip time of delay (because 199 DNS servers are often located near the hosts they serve). 201 The larger challenges for DNS SRV records are autonomy, robustness, 202 and size of the name space. Many hosts do not have control over their 203 DNS entries; moving port lookup into the DNS could limit the services 204 that a host can deploy for public access. This solution also makes 205 the DNS a required part of the Internet architecture, even for 206 accessing services on hosts with well-known IP addresses (e.g., the 207 DNS itself). This decreases network robustness, because access of 208 services on a host depends on access to the DNS. A more efficient, 209 fate-sharing approach is desired. Finally, DNS SRV records return a 210 conventional port, limiting the number of available services on a DNS 211 name to 65,536. 213 2.3. RPC Portmapper and RPCBIND 215 An alternative to indexing the portname at a separate host via the 216 DNS would be to contact the intended host directly and request the 217 lookup there. This is how the RPC portmapper (v2) and RPCBIND (v3 and 218 v4) services work, where the source host contacts the destination on 219 port #111 [RFC1831][RFC1833]. This service was designed for the same 220 basic reason as the TCP portname option of this document: to allow a 221 small subset of a potentially large set of services to be dynamically 222 bound to a small number of ports. The differences between portmapper 223 and RPCBIND are not important here, so they are discussed as a single 224 example. 226 In both portmapper and RPCBIND the source host contacts the 227 destination host on port 111, and issues a request including the 228 desired destination RPC service name. A response indicates the 229 appropriate port for that RPC service. 231 Like the DNS SRV solution, portmapper/RPCBIND requires a separate 232 round-trip (one for UDP; more for TCP) to perform the lookup 233 operation. This adds to both the communication overhead and 234 connection establishment latency. 236 The portmapper service also allows services to be selected on 237 version, i.e., to have different versions of a service on different 238 ports, accessed using the same version name but a different version 239 number. This is handled in IANA, DNS SRV records, and TCPMUX by using 240 a port keyword that embeds the version number in the name, e.g., 241 "imap" vs. "imap3"; the remainder of this document considers this a 242 sufficient solution to versioning. 244 2.4. TCPMUX 246 TCPMUX is a service on TCP port #1 which allows a host to provide a 247 port name handoff service for itself [RFC1078]. A source host opens a 248 connection to port 1 on a destination host and transmits 249 "portname" in the data stream; the destination replies with 250 either "+" (yes, the service is available) or "-" 251 (no, the service is not available). If the service is available, the 252 connection is transferred to the desired service while still in the 253 OPEN state. 255 TCPMUX modifies the semantics of TCP connection establishment; its 256 connections always succeed, and upon receipt of the named service the 257 application must determine whether to proceed or not. This document 258 seeks a more conventional TCP semantics, where unavailable services 259 result in a rejected connection (e.g., RST in reply and/or ICMP error 260 message). 262 TCPMUX further requires all new connections to be received on a 263 single port; this limits the number of connections between two 264 machines to 65,536; while this is a reasonably high number, it may 265 not be appropriate for services with connection-per-transaction 266 semantics. 268 2.5. Summary and Proposal 270 Each of the alternatives presented has a significant limitation. 271 These limits are summarized as follows: 273 o IANA ports: limited to 65,536 services throughout the Internet; 274 fewer if system/user/dynamic boundaries are preserved 276 o DNS SRV records: requires an extra round-trip exchange for lookup, 277 not typically under host control, limited to 65,536 services per 278 DNS name (fewer if system/user/dynamic boundaries are preserved) 280 o Portmapper: requires an extra round-trip exchange for lookup 282 o TCPMUX: destroys semantics of TCP connection establishment, limits 283 services and connections per endpoint pair to 65,536 285 The TCP portname option allows the destination host to associate 286 named services with processes on a per-connection basis, while 287 avoiding unnecessary additional round-trips or connections and while 288 also reducing message overhead. 290 The basic operation of the portname option is as follows: 292 o The source host issues a SYN, picking both source and destination 293 port numbers randomly that are not currently in-use to that 294 destination. 296 o The SYN includes the portname option, which contains the string 297 name of the desired service. 299 o The destination host, upon receiving the SYN with the portname 300 option, determines whether an available service matching the 301 string is running which admits dynamically-bound port pairs. If 302 so, a SYN-ACK is issued with a zero-length portname option, 303 indicating success of the lookup and handoff. The service is bound 304 to that connection at the destination. 306 o If the service is not available, the appropriate RST and/or ICMP 307 error messages are returned. 309 The benefits to the TCP portname option are that: 311 o The number of services available is no longer limited by 65,536; 312 the limit is based solely on the number of unique connections 313 between two hosts (i.e., 4,294,967,296) 315 o Portname support is provided at the same host as the intended 316 service, so the fate of both is shared (more robust) 318 o The option is embedded in the TCP SYN segment, avoiding extra 319 round trips and messages. 321 o TCP connection semantics are maintained, i.e., services not 322 available never connect. 324 3. The TCP Portname Option 326 The TCP portname option extends the TCP header to include a string 327 indicating the name of a service, as shown in Figure 1. 329 >> New implementations of TCP SHOULD implement the portname option. 331 >> The TCP portname option MAY appear in any TCP segment, but it 332 SHOULD NOT be added any segments except SYNs and SYN-ACKs. 334 >> The option MUST be ignored if in any segments except SYNs and SYN- 335 ACKs. 337 The option includes the mandatory KIND and LENGTH fields, as well as 338 the string name. The KIND is a single octet (byte) which indicates 339 that this option is the TCP portname option. The LENGTH is a single 340 octet (byte) interpreted as an unsigned number that indicates the 341 length of this option in octets (bytes), including the KIND and 342 LENGTH fields, as well as the octets of the name string. 344 >> The LENGTH field MUST be greater than or equal to 2. 346 The NAMESTRING field is a variable-length UTF-8 string that 347 represents the name of a service; for most typical services, this is 348 equivalent to a US ASCII string. 350 >> The NAMESTRING MAY be of any length that fits in the available TCP 351 header space, including zero. 353 +--------+--------+------... 354 | KIND | LENGTH | NAMESTRING 355 +--------+--------+------... 356 Kind Length 358 Figure 1 TCP portname option format 360 Upon receipt of a TCP SYN segment including the portname option ("TCP 361 SYN/portname"), the NAMESTRING is matched against a list of available 362 services. 364 >> The NAMESTRING MUST match the service name exactly to consider the 365 indexing valid. 367 The way in which the portname option and TCP destination port numbers 368 interacts is described in Section 3.1. When an incoming TCP 369 SYN/portname is considered valid, the connection is completed by 370 returning a SYN-ACK with the TCP portname option. 372 >> A TCP SYN-ACK in response to a TCP SYN/portname MUST include a 373 null portname option, i.e., with LENGTH=2. 375 >> A TCP SYN/portname answered with a TCP SYN with a non-null 376 portname option (LENGTH > 2) or lacking the portname option MUST 377 cause the initiator to abort the connection via issuing a RST and by 378 reporting an error to the application as if the port were not 379 available. 381 The TCB for that connection is then associated with the process for 382 the matching service, which then handles all further interactions 383 with the connection. 385 3.1. Interactions Between Portnames and Port Numbers 387 TCP currently uses TCP port numbers to demultiplex connections as 388 well as to indicate the desired service at the destination. The 389 portname option retains the demultiplexing capability, but overrides 390 service identification. 392 TCP specifies port numbers in the OPEN command, which corresponds to 393 Unix bind() and connect() system calls. The current OPEN command is 394 described in RFC 793 Sections 2.7 and 3.8 as: 396 OPEN (local port, foreign socket, active/passive 397 [, timeout] [, precedence] [, security/compartment] 398 [, options]) 399 -> local connection name 401 >> The portname option requires the TCP OPEN call to be augmented so 402 that the local port and foreign socket parameters include portnames 403 as well as port numbers, e.g., "portname.portnumber". 405 In specific, this modifies RFC 793 to refer to "port indicator" 406 rather than local port or remote port, where a port indicator would 407 be the pair "portname.portnumber". In such a port indicator, either 408 the portname or portnumber could be indeterminate (e.g., "DNS.*", or 409 "*.80". E.g., an incoming connection to port 28 with a portname of 410 "DNS" would be interpreted as "DNS.28". 412 >> Existing application bind requests to port numbers, in the absence 413 of the portname option, MUST be interpreted as if the keyword for 414 that port number were prepended to the port number. 416 E.g., an application binding to port 80, using no portname option, 417 would be equivalent to "HTTP.80". For ports lacking existing 418 keywords, the portname is substituted with "UNKNOWN". 420 >> An implementation MUST allow applications to bind to a portname on 421 a fixed port. 423 E.g., an application could bind to port 80 and indicate portname 424 "DNS" to bind to "DNS.80". 426 >> An implementation MUST allow applications to bind to a portname 427 without specifying a fixed port. 429 E.g., an application could bind to port INPORT_ANY and indicate 430 portname "DNS" to bind to "DNS.INPORT_ANY". 432 As with INADDR_ANY, we anticipate that INPORT_ANY will be overridden 433 by more specific port identifiers. 435 3.2. Error Conditions 437 There are a number of error conditions for a SYN segment with the 438 portname option to be considered: 440 o Invalid NAMESTRING 442 o Invalid service 444 o Invalid port 446 In all three cases, the receiving TCP should act as it would if the 447 service were not available, i.e., it SHOULD return an ICMP port 448 unreachable error message [RFC1122]. This message MUST include the 449 received TCP header including the portname option in its entirety. 450 The destination TCP MUST also send a RST in response. Other 451 interactions are the result of backward compatibility, and are 452 discussed in Section 3.3. 454 3.3. Backward Compatibility 456 The TCP portname option is designed to interact correctly only with 457 portname-supporting implementations, and will fail to connect with 458 non-portname implementations. Applications intended to be compatible 459 with both implementations MUST either attempt both portname and non- 460 portname connections in parallel or retry a failed portname attempt 461 with a non-portname attempt. 463 There are two error conditions due to the interaction of TCPs 464 supporting the portname option with TCPs which lack that support. In 465 particular: 467 o As per existing RFC793 requirements TCP SYN segments received by a 468 non-portname TCP MUST be ignored, and will return a SYN-ACK if any 469 service bound to that port. The source TCP will thus receive a 470 SYN-ACK without the required null portname option (i.e., 471 LENGTH=2), which will cause the connection attempt to be aborted 472 via a RST and an error sent to the application as if the port were 473 unreachable. 475 o Conventional TCP SYN received by portname TCP: A portname-capable 476 TCP MUST allow conventional binding of services to fixed ports. 477 TCP SYNs lacking the portname option MUST be handled 478 conventionally. 480 4. Issues 482 The TCP portname option requires API support, one variant of which is 483 informally presented here. The option interacts with some other IP 484 and TCP services, notably security services. Variants of the option 485 may be useful in other transport protocols. Also, there were a number 486 of alternate designs considered which this document captures in 487 summary. 489 4.1. API Support 491 The TCP portname option requires an API to allow a service to bind to 492 a port NAMESTRING rather than just a port number. One approach would 493 be to extend the existing port number fields to allow the 494 "portname.portnumber" format. A simpler approach is to use separate 495 commands as follows: 497 Use the existing port number indicator command (e.g., Unix bind() or 498 connect() calls) to select a specific port number where desired. 500 Use the existing socket parameterization command (e.g., Unix 501 setsockopt()) to set the portname option, e.g., TCP_PORTNAME). 503 We propose to extend the semantics of 'all zeroes' as used to 504 indicate floating/dynamically selected IP addresses and port numbers 505 to be used for the unspecified port number INPORT_ANY. 507 4.2. Interaction with Other Protocols 509 The TCP portname option potentially interacts with any other protocol 510 that interprets or modifies TCP port numbers. This includes IPsec and 511 other firewall systems, TCP/MD5 and other TCP security mechanisms, 512 FTP and other in-band exchange of ports, and network address 513 translators (NATs). 515 IPsec uses port numbers to perform access control in transport mode 516 [RFC4301]. Security policies can define port-specific access control 517 (PROTECT, BYPASS, DISCARD), as well as port-specific algorithms and 518 keys. Similarly, firewall policies allow or block traffic based on 519 port numbers. 521 Use of port numbers in IPsec selectors and firewalls may assume that 522 the numbers correspond to well-known services. It is useful to note 523 that there is no such requirement; any service may run on any port, 524 subject to mutual agreement between the endpoint hosts. Use of the 525 portname option may interfere with this assumption both within IPsec 526 and in other firewalling systems, but it does not add a new 527 vulnerability. New implementations of IPsec and firewall systems may 528 want to interpret the portname option for use in these policy rules, 529 but again should not rely on either port numbers or portnames to 530 indicate a specific service. 532 The TCP portname option occupies space in the TCP SYN segment. Such 533 space is severely limited in cases where TCP-level security is 534 present, as noted in detail in Section 5. 536 >> The portname option MUST be protected in the same way that the 537 existing SYN destination port is protected. 539 For IPsec, this is not an issue because the entire TCP header and 540 payload are protected by all IPsec modes. None of the TCP header is 541 protected by application-layer security, e.g., TLS, so again this is 542 not an issue [RFC2246]. 544 The resulting primary concern is TCP-level security, e.g., TCP/MD5 545 and its proposed successors [RFC2385] [Bo05] [We06]. TCP/MD5 and 546 [We06] exclude TCP options in their hash calculation; this is 547 confusing, as it fails to protect current critical TCP options such 548 as alternate checksums, window scale, and timestamp options [RFC793] 549 [RFC1323]. [Bo05] allows options to be included or excluded, 550 depending on a header parameter. This document recommends, as per 551 above, that the portname option, as all options, be included in TCP- 552 level protection. 554 A number of protocols exchange port numbers in-band, notably to 555 coordinate separate concurrent connections, e.g., FTP (file transfer) 556 and SIP (teleconferencing). Because these protocols coordinate the 557 specific port numbers in advance, there is no need for the portname 558 option to indicate the desired service. As a result, it is unlikely 559 that it would be useful to augment these protocols to support the 560 portnames option. 562 Network address and port translators, known collectively as NATs, not 563 only read TCP ports, but may also translate them [RFC2993]. This 564 interferes with the use of ports for service identification 565 [RFC3234]. The portname option may allow services to be identified 566 behind NATs if NATs are not further extended to translate portname 567 options. It is thus unknown whether the portname option will help 568 restore service identification in the presence of NATs. 570 TCP connections using the portname option continue to use IP 571 addresses and ports, although both port numbers are typically set 572 arbitrarily. Translation of these ports should not interfere with the 573 operation of NATs, though this has not been verified and is not a 574 design requirement. 576 4.3. Potential Use in Other Transport Protocols 578 As noted earlier, the portname option may be a useful addition to a 579 variety of other transport protocols, such as UDP, SCTP and DCCP 580 [RFC768] [RFC2960] [RFC4340]. Adding portname support to SCTP and 581 DCCP should be straightforward because both already have an option 582 space. These are not addressed further in this document, because this 583 focuses on TCP only. 585 UDP lacks options, so adding support for portnames is not 586 straightforward. One possible approach uses the TCPMUX approach, in 587 which the destination port is fixed to a reserved 'portname' port and 588 the NAMESTRING and LENGTH appear in the data (Figure 2). The packet 589 data is located immediately after the NAMESTRING field. 591 0 7 8 15 16 23 24 31 592 +--------+--------+--------+--------+ 593 | Source | portname | 594 | Port | Port | 595 +--------+--------+--------+--------+ 596 | UDP message | | 597 | Length | Checksum | 598 +--------+--------+--------+--------+ 599 | | 600 | LENGTH | NAMESTRING... 601 +---------------- ... 603 Figure 2 Potential UDP portname option format 605 This possible UDP format is viable because UDP has no connection 606 semantics to violate by placing options in the UDP data area. Using a 607 fixed portname port limits the number of outstanding UDP messages to 608 65,536, but this is less of an issue because UDP has no address/port- 609 tuple based semantics; any request/response exchange that uses UDP 610 must include its own layer of message identifiers anyway. 612 4.4. Discussion of Alternative Approaches 614 The current proposal assumes that the source TCP selects both source 615 and destination port numbers randomly, that the portname option 616 occurs only in SYN and SYN-ACKs, and that the binding of connection 617 to service happens inside the destination at mapping of TCB-to- 618 process. A number of alternative approaches were considered during 619 the development of the approach presented herein. These include: 621 o A portmapper-like service that returns a specific port number 623 o Continued demuxing based on the portname option 625 o Dynamic overwriting of the destination port 627 The first approach, of returning a specific port number for a 628 service, requires a separate round trip and messages to initiate a 629 connection. We avoid both the additional time and messages in the 630 proposed solution which integrates the lookup in the SYN. 632 Continued demultiplexing based on portname would violate TCP 633 connection semantics, which indicate that a connection be uniquely 634 identified by the 4-tuple: . 635 Although portname demuxing would increase the connection name space, 636 this seems unnecessary as it is already over 4,000,000,000 even 637 between a single pair of host addresses. Finally, this variant incurs 638 the portname NAMESTRING overhead on every message, which seems 639 unnecessarily inefficient. The proposed solution is more efficient 640 and sufficiently increases the utility of the entire current 641 connection name space. 643 Dynamic overwriting of the destination port would allow late-binding 644 of the destination port. This complicates the connection 645 establishment on the source side, because the SYN-ACK would have a 646 different port pair than the SYN. The primary utility for overwriting 647 the port number would be to facilitate demultiplexing at the 648 receiver, but this is should already include the entire 4-tuple 649 anyway. Overall, this variant seems unnecessarily complex for no real 650 benefit. 652 5. The Portname Name Space 654 The portname option requires a new portname name space. IANA already 655 manages an equivalent space, known as the "keyword" name of a port, 656 which is allocated first-come, first-served, and whose strings 657 typically already include both the protocol name and version number. 658 The portname option is designed to use those same keywords, but 659 renders the need for port number allocation unnecessary. 661 Portnames need to fit inside the available TCP option space, which 662 provides 40 bytes for options. It is useful to consider that TCP SYN 663 packets may include other options consuming up to 33 bytes, notably: 665 o 16 bytes of authentication [Bo05] [We06] [To06] 667 o 4 bytes of MSS 669 o 10 bytes of timestamp 671 o 3 bytes of windowscale 673 This leaves only 7 bytes for the portname option, or 5 bytes for the 674 NAMESTRING. This would accommodate only 20% of existing port names, 675 as port keywords are currently distributed nearly linearly from 2 to 676 15 bytes long as follows: 678 100% +---------------------------*- 679 90% + * * 680 80% + * * * 681 70% + * * * * 682 60% + * * * * * * 683 50% + * * * * * * * 684 40% + * * * * * * * * 685 30% + * * * * * * * * * 686 20% + * * * * * * * * * * 687 10% + * * * * * * * * * * * * 688 0% +-*-*------------------------- 689 0 0 0 0 0 0 0 0 0 1 1 1 1 1 690 1 2 3 4 5 6 7 8 9 0 1 2 3 4 692 Port keyword length 694 Figure 3 Distribution of current port keywords 696 Note that the most common ports used in the Internet are not 697 necessarily those with the shortest names; although HTTP represents 698 65% of traffic, services like Gnutella and Napster are also 699 nontrivially represented. We note, however, that the use of TCP 700 authentication is currently deprecated except for routing 701 applications, most of which have short names (e.g., bgp, ldp, msdp). 703 When non-TCP authentication is used - e.g., IPsec - the available 704 portname name space is over 20 bytes; this accommodates 100% of 705 current names, none of which is longer than 15 bytes. 707 Portnames MUST be handled as an opaque sequence of bytes; note that 708 this includes zero-valued bytes which some systems interpret as "end 709 of string" characters". To support human-readable names, portnames 710 are represented as UTF-8 [RFC3629]. 712 6. Security Considerations 714 There are four areas of security which the portname option raises: 716 1. Interaction with IPsec and firewalls 718 2. Interaction with TCP/MD5 and other TCP-level security 720 3. Increased DOS impact 722 The impact on IPsec and firewalls is discussed in detail in Section 723 4.2. As noted there, the portname option defeats the assumption that 724 port numbers correspond to specific services, an assumption that was 725 already defeated between consenting hosts. The portname option raises 726 no new vulnerability. 728 The impact of the portname option on TCP/MD5 and other TCP-layer 729 security services is also discussed in Sections 4.2 and 5. Use of 730 these services without inclusion of TCP options makes all options 731 vulnerable, including the portname option. Because the portname 732 option places the service identifier in this insecure option space, 733 it increases TCP's vulnerability. The appropriate solution would be 734 to use a TCP-level security that covers options, such as [Bo05]. Use 735 of these security options also reduces the space available for the 736 portname option, but this affects only for a limited set of routing 737 protocols that already have short port keywords, and thus should not 738 be an issue. 740 The use of strings as port identifiers means that TPC SYN segments 741 are longer, requiring more space to buffer while processing. The port 742 indexing is a more complex operation, requiring string lookup rather 743 than 16-bit indexing. These two aspects cause TCP SYN flooding 744 attacks to consume more space and processing resources when the 745 portname option is used. Typical SYN flooding mitigations can be used 746 here [Ed06]. The additional resources incurred by the portname option 747 are minimal, and can be mitigated by separate limits on the rate of 748 portname options processed. 750 7. IANA Considerations 752 This document specifies a new TCP option. The KIND for this option 753 must be assigned by IANA prior to this document's issuance as an RFC. 755 This document requires IANA to manage a new name space of "TCP 756 Portnames". This name space should be initially seeded with the 757 "keywords" of current TCP ports. This namespace MUST include any UTF- 758 8 encoded string. Although the current port keywords are limited to 759 15 characters, portnames are limited only by available TCP option 760 space. 762 IANA should allocate a TCP destination port for the portname service, 763 to allow applications to bind to that port and then receive on any 764 incoming destination port. This is the port space equivalent of 765 INADDR_ANY, and is thus called INPORT_ANY; the value "0" is 766 suggested. 768 [AUTHOR'S NOTE: if the UDP variant is included, the destination port 769 should be INPORT_ANY; TCP connections to INPORT_ANY that lack the TCP 770 portname option MUST be rejected.] 772 8. Conclusions 774 776 9. Acknowledgments 778 This work was inspired by discussions on the IETF mailing list, 779 notably by suggestions by Keith Moore and Noel Chiappa. Bob Braden 780 noted some of the origins of the named service concept. 782 10. References 784 10.1. Normative References 786 [RFC793] Postel, J., "Transmission Control Protocol," STD 7, RFC 787 793, Sept. 1981 (STANDARD). 789 [RFC1122] Braden, R. (ed.), "Requirements for Internet Hosts - 790 Communication Layers," STD 3, RFC 1122, Oct. 1989 791 (STANDARD). 793 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 794 Requirement Levels", BCP 14, RFC 2119, March 1997 (BEST 795 CURRENT PRACTICE). 797 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 798 Signature Option," RFC 2385, Aug. 1998 (PROPOSED STANDARD). 800 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646," 801 STD 63, RFC3629, Nov. 2003 (STANDARD). 803 10.2. Informative References 805 [CAIDA] CAIDA 2002 workload analysis, 806 http://www.caida.org/analysis/workload/byapplication/oc48/ 808 [IANA] Internet Assigned Numbers Authority, www.iana.org 810 [RFC814] Clark, D., "NAME, ADDRESSES, PORTS, AND ROUTES," RFC 814, 811 July 1982 (UNKNOWN). 813 [RFC959] Postel, J., J. Reynolds, "FILE TRANSFER PROTOCOL (FTP)," 814 STD 9, RFC 959, Oct. 1985 (STANDARD). 816 [RFC1078] Lottor, M., "TCP Port Service Multiplexer (TCPMUX)," 817 RFC1078, Nov. 1988 (UNKNOWN). 819 [RFC1323] Jacobson, V., R. Braden, D. Borman, "TCP Extensions for 820 High Performance," RFC 1323, May 1992 (PROPOSED STANDARD). 822 [RFC1831] Srinivasan, R., "RPC: Remote Procedure Call Protocol 823 Specification Version 2," RFC 1078, June 1995 (PROPOSED 824 STANDARD). 826 [RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2," 827 RFC 1833, August 1995 (PROPOSED STANDARD). 829 [RFC2246] Dierks, T., C. Allen, "The TLS Protocol Version 1.0," RFC 830 2246, Jan. 1999 (PROPOSED STANDARD). 832 [RFC2780] Bradner, S., V. Paxson, "IANA Allocation Guidelines For 833 Values In the Internet Protocol and Related Headers," BCP 834 37, RFC 2780, March 2000 (BEST CURRENT PRACTICE). 836 [RFC2782] Gulbrandsen, A., P. Vixie, L. Esibov, "A DNS RR for 837 specifying the location of services (DNS SRV)," RFC 2782, 838 Feb. 2000 (PROPOSED STANDARD). 840 [RFC2960] Stewart, R., Q. Xie, K. Morneault, C. Sharp, H. 841 Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, V. 842 Paxson, "Stream Control Transmission Protocol," RFC 2960, 843 Oct. 2000 (PROPOSED STANDARD). 845 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 846 November 2000 (INFORMATIONAL). 848 [RFC3261] Rosenberg, J., H. Schulzrinne, G. Camarillo, A. Johnston, 849 J. Peterson, R. Sparks, M. Handley, E. Schooler, "SIP: 850 Session Initiation Protocol," RFC 3261, June 2002 (PROPOSED 851 STANDARD). 853 [RFC3424] Daigle, L. and IAB, "IAB Considerations for Unilateral 854 Self-Address Fixing (UNSAF) Across Network Address 855 Translation", RFC 3424, November 2002 (INFORMATIONAL). 857 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 858 Signature Option," RFC 3562, July 2003(INFORMATIONAL). 860 [RFC4278] Bellovin, S., A. Zinin, "Standards Maturity Variance 861 Regarding the TCP MD5 Signature Option (RFC 2385) and the 862 BGP-4 Specification," RFC 4278, Jan. 2006 (INFORMATIONAL). 864 [RFC4301] Kent, S., K. Seo, "Security Architecture for the Internet 865 Protocol," RFC4301, Dec. 2005 (PROPOSED STANDARD). 867 [RFC4340] Kohler, E., M. Handley, S. Floyd, "Datagram Congestion 868 Control Protocol (DCCP)," RFC 4340, Mar. 2006 (PROPOSED 869 STANDARD). 871 [Bo06] Bonica, R., B. Weis, S. Viswanathan, A. Lange, O. Wheeler, 872 "Authentication for TCP-based Routing and Management 873 Protocols," Feb. 2006 (work in progress). 875 [Ed06] Eddy, W., "TCP SYN Flooding Attacks and Common 876 Mitigations," Apr. 2006 (work in progress). 878 [We05] Weis, B., "TCP Message Authentication Code Option," Dec. 879 2005(work in progress). 881 Author's Addresses 883 Joe Touch 884 USC/ISI 885 4676 Admiralty Way 886 Marina del Rey, CA 90292-6695 887 U.S.A. 889 Phone: +1 (310) 448-9151 890 Email: touch@isi.edu 891 URL: http://www.isi.edu/touch 893 Intellectual Property Statement 895 The IETF takes no position regarding the validity or scope of any 896 Intellectual Property Rights or other rights that might be claimed to 897 pertain to the implementation or use of the technology described in 898 this document or the extent to which any license under such rights 899 might or might not be available; nor does it represent that it has 900 made any independent effort to identify any such rights. Information 901 on the procedures with respect to rights in RFC documents can be 902 found in BCP 78 and BCP 79. 904 Copies of IPR disclosures made to the IETF Secretariat and any 905 assurances of licenses to be made available, or the result of an 906 attempt made to obtain a general license or permission for the use of 907 such proprietary rights by implementers or users of this 908 specification can be obtained from the IETF on-line IPR repository at 909 http://www.ietf.org/ipr. 911 The IETF invites any interested party to bring to its attention any 912 copyrights, patents or patent applications, or other proprietary 913 rights that may cover technology that may be required to implement 914 this standard. Please address the information to the IETF at 915 ietf-ipr@ietf.org. 917 Disclaimer of Validity 919 This document and the information contained herein are provided on an 920 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 921 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 922 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 923 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 924 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 925 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 927 Copyright Statement 929 Copyright (C) The Internet Society (2006). 931 This document is subject to the rights, licenses and restrictions 932 contained in BCP 78, and except as set forth therein, the authors 933 retain all their rights. 935 Acknowledgment 937 Funding for the RFC Editor function is currently provided by the 938 Internet Society.