idnits 2.17.1 draft-ietf-tsvwg-port-use-08.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 date (March 13, 2015) is 3325 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5405 (Obsoleted by RFC 8085) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 61 (Obsoleted by RFC 62) -- Obsolete informational reference (is this intentional?): RFC 739 (Obsoleted by RFC 750) -- Obsolete informational reference (is this intentional?): RFC 758 (Obsoleted by RFC 762) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 820 (Obsoleted by RFC 870) -- Obsolete informational reference (is this intentional?): RFC 900 (Obsoleted by RFC 923) -- Obsolete informational reference (is this intentional?): RFC 1340 (Obsoleted by RFC 1700) -- Obsolete informational reference (is this intentional?): RFC 1700 (Obsoleted by RFC 3232) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 5766 (Obsoleted by RFC 8656) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TSVWG J. Touch 2 Internet Draft USC/ISI 3 Intended status: Best Current Practice March 13, 2015 4 Expires: September 2015 6 Recommendations for Transport Port Number Uses 7 draft-ietf-tsvwg-port-use-08.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. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on September 13, 2015. 32 Copyright Notice 34 Copyright (c) 2015 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with 42 respect to this document. Code Components extracted from this 43 document must include Simplified BSD License text as described in 44 Section 4.e of the Trust Legal Provisions and are provided without 45 warranty as described in the Simplified BSD License. 47 Abstract 49 This document provides recommendations to application and service 50 protocol designers on how to use the assigned transport protocol 51 port number space and when to request a port assignment from IANA. 52 It provides designer guidelines on how to interact with the IANA 53 processes defined in RFC6335, thus serving to complement (but not 54 update) that document. 56 Table of Contents 58 1. Introduction...................................................2 59 2. Conventions used in this document..............................3 60 3. History........................................................3 61 4. Current Port Number Use........................................5 62 5. What is a Port Number?.........................................5 63 6. Conservation...................................................7 64 6.1. Guiding Principles........................................7 65 6.2. Firewall and NAT Considerations...........................8 66 7. Considerations for Requesting Port Number Assignments..........9 67 7.1. Is a port number assignment necessary?....................9 68 7.2. How Many Assigned Port Numbers?..........................11 69 7.3. Picking an Assigned Port Number..........................12 70 7.4. Support for Security.....................................13 71 7.5. Support for Future Versions..............................14 72 7.6. Transport Protocols......................................15 73 7.7. When to Request an Assignment............................16 74 7.8. Squatting................................................17 75 7.9. Other Considerations.....................................18 76 8. Security Considerations.......................................18 77 9. IANA Considerations...........................................19 78 10. References...................................................19 79 10.1. Normative References....................................19 80 10.2. Informative References..................................20 81 11. Acknowledgments..............................................22 83 1. Introduction 85 This document provides information and advice to application and 86 service designers on the use of assigned transport port numbers. It 87 provides a detailed historical background of the evolution of 88 transport port numbers and their multiple meanings. It also provides 89 specific recommendations to designers on how to use assigned port 90 numbers. Note that this document provides information to potential 91 port number applicants that complements the IANA process described 92 in BCP165 [RFC6335], but it does not change any of the port number 93 assignment procedures described therein. This document is intended 94 to address concerns typically raised during Expert Review of 95 assigned port number applications, but it is not intended to bind 96 those reviews. RFC 6335 also describes the interaction between port 97 experts and port requests in IETF consensus document. Authors of 98 IETF consensus documents should nevertheless follow the advice in 99 this document and can expect comment on their port requests from the 100 port experts during IETF last call or at other times when review is 101 explicitly sought. 103 2. Conventions used in this document 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC-2119 [RFC2119]. 109 In this document, these words will appear with that interpretation 110 only when in ALL CAPS. Lower case uses of these words are not to be 111 interpreted as carrying RFC-2119 significance. 113 In this document, the characters ">>" preceding an indented line(s) 114 indicates a statement using the key words listed above. This 115 convention aids reviewers in quickly identifying or finding 116 requirements for registration and recommendations for use of port 117 numbers in this RFC. 119 3. History 121 The term 'port' was first used in [RFC33] to indicate a simplex 122 communication path from an individual process and originally applied 123 to only the Network Control Program (NCP) connection-oriented 124 protocol. At a meeting described in [RFC37], an idea was presented 125 to decouple connections between processes and links that they use as 126 paths, and thus to include numeric source and destination socket 127 identifiers in packets. [RFC38] provides further detail, describing 128 how processes might have more than one of these paths and that more 129 than one path may be active at a time. As a result, there was the 130 need to add a process identifier to the header of each message so 131 that incoming messages could be demultiplexed to the appropriate 132 process. [RFC38] further suggested that 32 bit numbers would be used 133 for these identifiers. [RFC48] discusses the current notion of 134 listening on a specific port number, but does not discuss the issue 135 of port number determination. [RFC61] notes that the challenge of 136 knowing the appropriate port numbers is "left to the processes" in 137 general, but introduces the concept of a "well-known" port number 138 for common services. 140 [RFC76] proposed a "telephone book" by which an index would allow 141 port numbers to be used by name, but still assumed that both source 142 and destination port numbers are fixed by such a system. [RFC333] 143 proposed that a port number pair, rather than an individual port 144 number, would be used on both sides of the connection for 145 demultiplexing messages. This is the final view in [RFC793] (and its 146 predecessors, including [IEN112]), and brings us to their current 147 meaning. [RFC739] introduced the notion of generic reserved port 148 numbers for groups of protocols, such as "any private RJE server" 149 [RFC739]. Although the overall range of such port numbers was (and 150 remains) 16 bits, only the first 256 (high 8 bits cleared) in the 151 range were considered assigned. 153 [RFC758] is the first to describe port numbers as being used for TCP 154 (previous RFCs all refer to only NCP). It includes a list of such 155 well-known port numbers, as well as describing ranges used for 156 different purposes: 158 Decimal Octal 160 ----------------------------------------------------------- 162 0-63 0-77 Network Wide Standard Function 164 64-127 100-177 Hosts Specific Functions 166 128-223 200-337 Reserved for Future Use 168 224-255 340-377 Any Experimental Function 170 In [RFC820] those range meanings disappeared, and a single list of 171 number assignments is presented. This is also the first time that 172 port numbers are described as applying to a connectionless transport 173 (UDP) rather than only connection-oriented transports. 175 By [RFC900] the ranges appeared as decimal numbers rather than the 176 octal ranges used previously. [RFC1340] increased this range from 177 0..255 to 0..1023, and began to list TCP and UDP port number 178 assignments individually (although the assumption was that once 179 assigned a port number applies to all transport protocols, including 180 TCP, UDP, recently SCTP and DCCP, as well as ISO-TP4 for a brief 181 period in the early 1990s). [RFC1340] also established the 182 Registered range of 1024-59151, though it notes that it is not 183 controlled by the IANA at that point. The list provided by [RFC1700] 184 in 1994 remained the standard until it was declared replaced by an 185 on-line version, as of [RFC3232] in 2002. 187 4. Current Port Number Use 189 RFC6335 indicates three ranges of port number assignments: 191 Binary Hex 193 ----------------------------------------------------------- 195 0-1023 0x0000-0x03FF System (also Well-Known) 197 1024-49151 0x0400-0xBFFF User (also Registered) 199 49152-65535 0xC000-0xFFFF Dynamic (also Private) 201 System (also Well-Known) encompasses the range 0..1023. On some 202 systems, use of these port numbers requires privileged access, e.g., 203 that the process run as 'root' (i.e., as a privileged user), which 204 is why these are referred to as System port numbers. The port 205 numbers from 1024..49151 denotes non-privileged services, known as 206 User (also Registered), because these port numbers do not run with 207 special privileges. Dynamic (also Private) port numbers are not 208 assigned. 210 Both System and User port numbers are assigned through IANA, so both 211 are sometimes called 'registered port numbers'. As a result, the 212 term 'registered' is ambiguous, referring either to the entire range 213 0-49151 or to the User port numbers. Complicating matters further, 214 System port numbers do not always require special (i.e., 'root') 215 privilege. For clarity, the remainder of this document refers to the 216 port number ranges as System, User, and Dynamic, to be consistent 217 with IANA process [RFC6335]. 219 5. What is a Port Number? 221 A port number is a 16-bit number used for two distinct purposes: 223 o Demultiplexing transport endpoint associations within an end 224 host 226 o Identifying a service 228 The first purpose requires that each transport endpoint association 229 (e.g., TCP connection or UDP pairwise association) using a given 230 transport between a given pair of IP addresses use a different pair 231 of port numbers, but does not require either coordination or 232 registration of port number use. It is the second purpose that 233 drives the need for a common registry. 235 Consider a user wanting to run a web server. That service could run 236 on any port number, provided that all clients knew what port number 237 to use to access that service at that host. Such information can be 238 explicitly distributed - for example, by putting it in the URI: 240 http://www.example.com:51509/ 242 Ultimately, the correlation of a service with a port number is an 243 agreement between just the two endpoints of the association. A web 244 server can run on port number 53, which might appear as DNS traffic 245 to others but will connect to browsers that know to use port number 246 53 rather than 80. 248 As a concept, a service is the combination of ISO Layers 5-7 that 249 represents an application protocol capability. For example www (port 250 number 80) is a service that uses HTTP as an application protocol 251 and provides access to a web server [RFC7230]. However, it is 252 possible to use HTTP for other purposes, such as command and 253 control. This is why some current services (HTTP, e.g.) are a bit 254 overloaded - they describe not only the application protocol, but a 255 particular service. 257 IANA assigns port numbers so that Internet endpoints do not need 258 pairwise, explicit coordination of the meaning of their port 259 numbers. This is the primary reason for requesting assigned port 260 numbers with IANA - to have a common agreement between all endpoints 261 on the Internet as to the default meaning of a port number, which 262 provides the endpoints with a default port number for a particular 263 protocol or service. 265 Port numbers are sometimes used by intermediate devices on a network 266 path, either to monitor available services, to monitor traffic 267 (e.g., to indicate the data contents), or to intercept traffic (to 268 block, proxy, relay, aggregate, or otherwise process it). In each 269 case, the intermediate device interprets traffic based on the port 270 number. It is important to recognize that any interpretation of port 271 numbers - except at the endpoints - may be incorrect, because port 272 numbers are meaningful only at the endpoints. Further, port numbers 273 may not be visible to these intermediate devices, such as when the 274 transport protocol is encrypted (as in network- or link-layer 275 tunnels), or when a packet is fragmented (in which case only the 276 first fragment has the port number information). Such port number 277 invisibility may interfere with these in-network port number-based 278 capabilities. 280 Port numbers can also be used for other purposes. Assigned port 281 numbers can simplify end system configuration, so that individual 282 installations do not need to coordinate their use of arbitrary port 283 numbers. Such assignments can also simplify firewall management, so 284 that a single, fixed firewall configuration can either permit or 285 deny a service. 287 It is useful to differentiate a port number from a service name. The 288 former is a numeric value that is used directly in transport 289 protocol headers as a demultiplexing and service identifier. The 290 latter is primarily a user convenience, where the default map 291 between the two is considered static and resolved using a cached 292 index. This document focuses on the former because it is the 293 fundamental network resource. Dynamic maps between the two, i.e., 294 using DNS SRV records, are discussed further in Section 7.1. 296 6. Conservation 298 Assigned port numbers are a limited resource that is globally shared 299 by the entire Internet community. As of 2014, approximately 5850 TCP 300 and 5570 UDP port numbers have been assigned out of a total range of 301 49151. As a result of past conservation, current assigned port use 302 is small and the current rate of assignment avoids the need for 303 transition to larger number spaces. This conservation also helps 304 avoid the need for IANA to rely on assigned port number reclamation, 305 which is practically impossible even though procedurally permitted 306 [RFC6335]. 308 IANA aims to assign only one port number per service, including 309 variants [RFC6335], but there are other benefits to using fewer port 310 numbers for a given service. Use of multiple assigned port numbers 311 can make applications more fragile, especially when firewalls block 312 a subset of those port numbers or use ports numbers to route or 313 prioritize traffic differently. As a result: 315 >> Each assigned port requested MUST be justified by the applicant 316 as an independently useful service. 318 6.1. Guiding Principles 320 This document provides recommendations for users that also help 321 conserve assigned port number space. Again, this document does not 322 update BCP165 [RFC6335], which describes the IANA procedures for 323 managing assigned transport port numbers and services. Assigned port 324 number conservation is based on a number of basic principles: 326 o A single assigned port number can support different functions 327 over separate endpoint associations, determined using in-band 328 information. An FTP data connection can transfer binary or 329 text files, the latter translating line-terminators, as 330 indicated in-band over the control port number [RFC959]. 332 o A single assigned port number can indicate the Dynamic port 333 number(s) on which different capabilities are supported, as 334 with passive-mode FTP [RFC959]. 336 o Several existing services can indicate the Dynamic port 337 number(s) on which other services are supported, such as with 338 mDNS and portmapper [RFC1833] [RFC6762] [RFC6763]. 340 o Copies of an existing service can also be operated on 341 different IP addresses, either on different hosts or as 342 different real or virtual interfaces (or even operating 343 systems) on the same host. 345 o Copies of some existing services can be differentiated using 346 in-band information (e.g., URIs in HTTP Host field and TLS 347 Server Name Indication extension) [RFC7230] [RFC6066]. 349 o Services requiring varying performance properties can already 350 be supported using separate endpoint associations (connections 351 or other associations), each configured to support the desired 352 properties. E.g., a high-speed and low-speed variant can be 353 determined within the service using the same assigned port. 355 Assigned port numbers are intended to differentiate services, not 356 variations of performance, replicas, pairwise endpoint associations, 357 or payload types. Assigned port numbers are also a small space 358 compared to other Internet number spaces; it is never appropriate to 359 consume assigned port numbers to conserve larger spaces such as IP 360 addresses. 362 6.2. Firewall and NAT Considerations 364 Assigned port numbers are useful for configuring firewalls and other 365 port-based systems for access control. Ultimately, these numbers 366 indicate services only to the endpoints, and any intermediate device 367 that assigns meaning to a value can be incorrect. End systems might 368 agree to run web services (HTTP) over port number 53 (typically used 369 for DNS) rather than port number 80, at which point a firewall that 370 blocks port number 80 but permits port number 53 would not have the 371 desired effect. However, assigned port numbers often are important 372 in helping configure firewalls. 374 Using Dynamic port numbers, or explicitly-indicated port numbers 375 indicated in-band over another service (such as with FTP) often 376 complicates firewall and NAT interactions [RFC959]. FTP over 377 firewalls often requires direct support for deep-packet inspection 378 (to snoop for the Dynamic port number for the NAT to correctly map) 379 or passive-mode FTP (in which both connections are opened from the 380 client side). 382 7. Considerations for Requesting Port Number Assignments 384 Port numbers are assigned by IANA by a set of documented procedures 385 [RFC6335]. The following section describes the steps users can take 386 to help assist with responsible use of assigned port numbers, and 387 with preparing an application for a port number assignment. 389 7.1. Is a port number assignment necessary? 391 First, it is useful to consider whether a port number assignment is 392 required. In many cases, a new number assignment may not be needed, 393 for example: 395 o Is this really a new service, or can an existing service 396 suffice? 398 o Is this an experimental service [RFC3692]? If so, consider 399 using the current experimental ports [RFC2780]. 401 o Is this service independently useful? Some systems are 402 composed from collections of different service capabilities, 403 but not all component functions are useful as independent 404 services. Port numbers are typically shared among the smallest 405 independently-useful set of functions. Different service uses 406 or properties can be supported in separate pairwise endpoint 407 associations after an initial negotiation, e.g., to support 408 software decomposition. 410 o Can this service use a Dynamic port number that is coordinated 411 out-of-band, e.g.: 413 o By explicit configuration of both endpoints. 415 o By internal mechanisms within the same host (e.g., a 416 configuration file, indicated within a URI, or using 417 interprocess communication). 419 o Using information exchanged on a related service: FTP, SIP, 420 etc. [RFC959] [RFC3261]. 422 o Using an existing port discovery service: portmapper, mDNS, 423 etc. [RFC1833] [RFC6762] [RFC6763]. 425 There are a few good examples of reasons that more directly suggest 426 that not only is a port number assignment not necessary, but it is 427 directly counter-indicated: 429 o Assigned port numbers are not intended to differentiate 430 performance variations within the same service, e.g., high- 431 speed vs. ordinary speed. Performance variations can be 432 supported within a single assigned port number in context of 433 separate pairwise endpoint associations. 435 o Additional assigned port numbers are not intended to replicate 436 an existing service. For example, if a device is configured to 437 use a typical web browser then it the port number used for 438 that service is a copy of the http service that is already 439 assigned to port number 80 and does not warrant a new 440 assignment. However, an automated system that happens to use 441 HTTP framing - but is not primarily accessed by a browser - 442 might be a new service. A good way to tell is "can an 443 unmodified client of the existing service interact with the 444 proposed service"? If so, that service would be a copy of an 445 existing service and would not merit a new assignment. 447 o Assigned port numbers not intended for intra-machine 448 communication. Such communication can already be supported by 449 internal mechanisms (interprocess communication, shared 450 memory, shared files, etc.). When Internet communication 451 within a host is desired, the server can bind to a Dynamic 452 port that is indicated to the client using these internal 453 mechanisms. 455 o Separate assigned port numbers are not intended for insecure 456 versions of existing (or new) secure services. A service that 457 already requires security would be made more vulnerable by 458 having the same capability accessible without security. 460 Note that the converse is different, i.e., it can be useful to 461 create a new, secure service that replicates an existing 462 insecure service on a new port number assignment. This can be 463 necessary when the existing service is not backward-compatible 464 with security enhancements, such as the use of TLS [RFC5246] 465 or DTLS [RFC6347]. 467 o Assigned port numbers are not intended for indicating 468 different service versions. Version differentiation should be 469 handled in-band, e.g., using a version number at the beginning 470 of an association (e.g., connection or other transaction). 471 This may not be possible with legacy assignments, but all new 472 services should incorporate support for version indication. 474 Some services may not need assigned port numbers at all, e.g., SIP 475 allows voice calls to use Dynamic ports [RFC3261]. Some systems can 476 register services in the DNS, using SRV entries. These services can 477 be discovered by a variety of means, including mDNS, or via direct 478 query [RFC6762] [RFC6763]. In such cases, users can more easily 479 request a SRV name, which are assigned first-come, first-served from 480 a much larger namespace. 482 IANA assigns port numbers, but this assignment is typically used 483 only for servers, i.e., the host that listens for incoming 484 connections or other associations. Clients, i.e., hosts that 485 initiate connections or other associations, typically refer to those 486 assigned port numbers but do not need port number assignments for 487 their endpoint. 489 Finally, an assigned port number is not a guarantee of exclusive 490 use. Traffic for any service might appear on any port number, due to 491 misconfiguration or deliberate misuse. Application and service 492 designers are encouraged to validate traffic based on its content. 494 7.2. How Many Assigned Port Numbers? 496 As noted earlier, systems might require a single port number 497 assignment, but rarely require multiple port numbers. There are a 498 variety of known ways to reduce assigned port number consumption. 499 Although some may be cumbersome or inefficient, they are nearly 500 always preferable to consuming additional port number assignments. 502 Such techniques include: 504 o Use of a discovery service, either a shared service (mDNS), or 505 a discovery service for a given system [RFC6762] [RFC6763]. 507 o Multiplex packet types using in-band information, either on a 508 per-message or per-connection basis. Such demultiplexing can 509 even hand-off different messages and connections among 510 different processes, such as is done with FTP [RFC959]. 512 There are some cases where it is still important to have assigned 513 port numbers, largely to traverse either NATs or firewalls. Although 514 NAT traversal protocols supporting automatic configuration have been 515 proposed and developed (e.g., STUN [RFC5389], TURN [RFC5766], and 516 ICE [RFC5245]), application and service designers cannot yet rely on 517 their presence. 519 In the past, some services were assigned multiple port numbers or 520 sometimes fairly large port ranges (e.g., X11). This occurred for a 521 variety of reasons: port number conservation was not as widely 522 appreciated, assignments were not as ardently reviewed, etc. This no 523 longer reflects current practice and such assignments are not 524 considered to constitute a precedent for future assignments. 526 7.3. Picking an Assigned Port Number 528 Given a demonstrated need for a port number assignment, the next 529 question is how to pick the desired port number. An application for 530 a port number assignment does not need to include a desired port 531 number; in that case, IANA will select from those currently 532 available. 534 Users should consider whether the requested port number is 535 important. For example, would an assignment be acceptable if IANA 536 picked the port number value? Would a TCP (or other transport 537 protocol) port number assignment be useful by itself? If so, a port 538 number can be assigned to a service for one transport protocol where 539 it is already (or can be subsequently) assigned to a different 540 service for other transport protocols. 542 The most critical issue in picking a number is selecting the desired 543 range, i.e., System vs. User port numbers. The distinction was 544 intended to indicate a difference in privilege; originally, System 545 port numbers required privileged ('root') access, while User port 546 numbers did not. That distinction has since blurred because some 547 current systems do not limit access control to System port numbers 548 and because some System services have been replicated on User 549 numbers (e.g., IRC). Even so, System port number assignments have 550 continued at an average rate of 3-4 per year over the past 7 years 551 (2007-2013), indicating that the desire to keep this distinction 552 continues. 554 As a result, the difference between System and User port numbers 555 needs to be treated with caution. Developers are advised to treat 556 services as if they are always run without privilege. 558 Even when developers seek a System port number assignment, it may be 559 very difficult to obtain. System port number assignment requires 560 IETF Review or IESG Approval and justification that both User and 561 Dynamic port number ranges are insufficient [RFC6335]. Thus this 562 document recommends both: 564 >> Developers SHOULD NOT apply for System port number assignments 565 because the increased privilege they are intended to provide is not 566 always enforced. 568 >> System implementers SHOULD enforce the need for privilege for 569 processes to listen on System port numbers. 571 At some future date, it might be useful to deprecate the distinction 572 between System and User port numbers altogether. Services typically 573 require elevated ('root') privileges to bind to a System port 574 number, but many such services go to great lengths to immediately 575 drop those privileges just after connection or other association 576 establishment to reduce the impact of an attack using their 577 capabilities. Such services might be more securely operated on User 578 port numbers than on System port numbers. Further, if System port 579 numbers were no longer assigned, as of 2014 it would cost only 180 580 of the 1024 System values (17%), or 180 of the overall 49152 581 assigned (System and User) values (<0.04%). 583 7.4. Support for Security 585 Just as a service is a way to obtain information or processing from 586 a host over a network, a service can also be the opening through 587 which to compromise that host. Protecting a service involves 588 security, which includes integrity protection, source 589 authentication, privacy, or any combination of these capabilities. 590 Security can be provided in a number of ways: 592 >> New services SHOULD support security capabilities, either 593 directly or via a content protection such as TLS [RFC5246] or DTLS 594 [RFC6347] or transport protection such as TCP-AO [RFC5925]. Insecure 595 versions of new or existing secure services SHOULD be avoided 596 because of the new vulnerability they create. 598 >> When simultaneously requesting both secure and insecure port 599 assignments for the same service, strong justification is expected 600 for the utility and safety of a separate insecure assigned port 601 [RFC2595]. Precedent (citing other protocols that use an insecure 602 port) is not strong justification by itself. 604 It's also important to recognize that port number assignment is not 605 itself a guarantee that traffic using that number provides the 606 corresponding service, or that a given service is always offered 607 only on its assigned port number. Port numbers are ultimately 608 meaningful only between endpoints and any service can be run on any 609 port. Thus: 611 >> Security SHOULD NOT rely on assigned port number distinctions 612 alone; every service, whether secure or not, is likely to be 613 attacked. 615 There is debate as to how to secure legacy insecure services 616 [RFC6335]. Some argue that secure variants should share the existing 617 port number assignment, such that security is enabled on a per- 618 connection or other association basis [RFC2595] [RFC2817]. Others 619 argue that security should be supported on a new port number 620 assignment and be enabled by default. Either approach is currently 621 permitted. A separate port number might be important for security 622 coordination (e.g., firewall management), but this might further 623 argue for deprecation of the insecure variant. 625 Optional security can penalize performance, requiring additional 626 round-trip exchanges before a connection or other association can be 627 established. As discussed earlier, assigned port numbers are a 628 critical resource and it is inappropriate to consume assignments to 629 increase performance. As a result, the need for separate port 630 assignments for both secure and insecure variants is not justified 631 merely for performance - either for the performance of connection 632 establishment or association establishment, or for differences in 633 data performance between secure and insecure variants. 635 Note however that a new service might not be eligible for IANA 636 assignment of both an insecure and a secure variant of the same 637 service. In a similar way, applications requesting assignment for an 638 insecure port number for a secure service might not be appropriate. 639 In both cases, security of the service is compromised by adding the 640 insecure port number assignment. 642 7.5. Support for Future Versions 644 Requests for assigned port numbers are expected to support multiple 645 versions on the same assigned port number [RFC6335]. Versions are 646 typically indicated in-band, either at the beginning of a connection 647 or other association, or in each protocol message. 649 >> Version support SHOULD be included in new services rather than 650 relying on different port number assignments for different versions. 652 >> Version numbers SHOULD NOT be included in either the service name 653 or service description, to avoid the need to make additional port 654 number assignments for future variants of a service. 656 Again, the assigned port number space is far too limited to be used 657 as an indicator of protocol version or message type. Although this 658 has happened in the past (e.g., for NFS), it should be avoided in 659 new requests. 661 7.6. Transport Protocols 663 IANA assigns port numbers specific to one or more transport 664 protocols, typically UDP [RFC768] and TCP [RFC793], but also SCTP 665 [RFC4960], DCCP [RFC4340], and any other standard transport 666 protocol. Originally, IANA port number assignments were concurrent 667 for both UDP and TCP, and other transports were not indicated. 668 However, to conserve the assigned port number space and to reflect 669 increasing use of other transports, assignments are now specific 670 only to the transport being used. 672 In general, a service should request assignments for multiple 673 transports using the same service name and description on the same 674 port number only when they all reflect essentially the same service. 675 Good examples of such use are DNS and NFS, where the difference 676 between the UDP and TCP services are specific to supporting each 677 transport. E.g., the UDP variant of a service might add sequence 678 numbers and the TCP variant of the same service might add in-band 679 message delimiters. This document does not describe the appropriate 680 selection of a transport protocol for a service. 682 >> Service names and descriptions for multiple transport port number 683 assignments SHOULD match only when they describe the same service, 684 excepting only enhancements for each supported transport. 686 When the services differ, it may be acceptable or preferable to use 687 the same port number, but the service names and descriptions should 688 be different for each transport/service pair, reflecting the 689 differences in the services. E.g., if TCP is used for the basic 690 control protocol and UDP for an alarm protocol, then the services 691 might be "name-ctl" and "name-alarm". A common example is when TCP 692 is used for a service and UDP is used to determine whether that 693 service is active (e.g., via a unicast, broadcast, or multicast test 694 message) [RFC1122]. IANA has, for several years, used the suffix "- 695 disc" in service names to distinguish discovery services, such as 696 are used to identify endpoints capable of a given service: 698 >> Names of discovery services SHOULD use an identifiable suffix; 699 the suggestion is "-disc". 701 Some services are used for discovery, either in conjunction with a 702 TCP service or as a stand-alone capability. Such services will be 703 more reliable when using multicast rather than broadcast (over IPv4) 704 because IP routers do not forward "all nodes" broadcasts (all 1's, 705 i.e., 255.255.255.255 for IPv4) and have not been required to 706 support subnet-directed broadcasts since 1999 [RFC1812] [RFC2644]. 707 This issue is relevant only for IPv4 because IPv6 does not support 708 broadcast. 710 >> UDP over IPv4 multi-host services SHOULD use multicast rather 711 than broadcast. 713 Designers should be very careful in creating services over 714 transports that do not support congestion control or error recovery, 715 notably UDP. There are several issues that should be considered in 716 such cases, as summarized in Table 1 in [RFC5405]. In addition, the 717 following recommendations apply to service design: 719 >> Services that use multipoint communication SHOULD be scalable, 720 and SHOULD NOT rely solely on the efficiency of multicast 721 transmission for scalability. 723 >> Services SHOULD NOT use UDP as a performance enhancement over 724 TCP, e.g., to circumnavigate TCP's congestion control. 726 7.7. When to Request an Assignment 728 Assignments are typically requested when a user has enough 729 information to reasonably answer the questions in the IANA 730 application. IANA applications typically take up to a few weeks to 731 process, with some complex cases taking up to a month. The process 732 typically involves a few exchanges between the IANA Ports Expert 733 Review team and the applicant. 735 An application needs to include a description of the service, as 736 well as to address key questions designed to help IANA determine 737 whether the assignment is justified. The application should be 738 complete and not refer solely to the Internet Draft, RFC, a website, 739 or any other external documentation. 741 Services that are independently developed can be requested at any 742 time, but are typically best requested in the last stages of design 743 and initial experimentation, before any deployment has occurred that 744 cannot easily be updated. 746 >> Users MUST NOT deploy implementations that use assigned port 747 numbers prior their assignment by IANA. 749 >> Users MUST NOT deploy implementations that default to using the 750 experimental System port numbers (1021 and 1022 [RFC4727]) outside a 751 controlled environment where they can be updated with a subsequent 752 assigned port [RFC3692]. 754 Deployments that use unassigned port numbers before assignment 755 complicate IANA management of the port number space. Keep in mind 756 that this recommendation protects existing assignees, users of 757 current services, and applicants for new assignments; it helps 758 ensure that a desired number and service name are available when 759 assigned. The list of currently unassigned numbers is just that - 760 *currently* unassigned. It does not reflect pending applications. 761 Waiting for an official IANA assignment reduces the chance that an 762 assignment request will conflict with another deployed service. 764 Applications made through Internet Draft / RFC publication (in any 765 stream) typically use a placeholder ("PORTNUM") in the text, and 766 implementations use an experimental port number until a final 767 assignment has been made [RFC6335]. That assignment is initially 768 indicated in the IANA Considerations section of the document, which 769 is tracked by the RFC Editor. When a document has been approved for 770 publication, that request is forwarded to IANA for handling. IANA 771 will make the new assignment accordingly. At that time, IANA may 772 also request that the applicant fill out the application form on 773 their website, e.g., when the RFC does not directly address the 774 information expected as per [RFC6335]. "Early" assignments can be 775 made when justified, e.g., for early interoperability testing, 776 according to existing process [RFC7120] [RFC6335]. 778 >> Users writing specifications SHOULD use symbolic names for port 779 numbers and service names until an IANA assignment has been 780 completed. Implementations SHOULD use experimental port numbers 781 during this time, but those numbers MUST NOT be cited in 782 documentation except as interim. 784 7.8. Squatting 786 "Squatting" describes the use of a number from the assignable range 787 in deployed software without IANA assignment for that use, 788 regardless of whether the number has been assigned or remains 789 available for assignment. It is hazardous because IANA cannot track 790 such usage and thus cannot avoid making legitimate assignments that 791 conflict with such unauthorized usage. 793 Such "squatted" port numbers remain unassigned, and IANA retains the 794 right to assign them when requested by other applicants. Application 795 and service designers are reminded that is never appropriate to use 796 port numbers that have not been directly assigned [RFC6335]. In 797 particular, any unassigned code from the assigned ranges will be 798 assigned by IANA, and any conflict will be easily resolved as the 799 protocol designer's fault once that happens (because they would not 800 be the assignee). This may reflect in the public's judgment on the 801 quality of their expertise and cooperation with the Internet 802 community. 804 Regardless, there are numerous services that have squatted on such 805 numbers that are in widespread use. Designers who are using such 806 port numbers are encouraged to apply for an assignment. Note that 807 even widespread de-facto use may not justify a later IANA assignment 808 of that value, especially if either the value has already been 809 assigned to a legitimate applicant or if the service would not 810 qualify for an assignment of its own accord. 812 7.9. Other Considerations 814 As noted earlier, System port numbers should be used sparingly, and 815 it is better to avoid them altogether. This avoids the potentially 816 incorrect assumption that the service on such port numbers run in a 817 privileged mode. 819 Assigned port numbers are not intended to be changed; this includes 820 the corresponding service name. Once deployed, it can be very 821 difficult to recall every implementation, so the assignment should 822 be retained. However, in cases where the current assignee of a name 823 or number has reasonable knowledge of the impact on such uses, and 824 is willing to accept that impact, the name or number of an 825 assignment can be changed [RFC6335] 827 Aliases, or multiple service names for the same assigned port 828 number, are no longer considered appropriate [RFC6335]. 830 8. Security Considerations 832 This document discusses ways to conserve assigned port numbers, 833 notably through encouraging demultiplexing within a single port 834 number. As such, there may be cases where two variants of a 835 protocol - insecure and secure (such as using optional TLS or DTLS) 836 or different versions - are suggested to share the same assigned 837 port number. 839 The use of TLS [RFC5246], DTLS [RFC6347], or TCP-AO [RFC5925] that 840 protect transport protocols or their contents is encouraged. It may 841 not be possible to use IPsec [RFC4301] in similar ways because of 842 the different relationship between IPsec and port numbers and 843 because applications may not be aware of IPsec protections. 845 This document reminds application and service designers that port 846 numbers do not protect against denial of service attack or guarantee 847 that traffic should be trusted. Using assigned numbers for port 848 filtering isn't a substitute for authentication, encryption, and 849 integrity protection. The port number alone should not be used to 850 avoid denial of service attacks or to manage firewall traffic 851 because the use of port numbers is not regulated or validated. 853 The use of assigned port numbers is the antithesis of privacy 854 because they are intended to explicitly indicate the desired 855 application or service. Strictly, port numbers are meaningful only 856 at the endpoints, so any interpretation elsewhere in the network can 857 be arbitrarily incorrect. However, those numbers can also expose 858 information about available services on a given host. This 859 information can be used by intermediate devices to monitor and 860 intercept traffic as well as to potentially identify key endpoint 861 software properties ("fingerprinting"), which can be used to direct 862 other attacks. 864 9. IANA Considerations 866 The entirety of this document focuses on suggestions that help 867 ensure the conservation of port numbers and provide useful hints for 868 issuing informative requests thereof. 870 10. References 872 10.1. Normative References 874 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 875 Requirement Levels", BCP 14, RFC 2119, March 1997. 877 [RFC2780] Bradner, S., and V. Paxson, "IANA Allocation Guidelines 878 For Values In the Internet Protocol and Related Headers", 879 BCP 37, RFC 2780, March 2000. 881 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 882 Considered Useful", BCP 82, RFC 3962, Jan. 2004. 884 [RFC4727] Fenner, B., "Experimental Values in IPv4, IPv6, ICMPv4, 885 ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 887 [RFC5246] Dierks, T., and E. Rescorla, "The Transport Layer Security 888 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 890 [RFC5405] Eggert, L., and G. Fairhurst, "Unicast UDP Usage 891 Guidelines for Application Designers", BCP 145, RFC 5405, 892 Nov. 2008. 894 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 895 Authentication Option", RFC 5925, June 2010. 897 [RFC6335] Cotton, M., L. Eggert, J. Touch, M. Westerlund, and S. 898 Cheshire, "Internet Assigned Numbers Authority (IANA) 899 Procedures for the Management of the Service Name and 900 Transport Protocol Port Number Registry", BCP 165, RFC 901 6335, August 2011. 903 [RFC6347] Rescorla, E., and N. Modadugu, "Datagram Transport Layer 904 Security Version 1.2", RFC 6347, January 2012. 906 10.2. Informative References 908 [IEN112] Postel, J., "Transmission Control Protocol", IEN 112, 909 August 1979. 911 [RFC33] Crocker, S., "New Host-Host Protocol", RFC 33 February 912 1970. 914 [RFC37] Crocker, S., "Network Meeting Epilogue", RFC 37, March 915 1970. 917 [RFC38] Wolfe, S., "Comments on Network Protocol from NWG/RFC 918 #36", RFC 38, March 1970. 920 [RFC48] Postel, J., and S. Crocker, "Possible protocol plateau", 921 RFC 48, April 1970. 923 [RFC61] Walden, D., "Note on Interprocess Communication in a 924 Resource Sharing Computer Network", RFC 61, July 1970. 926 [RFC76] Bouknight, J., J. Madden, and G. Grossman, "Connection by 927 name: User oriented protocol", RFC 76, October 1970. 929 [RFC333] Bressler, R., D. Murphy, and D. Walden. "Proposed 930 experiment with a Message Switching Protocol", RFC 333, 931 May 1972. 933 [RFC739] Postel, J., "Assigned numbers", RFC 739, November 1977. 935 [RFC758] Postel, J., "Assigned numbers", RFC 758, August 1979. 937 [RFC768] Postel, J., "User Datagram Protocol", RFC 768, August 938 1980. 940 [RFC793] Postel, J., "Transmission Control Protocol" RFC 793, 941 September 1981 943 [RFC820] Postel, J., "Assigned numbers", RFC 820, August 1982. 945 [RFC900] Reynolds, J., and J. Postel, "Assigned numbers", RFC 900, 946 June 1984. 948 [RFC959] Postel, J., and J. Reynolds, "FILE TRANSFER PROTOCOL 949 (FTP)", RFC 959, October 1985. 951 [RFC1122] Braden, B. (Ed.), "Requirements for Internet Hosts -- 952 Communication Layers", RFC 1122, October 1989. 954 [RFC1340] Reynolds, J., and J. Postel, "Assigned numbers", RFC 1340, 955 July 1992. 957 [RFC1700] Reynolds, J., and J. Postel, "Assigned numbers", RFC 1700, 958 October 1994. 960 [RFC1812] Baker, F. (Ed.), "Requirements for IP Version 4 Routers", 961 RFC 1812, June 1995. 963 [RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", 964 RFC 1833, August 1995. 966 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 967 2595, June 1999. 969 [RFC2644] Senie, D., "Changing the Default for Directed Broadcasts 970 in Routers", RFC 2644, August 1999. 972 [RFC2817] Khare, R., and S. Lawrence, "Upgrading to TLS Within 973 HTTP/1.1", RFC 2817, May 2000. 975 [RFC3232] Reynolds, J. (Ed.), "Assigned Numbers: RFC 1700 is 976 Replaced by an On-line Database", RFC 3232, January 2002. 978 [RFC3261] Rosenberg, J., H. Schulzrinne, G. Camarillo, A. Johnston, 979 J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: 980 Session Initiation Protocol", RFC 3261, June 2002. 982 [RFC4301] Kent, S., and K. Seo, "Security Architecture for the 983 Internet Protocol", RFC 4301, December 2005. 985 [RFC4340] Kohler, E., M. Handley, and S. Floyd, "Datagram Congestion 986 Control Protocol (DCCP)", RFC 4340, March 2006. 988 [RFC4960] Stewart, R. (Ed.), "Stream Control Transmission Protocol", 989 RFC 4960, September 2007. 991 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 992 (ICE): A Protocol for Network Address Translator (NAT) 993 Traversal for Offer/Answer Protocols", RFC 5245, April 994 2010. 996 [RFC5389] Rosenberg, J., R. Mahy, P. Matthews, and D. Wing, "Session 997 Traversal Utilities for NAT", RFC 5389, October 2008. 999 [RFC5766] Mahy, R., P. Matthews, and J. Rosenberg, "Traversal Using 1000 Relays around NAT (TURN): Relay Extensions to Session 1001 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 1003 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1004 Extensions: Extension Definitions", RFC 6066, January 1005 2011. 1007 [RFC6762] Cheshire, S., and M. Krochmal, "Multicast DNS", RFC 6762, 1008 February 2013. 1010 [RFC6763] Cheshire, S., and M. Krochmal, "DNS-Based Service 1011 Discovery", RFC 6763, February 2013. 1013 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 1014 Points", BCP 100, RFC 7120, January 2014. 1016 [RFC7230] Fielding, R., (Ed.), and J. Reshke, (Ed.), "Hypertext 1017 Transfer Protocol (HTTP/1.1): Message Syntax and Routing", 1018 RFC 7230, June 2014. 1020 11. Acknowledgments 1022 This work benefitted from the feedback from David Black, Lars 1023 Eggert, Gorry Fairhurst, and Eliot Lear, as well as discussions of 1024 the IETF TSVWG WG. 1026 This document was prepared using 2-Word-v2.0.template.dot. 1028 Authors' Addresses 1030 Joe Touch 1031 USC/ISI 1032 4676 Admiralty Way 1033 Marina del Rey, CA 90292-6695 1034 U.S.A. 1036 Phone: +1 (310) 448-9151 1037 EMail: touch@isi.edu