idnits 2.17.1 draft-touch-tcpm-sno-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 9, 2015) is 3307 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** 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 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 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 Intended status: Experimental March 9, 2015 4 Expires: September 2015 6 The TCP Service Number Option (SNO) 7 draft-touch-tcpm-sno-03.txt 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. This document may not be modified, 13 and derivative works of it may not be created, except to publish it 14 as an RFC and to translate it into languages other than English. 16 This document may contain material from IETF Documents or IETF 17 Contributions published or made publicly available before November 18 10, 2008. The person(s) controlling the copyright in some of this 19 material may not have granted the IETF Trust the right to allow 20 modifications of such material outside the IETF Standards Process. 21 Without obtaining an adequate license from the person(s) controlling 22 the copyright in such materials, this document may not be modified 23 outside the IETF Standards Process, and derivative works of it may 24 not be created outside the IETF Standards Process, except to format 25 it for publication as an RFC or to translate it into languages other 26 than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six 34 months and may be updated, replaced, or obsoleted by other documents 35 at any time. It is inappropriate to use Internet-Drafts as 36 reference material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 This Internet-Draft will expire on September 9, 2015. 46 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with 56 respect to this document. Code Components extracted from this 57 document must include Simplified BSD License text as described in 58 Section 4.e of the Trust Legal Provisions and are provided without 59 warranty as described in the Simplified BSD License. 61 Abstract 63 This document specifies a TCP option for service numbers. The 64 current SYN destination port is used both to indicate the desired 65 service and as a connection demultiplexing field. This option 66 separates those two functions, retaining the current destination 67 port solely for demultiplexing and indicating the service separately 68 in a service number option (SNO). By decoupling these two functions, 69 SNO allows a larger number of concurrent connections for a single 70 service, as might be useful between fixed addresses of proxies. 72 Table of Contents 74 1. Introduction...................................................3 75 2. Conventions used in this document..............................4 76 3. Background.....................................................4 77 3.1. IANA port numbers.........................................5 78 3.2. DNS SRV records...........................................6 79 3.3. RPC portmapper and RPCBIND................................7 80 3.4. TCPMUX....................................................7 81 3.5. Summary of alternatives and comparison to SNO.............8 82 4. TCP Service Number Option......................................9 83 4.1. Interaction between SNO and the TCP API..................11 84 4.1.1. Active OPEN (Unix connect)..........................11 85 4.1.2. Passive OPEN (Unix listen)..........................11 86 4.1.3. Impact on the TCP OPEN API..........................11 87 4.2. Error conditions.........................................12 88 4.3. Backward compatibility...................................12 89 5. Issues........................................................13 90 5.1. Interaction with other protocols and features............13 91 5.2. Potential use in other transport protocols...............14 92 5.3. Discussion of alternative approaches.....................15 93 5.4. Implementation Issues....................................16 94 6. SNO impact on TCP option space................................17 95 7. Security Considerations.......................................17 96 8. IANA considerations...........................................18 97 9. References....................................................18 98 9.1. Normative References.....................................18 99 9.2. Informative References...................................18 100 10. Acknowledgments..............................................20 102 1. Introduction 104 TCP connections are defined by a socket pair, where each TCP socket 105 consists of an IP address and a port number. The IP addresses 106 indicate the network endpoints (hosts) of the connection, and the 107 port numbers allow a pair of IP endpoints to have more than one 108 concurrent connection. TCP connections begin when an application on 109 one host sends a SYN segment to a waiting application on the other 110 host, determined by the destination port in that segment. 112 Port numbers thus serve two distinct purposes. For the entirety of a 113 connection, they help differentiate concurrent connections as part 114 of the socket pair, and are thus used for demultiplexing within a 115 host. For the SYN, the destination port also indicates the waiting 116 application, i.e., the service for that connection, acting as a 117 service identifier. 119 Service identifiers need to be coordinated between the endpoints of 120 a connection, but need not be coordinated with any other component 121 of the network. To avoid the need for explicit pairwise 122 coordination, most Internet transport protocols currently use 123 globally-assigned destination port numbers as service identifiers; 124 this includes TCP, UDP, SCTP, and DCCP [RFC768] [RFC793] [RFC4960] 125 [RFC4340]. An assigned port number can be requested from the 126 Internet Assigned Numbers Authority (IANA) [IANA]. 128 The use of SYN destination ports as both service identifier and 129 demultiplexing identifier can impact TCP performance. For a given 130 service, a given pair of endpoints can have at most 2^16 concurrent 131 connections, or even connections in the TIME-WAIT state (which is 132 typically expected to last two minutes) [To1999]. This limits 133 services to at most an average of 550 connections per second, which 134 can be a constraint on proxy-to-proxy services. 136 To reduce this impact, this document specifies the TCP service 137 number option (SNO), which allows services to be specified in an 138 option separate from the current header destination port field. SNO 139 decouples the use of ports for connection demultiplexing and state 140 management from their use to indicate a desired endpoint service. 141 This decoupling can substantially increase the number of concurrent 142 connections to 2^32; even considering current expected TIME-WAIT 143 delay, that can support up to 35.8M connections per second. 145 Although it changes TCP SYNs, it does not otherwise affect the 146 processing of other TCP segments or the TCP state machine. SNO must 147 be implemented at both ends of a TCP connection to be effective. 149 The following is a summary of the RFC2119-level recommendations of 150 this document: 152 >> (TO BE COMPLETED PRIOR TO FINAL SUBMISSION) 154 2. Conventions used in this document 156 In examples, "C:" and "S:" indicate lines sent by the client and 157 server respectively. 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in RFC-2119 [RFC2119]. 163 In this document, these words will appear with that interpretation 164 only when in ALL CAPS. Lower case uses of these words are not to be 165 interpreted as carrying RFC-2119 significance. 167 In this document, the characters ">>" preceding an indented line(s) 168 indicates a compliance requirement statement using the key words 169 listed above. This convention aids reviewers in quickly identifying 170 or finding the explicit compliance requirements of this RFC. 172 3. Background 174 TCP supports multiplexing as one of its six core facilities, 175 allowing a single pair of hosts to have multiple concurrent TCP 176 sessions (see Sec. 1.5 of [RFC793]). An endpoint address is 177 associated with a port number, forming a socket; and "A pair of 178 sockets uniquely identifies each connection." Although ports can be 179 bound to services uniquely at each endpoint, RFC 793 notes that it 180 is useful to attach frequently-used services to fixed ports which 181 are publicly known, but that other services may be discovered by 182 dynamic means. This document addresses one impact of that 183 suggestion, and specifies an alternative which alleviates that 184 impact. 186 The Internet currently relies on the use of fixed, publicly-agreed 187 port numbers for most services, whether for public access (e.g., 188 HTTP, FTP, DNS) or between pre-arranged pairs (e.g., X11, SSL). Some 189 of these services use one public port to negotiate other ports for 190 further exchanges (e.g., FTP, H.323, RPC). 192 There are several current methods for determining the port for a 193 public service: 195 o Index the service in IANA's port registry 197 o Index the service in the host's DNS SRV records 199 o Ask the host directly using an RPC portmapper/bind-like service 201 o Ask the host for a hand-off using the TCPMUX port (port #1) 203 Many of these alternatives, including the use of strings as service 204 identifiers, were described in principle in RFC 814, and have 205 evolved into deployed capabilities [RFC814]. Each of these 206 alternatives is summarized below, and each either significantly 207 limits the number of concurrent connections for a service or incurs 208 additional latency or management overhead compared to SNO. 210 3.1. IANA port numbers 212 The Internet Assigned Numbers Authority currently manages globally 213 reserved port numbers [RFC6335]. The desired port number for a 214 service is determined either by an operating system index to a copy 215 of IANA's table (e.g., getportbyname() in Unix, which indexes the 216 /etc/services file), or is fixed in inside the application. 218 The port number space - 0..65536 - is split into three ranges 219 [RFC2780]: 221 o 0..1023 "well-known", also called "system" ports 223 o 1024..49151 "registered", also called "user" ports 225 o 49152..65535 "dynamic", also called "private" ports 227 The terms "well-known" and "registered" are misnomers; both of those 228 port ranges are managed by IANA, and are equally registered and 229 well-known; they are currently known together as "assigned" 230 [RFC6335]. System ports are intended for services that run in 231 privileged mode, sometimes known as "root", although that 232 distinction is blurred in current operating systems. 234 IANA-managed ports are allocated globally, for all hosts everywhere 235 on the public Internet, even though the meaning of a port need be 236 known only for a particular host. A given service is typically 237 assigned a single port, which then limits the number of concurrent 238 connections between two hosts to 2^16, i.e., the number expressible 239 in the source port field. This assumes that the source port can be 240 arbitrary; in may implementations, when a service is bound to a SYN 241 destination port it is prohibited for use in other connections, 242 e.g., as a source port for outgoing SYNs. 244 3.2. DNS SRV records 246 DNS SRV resource records provide a way to find the port number for a 247 service based on its string name [RFC2782]. A host asks the DNS to 248 index "_servicename._tcp.hostname" (underscores required) and the 249 response is a record that includes both the port number and host's 250 IP address. 252 SRV records allow port numbers to be allocated on a per-host basis, 253 and allow multiple ports to be indicated for a given service. A 254 system that wants to support a large number of concurrent HTTP 255 connections could advertise the HTTP service as available on the 256 entire unassigned (dynamic) port range, in addition to port 80. This 257 can increase the number of concurrent connections to 2^30 (2^14 258 dynamic ports and 2^16 source ports), which would be nearly as good 259 as SNO (2^32). 261 However, SRV lookups require an additional protocol exchange for 262 each first-time access, which can traverse much of the same path the 263 TCP SYN will, i.e., incurring an additional round-trip time of delay 264 (because DNS servers are often located near the hosts they serve). 265 Further, using SRV records requires that the dynamic ports be 266 allocated in advance, and they cannot be reclaimed once advertised. 267 SRV advertisement may be useful for a single known service, but does 268 not support a larger number of connections for any (or every) 269 service on-demand. 271 Additional challenges for DNS SRV records are autonomy, robustness, 272 and size of the name space. Many hosts do not have control over 273 their DNS entries; moving port lookup into the DNS could limit the 274 services that a host can deploy for public access. This solution 275 also makes the DNS a required part of the Internet architecture, 276 even for accessing services on hosts with well-known IP addresses 277 (e.g., the DNS itself). This decreases network robustness, because 278 access of services on a host depends on access to the DNS. 280 3.3. RPC portmapper and RPCBIND 282 An alternative to indexing the service name at a separate host via 283 the DNS would be to contact the intended host directly and request 284 the lookup there. This is how the RPC portmapper (v2) and RPCBIND 285 (v3 and v4) services work, where the source host contacts the 286 destination on port #111 [RFC1831][RFC1833]. This service was 287 designed for the same basic reason as the TCP port option of this 288 document: to allow a small subset of a potentially large set of 289 services to be dynamically bound to a small number of ports. The 290 differences between portmapper and RPCBIND are not important here, 291 so they are discussed as a single example. 293 In both portmapper and RPCBIND the source host contacts the 294 destination host on port 111, and issues a request including the 295 desired destination RPC service name. A response indicates the 296 appropriate port for that RPC service. 298 Like the DNS SRV solution, portmapper/RPCBIND requires a separate 299 round-trip (one for UDP; more for TCP) to perform the lookup 300 operation. This adds to both the communication overhead and 301 connection establishment latency. 303 The portmapper service also allows services to be selected on 304 version, i.e., to have different versions of a service on different 305 ports, accessed using the same version name but a different version 306 number. This is handled in some IANA entries, DNS SRV records, and 307 TCPMUX by using a port keyword that embeds the version number in the 308 name, e.g., "imap" vs. "imap3". In most other cases, versioning is 309 indicated and negotiated in-band, inside the protocol (e.g., HTTP). 311 Unfortunately, portmapper has the same limitation as DNS SRV 312 records; once a port is advertised for a given service, it cannot be 313 reclaimed for use by another service. Further, once a given service 314 is advertised, it is likely that the requesting host will cache the 315 response. As a result, dynamic ports can be used to extend the port 316 space for a given service in advance, but they need to be pinned to 317 that service when it is first requested from that host. Again, this 318 limits the ability to flexibly support large numbers of connections 319 for any (or every) service. 321 3.4. TCPMUX 323 TCPMUX is a service on TCP port #1 which allows a host to provide a 324 port name handoff service for itself [RFC1078]. A source host opens 325 a connection to port 1 on a destination host and transmits 326 "portname" in the data stream; the destination replies with 327 either "+" (yes, the service is available) or "-" 328 (no, the service is not available). If the service is available, the 329 connection is transferred to the desired service while still in the 330 OPEN state. 332 TCPMUX modifies the semantics of TCP connection establishment; its 333 connections always succeed, and upon receipt of the named service 334 the application must determine whether to proceed or not. This 335 document seeks a more conventional TCP semantics, where unavailable 336 services result in a rejected connection (e.g., RST in reply and/or 337 ICMP error message). 339 TCPMUX further requires all new connections to be received on a 340 single port; this again limits the number of connections between two 341 machines to 2^16, which provides no benefit compared to existing 342 assigned ports as currently used in SYN segments. 344 3.5. Summary of alternatives and comparison to SNO 346 Each of the alternatives presented has a significant limitation. 347 These alternatives are summarized as follows: 349 o IANA ports: limits a given service to 2^16 concurrent connections 350 between two IP addresses; fewer if system/user/dynamic boundaries 351 are preserved 353 o DNS SRV records: requires an extra round-trip exchange for 354 lookup, not typically under host control, allows up to 2^30 355 concurrent connections but requires that the additional space of 356 2^14 be allocated to services on a given host in advance. 358 o Portmapper: requires an extra round-trip exchange for lookup, 359 allows up to 2^30 concurrent connections but requires that the 360 additional space of 2^14 be allocated to services on a given host 361 in advance 363 o TCPMUX: destroys semantics of TCP connection establishment, 364 limits connections per endpoint pair to 2^16 over all services 366 SNO allows the destination host to associate services with processes 367 on a per-connection basis, while avoiding unnecessary additional 368 round-trips or connections and also while reducing message overhead. 369 This enables every service to support up to 2^32 concurrent 370 connections, by decoupling the demultiplexing and service identifier 371 role of SYN destination ports. 373 The basic operation of SNO is as follows: 375 o The source host issues a SYN, picking both source and destination 376 port numbers arbitrarily that are not currently in use (active or 377 pending connection). 379 o The SYN includes SNO, which indicates the IANA assigned port 380 number of the desired service. 382 o The destination host, upon receiving the SYN with SNO, determines 383 whether the service indicated in the option is running. If so, a 384 SYN-ACK is issued with a zero-length SNO, indicating success of 385 the lookup and handoff. The service is bound to that connection 386 at the destination. 388 o If the service is not available, the appropriate RST and/or ICMP 389 error messages are returned. 391 The benefits to TCP SNO are that: 393 o For a given service, the number of connections between two given 394 IP addresses is no longer limited to 2^16; it is expanded to 395 2^32. 397 o SNO support is provided at the same host as the intended service, 398 so the fate of both is shared (i.e., it is more robust than 399 decoupled service such as DNS SRV). 401 o SNO is embedded in the TCP SYN segment, avoiding extra round 402 trips and messages. 404 o NAT traversal is preserved. 406 o TCP connection semantics are maintained, i.e., services not 407 available never connect. 409 4. TCP Service Number Option 411 The TCP service number option (SNO) extends the TCP header to 412 include a 16-bit port field indicating desired service, as shown in 413 Figure 1. 415 >> New implementations of TCP MAY implement SNO. 417 >> SNO SHOULD NOT appear in any TCP segment except SYN and SYN-ACK. 418 SNO MUST be silently ignored if in any segments except SYN and SYN- 419 ACK. 421 SNO includes the mandatory KIND and LENGTH fields [RFC793], as well 422 as the desired service port number. The current specification uses 423 the TCP Experimental Option format, with an ExID of 0x5323 in 424 network-standard byte order (ASCII for "S#") [RFC6994]. 426 The KIND is a single octet (byte) which indicates this is an 427 experimental option; SNO is supported on both experimental options 428 (253 and 254); there is no difference as to which experimental 429 option is used. The LENGTH is a single octet (byte) interpreted as 430 an unsigned number that indicates the length of this option in 431 octets (bytes), including the KIND and LENGTH fields, as well as the 432 octets of the Service-Number. 434 +--------+--------+--------+--------+ 435 | 253 | 6 | 0x53 | 0x23 | 436 +--------+--------+--------+--------+ 437 | Service-Number | 438 +--------+--------+ 440 Figure 1 TCP SNO SYN option format 442 Upon receipt of a TCP SYN segment including SNO ("TCP SYN/SNO"), the 443 Service-Number is matched against a list of available services. 444 Available services are those that listen on the indicated port 445 number. E.g., a web server that listens for incoming connections on 446 port 80 will respond to connections with SYN segments with SNO=80. 448 The way in which SNO and TCP destination port numbers interacts is 449 described in Section 4.1. When an incoming TCP SYN/SNO is considered 450 valid, the connection is completed by returning a SYN-ACK with a 451 null SNO. 453 +--------+--------+--------+--------+ 454 | 253 | 4 | 0x53 | 0x23 | 455 +--------+--------+--------+--------+ 457 Figure 2 TCP Null SNO format, as used in SYN-ACK 459 >> A TCP SYN/SNO answered with a TCP SYN with a non-null SNO (LENGTH 460 > 2) or lacking the SNO option MUST cause the initiator to abort the 461 connection via issuing a RST and by reporting an error to the 462 application as if the port were not available. 464 The TCB for that connection is then associated with the process for 465 the matching service, which then handles all further interactions 466 with the connection. 468 4.1. Interaction between SNO and the TCP API 470 TCP currently uses TCP port numbers to demultiplex connections as 471 well as to indicate the desired service at the destination. SNO 472 retains the demultiplexing capability, but overrides service 473 identification. 475 TCP specifies port numbers for connections in the OPEN command. The 476 current OPEN command is described in RFC 793 Sections 2.7 and 3.8 477 as: 479 OPEN (local port, foreign socket, active/passive 480 [, timeout] [, precedence] [, security/compartment] 481 [, options]) 482 -> local connection name 484 The OPEN call is used to initiate connections, corresponding to Unix 485 connect, and to wait for incoming connection requests, corresponding 486 to Unix listen. The impact of the SNO option on each of these 487 variants is described below. 489 4.1.1. Active OPEN (Unix connect) 491 During a TCP active OPEN command, SNO interprets the port number of 492 foreign TCP socket as the SNO Service-Number and selects a random 493 number as the foreign port. The OPEN command can be extended to 494 override that random selection by extending the foreign socket to 495 include both the service identifier and port number as separate 496 fields. 498 4.1.2. Passive OPEN (Unix listen) 500 During a TCP passive OPEN command, SNO interprets the local port 501 number as the SNO service identifier. The OPEN command can be 502 extended to allow the listening application to also indicate a 503 specific destination port by extending the local port to include 504 both a service identifier and port number as separate fields. 506 4.1.3. Impact on the TCP OPEN API 508 Both active OPEN and passive OPEN may need to extend the current 509 port numbers to include separate service identifiers. It may be 510 useful to consider that only one service identifier is ever used, 511 e.g., an active OPEN may need a separate foreign service identifier, 512 and a passive OPEN may need a separate local service identifier, but 513 separate service identifiers for both foreign and local would never 514 occur. As a result, it may be more convenient to consider the TCP 515 OPEN API as being extended with a single service field as follows: 517 SNOPEN (local port, foreign socket, service, active/passive 518 [, timeout] [, precedence] [, security/compartment] 519 [, options]) 520 -> local connection name 522 Legacy uses of the OPEN call can be trivially converted to the new 523 SNOPEN description. A legacy active OPEN uses the port of the 524 foreign socket as the service; a legacy passive OPEN uses the local 525 port as the service. 527 However, because the most common use is to allow the active foreign 528 port or passive local port "float" (be unspecified, and thus filled 529 by the OS with an arbitrary value), most implementations will not 530 need to modify the TCP OPEN API implementation, or can extend the 531 API using a separate interface (e.g., Unix setsockopt). 533 4.2. Error conditions 535 There are two error conditions for a SYN segment with the SNO option 536 to be considered: 538 o SNO not supported 540 o Invalid port (i.e., no application listening on that port) 542 The case where SNO is not supported is already addressed in TCP as 543 an unknown option [RFC793. Implementations are expected to ignore 544 it, which means the SYN-ACK would not include the SNO confirmation 545 response. 547 >> For an invalid port, the receiving TCP should act as it would if 548 the destination port were a service that is not available, i.e., it 549 SHOULD return an ICMP port unreachable error message [RFC1122]. This 550 message MUST include the received TCP header including the SNO 551 option in its entirety. The destination TCP MUST also send a RST in 552 response. Other interactions are the result of backward 553 compatibility, and are discussed in Section 4.3. 555 4.3. Backward compatibility 557 The TCP SNO option is designed to interact correctly only on SNO- 558 supporting implementations. 560 SNO connection attempts to non-SNO endpoints will be rejected; the 561 SNO SYN will receive a non-SNO SYN-ACK, at which point the SNO 562 endpoint will terminate the connection attempt. 564 Services on SNO endpoints will support both SNO and non-SNO incoming 565 connections, without the need for recompilation or relinking. 567 >> Outgoing connections intended to be compatible with both 568 implementations MUST either attempt both SNO and non-SNO connections 569 in parallel or retry a failed SNO attempt with a non-SNO attempt. 571 5. Issues 573 The TCP SNO option interacts with some other IP and TCP services, 574 notably security services. Variants of the option may be useful in 575 other transport protocols. Also, there were a number of alternate 576 designs considered which this document captures in summary. 578 5.1. Interaction with other protocols and features 580 TCP SNO potentially interacts with any other protocol that 581 interprets or modifies TCP port numbers. This includes IPsec and 582 other firewall systems, TCP/MD5 and other TCP security mechanisms, 583 FTP and other in-band exchange of ports, and network address 584 translators (NATs). 586 IPsec uses port numbers to perform access control in transport mode 587 [RFC4301]. Security policies can define port-specific access 588 control (PROTECT, BYPASS, DISCARD), as well as port-specific 589 algorithms and keys. Similarly, firewall policies allow or block 590 traffic based on port numbers. 592 Use of port numbers in IPsec selectors and firewalls may assume that 593 the numbers correspond to well-known services. It is useful to note 594 that there is no such requirement; any service may run on any port, 595 subject to mutual agreement between the endpoint hosts. Use of SNO 596 may interfere with this assumption both within IPsec and in other 597 firewalling systems, but it does not add a new vulnerability. New 598 implementations of IPsec and firewall systems may want to support 599 interpreting SNO in these policy rules, but again should not rely on 600 either port numbers to indicate a specific service. 602 TCP SNO occupies space in the TCP SYN segment. Such space is 603 severely limited in cases where TCP-level security is present, as 604 noted in detail in Section 5. 606 >> TCP SNO MUST be protected in the same way that the existing SYN 607 destination port is protected. 609 For IPsec, this is not an issue because the entire TCP header and 610 payload are protected by all IPsec modes. None of the TCP header is 611 protected by application-layer security, e.g., TLS, so again this is 612 not an issue [RFC5246]. 614 The resulting primary concern is TCP-level security, e.g., legacy 615 TCP/MD5 and its successors TCP-AO [RFC2385][RFC5925]. TCP/MD5 always 616 excludes TCP options in its hash calculation; this it fails to 617 protect current critical TCP options such as alternate checksums, 618 window scale, and timestamp options [RFC793] [RFC1323]. TCP-AO 619 allows options to be included or excluded, depending on per- 620 connection parameter. This document recommends, as per above, that 621 SNO, as all options, be included in TCP-level protection. 623 A number of protocols exchange port numbers in-band, notably to 624 coordinate separate concurrent connections, e.g., FTP (file 625 transfer) and SIP (teleconferencing) [RFC959][RFC3261]. Because 626 these protocols coordinate the specific port numbers in advance, 627 there is no need for SNO to indicate the desired service. As a 628 result, it is unlikely that it would be useful to augment these 629 protocols to support SNO in their creation of subordinate 630 connections. SNO could still be useful in establishing the primary 631 (first) connection for these services. 633 Network address and port translators, known collectively as NATs, 634 not only read TCP ports, but may also translate them [RFC2993]. This 635 interferes with the use of ports for service identification 636 [RFC3234]. SNO may allow services to be identified behind NATs if 637 NATs are not further extended to translate SNO. It is thus unknown 638 whether SNO will help restore service identification in the presence 639 of NATs. 641 TCP connections using SNO continue to use IP addresses and ports, 642 although both port numbers are typically set arbitrarily. 643 Translation of these ports should not interfere with the operation 644 of NATs, though this has not been verified and is not a design 645 requirement. 647 5.2. Potential use in other transport protocols 649 As noted earlier, SNO may be a useful addition to a variety of other 650 transport protocols, such as UDP, SCTP and DCCP [RFC768] [RFC4960] 651 [RFC4340]. Adding SNO support to SCTP and DCCP should be 652 straightforward because both already have an option space. These are 653 not addressed further in this document, because this focuses on TCP 654 only. 656 DCCP already includes a Service Code that provides a similar way to 657 separately identify services, but these codes are 32 bits and use a 658 separate IANA registered space. DCCP does not use Service Codes as a 659 way to expand the number of concurrent connections to a given IANA 660 transport service. 662 UDP lacks options, so adding support for SNO is not feasible. 664 5.3. Discussion of alternative approaches 666 The current proposal assumes that the source TCP selects both source 667 and destination port numbers randomly, that SNO occurs only in SYN 668 and SYN-ACKs. A number of alternative approaches were considered 669 during the development of the approach presented herein. These 670 include: 672 o A portmapper-like service that returns a specific port number 674 o Continued demuxing based on SNO 676 o Dynamic overwriting of the destination port 678 The first approach, of returning a specific port number for a 679 service, requires a separate round trip and messages to initiate a 680 connection. We avoid both the additional time and messages in the 681 proposed solution which integrates the lookup in the SYN. 683 Continued demultiplexing based on SNO would violate TCP connection 684 semantics, which indicate that a connection be uniquely identified 685 by the 4-tuple: . Although 686 SNO demuxing would increase the connection tuple space, this seems 687 unnecessary as it is already over 2^32 concurrent connections 688 between a single pair of host addresses. Finally, this variant 689 incurs the SNO option overhead on every message, which seems 690 unnecessarily inefficient. The proposed solution is more efficient 691 and sufficiently increases the utility of the entire current 692 connection name space. 694 Dynamic overwriting of the destination port complicates the 695 connection establishment on the source side, because the SYN-ACK 696 would have a different port pair than the SYN. It would further 697 interfere with NAT traversal. The primary utility for overwriting 698 the port number would be to facilitate demultiplexing at the 699 receiver, but this is should already include the entire 4-tuple 700 anyway. Overall, this variant seems unnecessarily complex for no 701 real benefit. 703 5.4. Implementation Issues 705 Prototypes underway in both FreeBSD and Linux indicate substantial 706 challenges with implementing SNO due to errors in option processing 707 as well as optimizations that interfere with SNO's decoupling of 708 service and connection identifiers. 710 Option processing has never been sufficiently described to ensure 711 interoperable implementation. Both FreeBSD and Linux assume that TCP 712 options can be processed at a single location in both incoming and 713 outgoing TCP header processing, but this has never been true. In 714 particular, options that determine whether a segment is valid (TCP 715 MD5, TCP-AO, header checksum, etc.) must be processed before any 716 other header fields are interpreted, whereas options that are 717 interpreted in the context of header fields (e.g., SACK, etc.) must 718 be interpreted afterwards. 720 Keeping track of TCP state can require multiple data structures on 721 both endpoints, but these structures are currently optimized 722 assuming that port numbers are overloaded as both service and 723 connection identifiers. Connections can be in any of the following 724 11 states: CLOSED, LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED, FIN- 725 WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT. CLOSED 726 is fictional because no connection context exists. The remaining 727 states are often grouped as follows: 729 o LISTEN - no connection state yet; tracking which ports are bound 731 o Active - SYN-SENT, ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE- 732 WAIT, CLOSING, and LAST-ACK (sometimes also TIME-WAIT), in which 733 full connection state is kept 735 There are two states that are typically not kept in detail - SYN- 736 RECEIVED and TIME-WAIT. SYN-RECEIVED keeps track of a connection 737 that has received a SYN but not yet the final ACK of the three-way 738 handshake; it state is typically not kept in detail to avoid DOS 739 attacks that overload a server with half-open connections [RFC4987]. 740 Similarly, the TIME-WAIT state is often ignored or kept in aggregate 741 to avoid state accumulation on busy servers [Fa99]. 743 The challenge implementing SNO involves using the LISTEN queue for 744 SYN-RECEIVED states. Connections in the LISTEN state are indexed by 745 the service number: for legacy TCP connections, this is the SYN 746 destination port, and for SNO connections this is the SNO service 747 number. In the SYN-RECEIVED state, connections always need to be 748 indexed by the receive port number of the incoming ACK segment. As a 749 result, SNO implementations need a distinct SYN-RECEIVED queue; they 750 cannot reuse the LISTEN queue to keep track of pending half-open 751 connections. 753 The additional state needed for the SYN-RECEIVED queue is the same 754 regardless of whether it shares space with the LISTEN queue - each 755 receive port for half-open connections needs to be listed. The key 756 difference is the index to the queue. 758 6. SNO impact on TCP option space 760 SNO needs to fit inside the available TCP option space, which 761 provides 40 bytes for options. It is useful to consider that TCP SYN 762 segments may include other options consuming up to 33 bytes, 763 notably: 765 o 16 bytes of authentication [RFC5925] 767 o 4 bytes of MSS 769 o 10 bytes of timestamp 771 o 3 bytes of windowscale 773 This leaves only 7 bytes for the SNO option, which is more than 774 sufficient. The experimental variant described herein uses 6 bytes; 775 a standards-track variant would use only 4 bytes. 777 7. Security Considerations 779 There are four areas of security which the SNO option raises: 781 1. Interaction with IPsec and firewalls 783 2. Interaction with TCP/MD5 and TCP-AO security 785 3. Increased DOS impact 787 The impact on IPsec and firewalls is discussed in detail in Section 788 5.1. As noted there, SNO defeats the assumption that port numbers 789 correspond to specific services, an assumption that was already 790 defeated between consenting hosts. The SNO option thus raises no new 791 vulnerability. 793 The impact of SNO on TCP/MD5 and TCP-AO is also discussed in 794 Sections 5.1. Use of these services without inclusion of TCP options 795 makes all options vulnerable, including SNO. 797 The additional resources incurred by parsing the SNO option are 798 minimal. 800 8. IANA considerations 802 This document specifies a new TCP option that uses the shared 803 experimental options format, with ExID = 0x5323 in network-standard 804 byte order (representing ASCII "S#") [RFC6994]. This ExID has 805 already been registered with IANA. 807 9. References 809 9.1. Normative References 811 [RFC793] Postel, J., "Transmission Control Protocol," STD 7, RFC 812 793, Sep. 1981 (STANDARD). 814 [RFC1122] Braden, R. (ed.), "Requirements for Internet Hosts - 815 Communication Layers," STD 3, RFC 1122, Oct. 1989 816 (STANDARD). 818 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 819 Requirement Levels", BCP 14, RFC 2119, Mar. 1997 (BEST 820 CURRENT PRACTICE). 822 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 823 Signature Option," RFC 2385, Aug. 1998 (PROPOSED 824 STANDARD). 826 [RFC6994] Touch, J., "Shared Use of Experimental TCP Options," 827 RFC6994, Aug. 2013 (PROPOSED STANDARD). 829 9.2. Informative References 831 [Fa99] T. Faber, J. Touch, and W. Yue, "The TIME-WAIT state in 832 TCP and Its Effect on Busy Servers," in Proc. IEEE 833 Infocom, 1999, pp. 1573-1583. 835 [Fr2008] Freire, S., A. Zuquete, "A TCP-layer name service for TCP 836 ports", Proc. Usenix, 2008. 838 [IANA] Internet Assigned Numbers Authority, www.iana.org 840 [RFC768] Postel, J., "User Datagram Protocol", RFC768, Aug. 1980 841 (STANDARD). 843 [RFC814] Clark, D., "NAME, ADDRESSES, PORTS, AND ROUTES," RFC 814, 844 Jul. 1982 (UNKNOWN). 846 [RFC959] Postel, J., J. Reynolds, "FILE TRANSFER PROTOCOL (FTP)," 847 STD 9, RFC 959, Oct. 1985 (STANDARD). 849 [RFC1078] Lottor, M., "TCP Port Service Multiplexer (TCPMUX)," 850 RFC1078, Nov. 1988 (UNKNOWN). 852 [RFC1323] Jacobson, V., R. Braden, D. Borman, "TCP Extensions for 853 High Performance," RFC 1323, May 1992 (PROPOSED STANDARD). 855 [RFC1831] Srinivasan, R., "RPC: Remote Procedure Call Protocol 856 Specification Version 2," RFC 1078, Jun. 1995 (PROPOSED 857 STANDARD). 859 [RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2," 860 RFC 1833, Aug. 1995 (PROPOSED STANDARD). 862 [RFC2780] Bradner, S., V. Paxson, "IANA Allocation Guidelines For 863 Values In the Internet Protocol and Related Headers," BCP 864 37, RFC 2780, Mar. 2000 (BEST CURRENT PRACTICE). 866 [RFC2782] Gulbrandsen, A., P. Vixie, L. Esibov, "A DNS RR for 867 specifying the location of services (DNS SRV)," RFC 2782, 868 Feb. 2000 (PROPOSED STANDARD). 870 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 871 November 2000 (INFORMATIONAL). 873 [RFC3234] Carpenter, B., S. Brim, "Middleboxes: Taxonomy and 874 Issues", RFC 3234 Feb. 2002 (INFORMATIONAL). 876 [RFC3261] Rosenberg, J., H. Schulzrinne, G. Camarillo, A. Johnston, 877 J. Peterson, R. Sparks, M. Handley, E. Schooler, "SIP: 878 Session Initiation Protocol," RFC 3261, Jun. 2002 879 (PROPOSED STANDARD). 881 [RFC4301] Kent, S., K. Seo, "Security Architecture for the Internet 882 Protocol," RFC4301, Dec. 2005 (PROPOSED STANDARD). 884 [RFC4340] Kohler, E., M. Handley, S. Floyd, "Datagram Congestion 885 Control Protocol (DCCP)," RFC 4340, Mar. 2006 (PROPOSED 886 STANDARD). 888 [RFC4960] Stewart, R. (Ed.), "Stream Control Transmission Protocol," 889 RFC 4960, Sep. 2007 (PROPOSED STANDARD). 891 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 892 Mitigations," RFC 4987, Aug. 2007. 894 [RFC5246] Dierks, T., E. Rescorla, "The Transport Layer Security 895 (TLS) Protocol Version 1.2," RFC 5246, Aug. 2008 (PROPOSED 896 STANDARD). 898 [RFC5925] Touch, J., A. Mankin, R. Bonica, "The TCP Authentication 899 Option," RFC5925, Jun. 2010 (PROPOSED STANDARD). 901 [RFC6335] Cotton, M., L. Eggert, J. Touch, M. Westerlund, S. 902 Cheshire "Internet Assigned Numbers Authority (IANA) 903 Procedures for theManagement of the Transport Protocol 904 Port Number and Service Name Registry," RFC 6335 / BCP 905 165, Aug. 2011. 907 [To1999] Touch, J., T. Faber, "The TIME-WAIT state in TCP and its 908 Effect on Busy Servers", Proc. Infocom, 1999. 910 [To2006] Touch, J., "A TCP Option for Port Names", draft-touch-tcp- 911 portnames-00.txt (work in progress), Apr. 2006. 913 10. Acknowledgments 915 This work was inspired by discussions on the IETF mailing list, 916 notably by suggestions by Keith Moore and Noel Chiappa. Bob Braden 917 noted some of the origins of the named service concept. 919 This document is based on an earlier version based on using strings 920 rather than IANA port numbers, where the receiving host used the 921 strings to directly identify services [To2006]. A similar approach 922 was proposed that also used strings was implemented in Linux, except 923 that the strings were resolved by a separate server and transmitted 924 in the TCP segment as data (e.g., as with TCPMUX) [Fr2008]. 926 This document was initially prepared using 2-Word-v2.0.template.dot. 928 Authors' Addresses 930 Joe Touch 931 USC/ISI 932 4676 Admiralty Way 933 Marina del Rey, CA 90292-6695 934 U.S.A. 936 Phone: +1 (310) 448-9151 937 Email: touch@isi.edu 938 URL: http://www.isi.edu/touch