idnits 2.17.1 draft-ietf-tsvwg-port-use-11.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 (April 24, 2015) is 3289 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 April 24, 2015 4 Expires: October 2015 6 Recommendations on Using Assigned Transport Port Numbers 7 draft-ietf-tsvwg-port-use-11.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 October 24, 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 port number 260 assignment by IANA - to have a common agreement between all 261 endpoints on the Internet as to the default meaning of a port 262 number, which provides the endpoints with a default port number for 263 a particular 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 may also have the effect of simplifying 284 firewall management, so that a single, fixed firewall configuration 285 can either permit or deny a service that uses the assigned ports. 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 some existing services can be differentiated using 341 in-band information (e.g., URIs in HTTP Host field and TLS 342 Server Name Indication extension) [RFC7230] [RFC6066]. 344 o Services requiring varying performance properties can already 345 be supported using separate endpoint associations (connections 346 or other associations), each configured to support the desired 347 properties. E.g., a high-speed and low-speed variant can be 348 determined within the service using the same assigned port. 350 Assigned port numbers are intended to differentiate services, not 351 variations of performance, replicas, pairwise endpoint associations, 352 or payload types. Assigned port numbers are also a small space 353 compared to other Internet number spaces; it is never appropriate to 354 consume assigned port numbers to conserve larger spaces such as IP 355 addresses, especially where copies of a service represent different 356 endpoints. 358 6.2. Firewall and NAT Considerations 360 Ultimately, port numbers numbers indicate services only to the 361 endpoints, and any intermediate device that assigns meaning to a 362 value can be incorrect. End systems might agree to run web services 363 (HTTP) over port number 53 (typically used for DNS) rather than port 364 number 80, at which point a firewall that blocks port number 80 but 365 permits port number 53 would not have the desired effect. 366 Nonetheless, assigned port numbers are often used to help configure 367 firewalls and other port-based systems for access control. 369 Using Dynamic port numbers, or explicitly-indicated port numbers 370 indicated in-band over another service (such as with FTP) often 371 complicates firewall and NAT interactions [RFC959]. FTP over 372 firewalls often requires direct support for deep-packet inspection 373 (to snoop for the Dynamic port number for the NAT to correctly map) 374 or passive-mode FTP (in which both connections are opened from the 375 client side). 377 7. Considerations for Requesting Port Number Assignments 379 Port numbers are assigned by IANA by a set of documented procedures 380 [RFC6335]. The following section describes the steps users can take 381 to help assist with responsible use of assigned port numbers, and 382 with preparing an application for a port number assignment. 384 7.1. Is a port number assignment necessary? 386 First, it is useful to consider whether a port number assignment is 387 required. In many cases, a new number assignment may not be needed, 388 for example: 390 o Is this really a new service, or can an existing service 391 suffice? 393 o Is this an experimental service [RFC3692]? If so, consider 394 using the current experimental ports [RFC2780]. 396 o Is this service independently useful? Some systems are 397 composed from collections of different service capabilities, 398 but not all component functions are useful as independent 399 services. Port numbers are typically shared among the smallest 400 independently-useful set of functions. Different service uses 401 or properties can be supported in separate pairwise endpoint 402 associations after an initial negotiation, e.g., to support 403 software decomposition. 405 o Can this service use a Dynamic port number that is coordinated 406 out-of-band, e.g.: 408 o By explicit configuration of both endpoints. 410 o By internal mechanisms within the same host (e.g., a 411 configuration file, indicated within a URI, or using 412 interprocess communication). 414 o Using information exchanged on a related service: FTP, SIP, 415 etc. [RFC959] [RFC3261]. 417 o Using an existing port discovery service: portmapper, mDNS, 418 etc. [RFC1833] [RFC6762] [RFC6763]. 420 There are a few good examples of reasons that more directly suggest 421 that not only is a port number assignment not necessary, but it is 422 directly counter-indicated: 424 o Assigned port numbers are not intended to differentiate 425 performance variations within the same service, e.g., high- 426 speed vs. ordinary speed. Performance variations can be 427 supported within a single assigned port number in context of 428 separate pairwise endpoint associations. 430 o Additional assigned port numbers are not intended to replicate 431 an existing service. For example, if a device is configured to 432 use a typical web browser then it the port number used for 433 that service is a copy of the http service that is already 434 assigned to port number 80 and does not warrant a new 435 assignment. However, an automated system that happens to use 436 HTTP framing - but is not primarily accessed by a browser - 437 might be a new service. A good way to tell is "can an 438 unmodified client of the existing service interact with the 439 proposed service"? If so, that service would be a copy of an 440 existing service and would not merit a new assignment. 442 o Assigned port numbers not intended for intra-machine 443 communication. Such communication can already be supported by 444 internal mechanisms (interprocess communication, shared 445 memory, shared files, etc.). When Internet communication 446 within a host is desired, the server can bind to a Dynamic 447 port that is indicated to the client using these internal 448 mechanisms. 450 o Separate assigned port numbers are not intended for insecure 451 versions of existing (or new) secure services. A service that 452 already requires security would be made more vulnerable by 453 having the same capability accessible without security. 455 Note that the converse is different, i.e., it can be useful to 456 create a new, secure service that replicates an existing 457 insecure service on a new port number assignment. This can be 458 necessary when the existing service is not backward-compatible 459 with security enhancements, such as the use of TLS [RFC5246] 460 or DTLS [RFC6347]. 462 o Assigned port numbers are not intended for indicating 463 different service versions. Version differentiation should be 464 handled in-band, e.g., using a version number at the beginning 465 of an association (e.g., connection or other transaction). 466 This may not be possible with legacy assignments, but all new 467 services should incorporate support for version indication. 469 Some services may not need assigned port numbers at all, e.g., SIP 470 allows voice calls to use Dynamic ports [RFC3261]. Some systems can 471 register services in the DNS, using SRV entries. These services can 472 be discovered by a variety of means, including mDNS, or via direct 473 query [RFC6762] [RFC6763]. In such cases, users can more easily 474 request a SRV name, which are assigned first-come, first-served from 475 a much larger namespace. 477 IANA assigns port numbers, but this assignment is typically used 478 only for servers, i.e., the host that listens for incoming 479 connections or other associations. Clients, i.e., hosts that 480 initiate connections or other associations, typically refer to those 481 assigned port numbers but do not need port number assignments for 482 their endpoint. 484 Finally, an assigned port number is not a guarantee of exclusive 485 use. Traffic for any service might appear on any port number, due to 486 misconfiguration or deliberate misuse. Application and service 487 designers are encouraged to validate traffic based on its content. 489 7.2. How Many Assigned Port Numbers? 491 As noted earlier, systems might require a single port number 492 assignment, but rarely require multiple port numbers. There are a 493 variety of known ways to reduce assigned port number consumption. 494 Although some may be cumbersome or inefficient, they are nearly 495 always preferable to consuming additional port number assignments. 497 Such techniques include: 499 o Use of a discovery service, either a shared service (mDNS), or 500 a discovery service for a given system [RFC6762] [RFC6763]. 502 o Multiplex packet types using in-band information, either on a 503 per-message or per-connection basis. Such demultiplexing can 504 even hand-off different messages and connections among 505 different processes, such as is done with FTP [RFC959]. 507 There are some cases where NAT and firewall traversal are 508 significantly improved by having an assigned port number. Although 509 NAT traversal protocols supporting automatic configuration have been 510 proposed and developed (e.g., STUN [RFC5389], TURN [RFC5766], and 511 ICE [RFC5245]), not all application and service designers can rely 512 on their presence as of yet. 514 In the past, some services were assigned multiple port numbers or 515 sometimes fairly large port ranges (e.g., X11). This occurred for a 516 variety of reasons: port number conservation was not as widely 517 appreciated, assignments were not as ardently reviewed, etc. This no 518 longer reflects current practice and such assignments are not 519 considered to constitute a precedent for future assignments. 521 7.3. Picking an Assigned Port Number 523 Given a demonstrated need for a port number assignment, the next 524 question is how to pick the desired port number. An application for 525 a port number assignment does not need to include a desired port 526 number; in that case, IANA will select from those currently 527 available. 529 Users should consider whether the requested port number is 530 important. For example, would an assignment be acceptable if IANA 531 picked the port number value? Would a TCP (or other transport 532 protocol) port number assignment be useful by itself? If so, a port 533 number can be assigned to a service for one transport protocol where 534 it is already (or can be subsequently) assigned to a different 535 service for other transport protocols. 537 The most critical issue in picking a number is selecting the desired 538 range, i.e., System vs. User port numbers. The distinction was 539 intended to indicate a difference in privilege; originally, System 540 port numbers required privileged ('root') access, while User port 541 numbers did not. That distinction has since blurred because some 542 current systems do not limit access control to System port numbers 543 and because some System services have been replicated on User 544 numbers (e.g., IRC). Even so, System port number assignments have 545 continued at an average rate of 3-4 per year over the past 7 years 546 (2007-2013), indicating that the desire to keep this distinction 547 continues. 549 As a result, the difference between System and User port numbers 550 needs to be treated with caution. Developers are advised to treat 551 services as if they are always run without privilege. 553 Even when developers seek a System port number assignment, it may be 554 very difficult to obtain. System port number assignment requires 555 IETF Review or IESG Approval and justification that both User and 556 Dynamic port number ranges are insufficient [RFC6335]. Thus this 557 document recommends both: 559 >> Developers SHOULD NOT apply for System port number assignments 560 because the increased privilege they are intended to provide is not 561 always enforced. 563 >> System implementers SHOULD enforce the need for privilege for 564 processes to listen on System port numbers. 566 At some future date, it might be useful to deprecate the distinction 567 between System and User port numbers altogether. Services typically 568 require elevated ('root') privileges to bind to a System port 569 number, but many such services go to great lengths to immediately 570 drop those privileges just after connection or other association 571 establishment to reduce the impact of an attack using their 572 capabilities. Such services might be more securely operated on User 573 port numbers than on System port numbers. Further, if System port 574 numbers were no longer assigned, as of 2014 it would cost only 180 575 of the 1024 System values (17%), or 180 of the overall 49152 576 assigned (System and User) values (<0.04%). 578 7.4. Support for Security 580 Just as a service is a way to obtain information or processing from 581 a host over a network, a service can also be the opening through 582 which to compromise that host. Protecting a service involves 583 security, which includes integrity protection, source 584 authentication, privacy, or any combination of these capabilities. 585 Security can be provided in a number of ways, and thus: 587 >> New services SHOULD support security capabilities, either 588 directly or via a content protection such as TLS [RFC5246] or DTLS 589 [RFC6347] or transport protection such as TCP-AO [RFC5925]. Insecure 590 versions of new or existing secure services SHOULD be avoided 591 because of the new vulnerability they create. 593 Secure versions of legacy services that are not already security- 594 capable via in-band negotiations can be very useful. However, there 595 is no IETF consensus on when separate ports should be used for 596 secure and insecure variants of the same service [RFC2595] [RFC2817] 597 [RFC6335]. The overall preference is for use of a single port, as 598 noted in Section 6 of this document and Section 7.2 of [RFC6335], 599 but the appropriate approach depends on the specific characteristics 600 of the service. As a result: 602 >> When requesting both secure and insecure port assignments for the 603 same service, justification is expected for the utility and safety 604 of each port as an independent service (Section 6). Precedent (e.g., 605 citing other protocols that use a separate insecure port) is 606 inadequate justification by itself. 608 It's also important to recognize that port number assignment is not 609 itself a guarantee that traffic using that number provides the 610 corresponding service, or that a given service is always offered 611 only on its assigned port number. Port numbers are ultimately 612 meaningful only between endpoints and any service can be run on any 613 port. Thus: 615 >> Security SHOULD NOT rely on assigned port number distinctions 616 alone; every service, whether secure or not, is likely to be 617 attacked. 619 Applications for a new service that requires both a secure and 620 insecure port may be found, on expert review, to be unacceptable, 621 and may not be approved for allocation. Similarly, an application 622 for a new port to support an insecure variant of an existing secure 623 protocol may be found unacceptable. In both cases, the resulting 624 security of the service in practice will be a significant 625 consideration in the decision as to whether to assign an insecure 626 port. 628 7.5. Support for Future Versions 630 Requests for assigned port numbers are expected to support multiple 631 versions on the same assigned port number [RFC6335]. Versions are 632 typically indicated in-band, either at the beginning of a connection 633 or other association, or in each protocol message. 635 >> Version support SHOULD be included in new services rather than 636 relying on different port number assignments for different versions. 638 >> Version numbers SHOULD NOT be included in either the service name 639 or service description, to avoid the need to make additional port 640 number assignments for future variants of a service. 642 Again, the assigned port number space is far too limited to be used 643 as an indicator of protocol version or message type. Although this 644 has happened in the past (e.g., for NFS), it should be avoided in 645 new requests. 647 7.6. Transport Protocols 649 IANA assigns port numbers specific to one or more transport 650 protocols, typically UDP [RFC768] and TCP [RFC793], but also SCTP 651 [RFC4960], DCCP [RFC4340], and any other standard transport 652 protocol. Originally, IANA port number assignments were concurrent 653 for both UDP and TCP, and other transports were not indicated. 654 However, to conserve the assigned port number space and to reflect 655 increasing use of other transports, assignments are now specific 656 only to the transport being used. 658 In general, a service should request assignments for multiple 659 transports using the same service name and description on the same 660 port number only when they all reflect essentially the same service. 661 Good examples of such use are DNS and NFS, where the difference 662 between the UDP and TCP services are specific to supporting each 663 transport. E.g., the UDP variant of a service might add sequence 664 numbers and the TCP variant of the same service might add in-band 665 message delimiters. This document does not describe the appropriate 666 selection of a transport protocol for a service. 668 >> Service names and descriptions for multiple transport port number 669 assignments SHOULD match only when they describe the same service, 670 excepting only enhancements for each supported transport. 672 When the services differ, it may be acceptable or preferable to use 673 the same port number, but the service names and descriptions should 674 be different for each transport/service pair, reflecting the 675 differences in the services. E.g., if TCP is used for the basic 676 control protocol and UDP for an alarm protocol, then the services 677 might be "name-ctl" and "name-alarm". A common example is when TCP 678 is used for a service and UDP is used to determine whether that 679 service is active (e.g., via a unicast, broadcast, or multicast test 680 message) [RFC1122]. IANA has, for several years, used the suffix "- 681 disc" in service names to distinguish discovery services, such as 682 are used to identify endpoints capable of a given service: 684 >> Names of discovery services SHOULD use an identifiable suffix; 685 the suggestion is "-disc". 687 Some services are used for discovery, either in conjunction with a 688 TCP service or as a stand-alone capability. Such services will be 689 more reliable when using multicast rather than broadcast (over IPv4) 690 because IP routers do not forward "all nodes" broadcasts (all 1's, 691 i.e., 255.255.255.255 for IPv4) and have not been required to 692 support subnet-directed broadcasts since 1999 [RFC1812] [RFC2644]. 694 This issue is relevant only for IPv4 because IPv6 does not support 695 broadcast. 697 >> UDP over IPv4 multi-host services SHOULD use multicast rather 698 than broadcast. 700 Designers should be very careful in creating services over 701 transports that do not support congestion control or error recovery, 702 notably UDP. There are several issues that should be considered in 703 such cases, as summarized in Table 1 in [RFC5405]. In addition, the 704 following recommendations apply to service design: 706 >> Services that use multipoint communication SHOULD be scalable, 707 and SHOULD NOT rely solely on the efficiency of multicast 708 transmission for scalability. 710 >> Services SHOULD NOT use UDP as a performance enhancement over 711 TCP, e.g., to circumnavigate TCP's congestion control. 713 7.7. When to Request an Assignment 715 Assignments are typically requested when a user has enough 716 information to reasonably answer the questions in the IANA 717 application. IANA applications typically take up to a few weeks to 718 process, with some complex cases taking up to a month. The process 719 typically involves a few exchanges between the IANA Ports Expert 720 Review team and the applicant. 722 An application needs to include a description of the service, as 723 well as to address key questions designed to help IANA determine 724 whether the assignment is justified. The application should be 725 complete and not refer solely to the Internet Draft, RFC, a website, 726 or any other external documentation. 728 Services that are independently developed can be requested at any 729 time, but are typically best requested in the last stages of design 730 and initial experimentation, before any deployment has occurred that 731 cannot easily be updated. 733 >> Users MUST NOT deploy implementations that use assigned port 734 numbers prior their assignment by IANA. 736 >> Users MUST NOT deploy implementations that default to using the 737 experimental System port numbers (1021 and 1022 [RFC4727]) outside a 738 controlled environment where they can be updated with a subsequent 739 assigned port [RFC3692]. 741 Deployments that use unassigned port numbers before assignment 742 complicate IANA management of the port number space. Keep in mind 743 that this recommendation protects existing assignees, users of 744 current services, and applicants for new assignments; it helps 745 ensure that a desired number and service name are available when 746 assigned. The list of currently unassigned numbers is just that - 747 *currently* unassigned. It does not reflect pending applications. 748 Waiting for an official IANA assignment reduces the chance that an 749 assignment request will conflict with another deployed service. 751 Applications made through Internet Draft / RFC publication (in any 752 stream) typically use a placeholder ("PORTNUM") in the text, and 753 implementations use an experimental port number until a final 754 assignment has been made [RFC6335]. That assignment is initially 755 indicated in the IANA Considerations section of the document, which 756 is tracked by the RFC Editor. When a document has been approved for 757 publication, that request is forwarded to IANA for handling. IANA 758 will make the new assignment accordingly. At that time, IANA may 759 also request that the applicant fill out the application form on 760 their website, e.g., when the RFC does not directly address the 761 information expected as per [RFC6335]. "Early" assignments can be 762 made when justified, e.g., for early interoperability testing, 763 according to existing process [RFC7120] [RFC6335]. 765 >> Users writing specifications SHOULD use symbolic names for port 766 numbers and service names until an IANA assignment has been 767 completed. Implementations SHOULD use experimental port numbers 768 during this time, but those numbers MUST NOT be cited in 769 documentation except as interim. 771 7.8. Squatting 773 "Squatting" describes the use of a number from the assignable range 774 in deployed software without IANA assignment for that use, 775 regardless of whether the number has been assigned or remains 776 available for assignment. It is hazardous because IANA cannot track 777 such usage and thus cannot avoid making legitimate assignments that 778 conflict with such unauthorized usage. 780 Such "squatted" port numbers remain unassigned, and IANA retains the 781 right to assign them when requested by other applicants. Application 782 and service designers are reminded that is never appropriate to use 783 port numbers that have not been directly assigned [RFC6335]. In 784 particular, any unassigned code from the assigned ranges will be 785 assigned by IANA, and any conflict will be easily resolved as the 786 protocol designer's fault once that happens (because they would not 787 be the assignee). This may reflect in the public's judgment on the 788 quality of their expertise and cooperation with the Internet 789 community. 791 Regardless, there are numerous services that have squatted on such 792 numbers that are in widespread use. Designers who are using such 793 port numbers are encouraged to apply for an assignment. Note that 794 even widespread de-facto use may not justify a later IANA assignment 795 of that value, especially if either the value has already been 796 assigned to a legitimate applicant or if the service would not 797 qualify for an assignment of its own accord. 799 7.9. Other Considerations 801 As noted earlier, System port numbers should be used sparingly, and 802 it is better to avoid them altogether. This avoids the potentially 803 incorrect assumption that the service on such port numbers run in a 804 privileged mode. 806 Assigned port numbers are not intended to be changed; this includes 807 the corresponding service name. Once deployed, it can be very 808 difficult to recall every implementation, so the assignment should 809 be retained. However, in cases where the current assignee of a name 810 or number has reasonable knowledge of the impact on such uses, and 811 is willing to accept that impact, the name or number of an 812 assignment can be changed [RFC6335] 814 Aliases, or multiple service names for the same assigned port 815 number, are no longer considered appropriate [RFC6335]. 817 8. Security Considerations 819 This document focuses on the issues arising when designing services 820 that require new port assignments. Section 7.4 addresses the 821 security and security-related issues of that interaction. 823 When designing a secure service, the use of TLS [RFC5246], DTLS 824 [RFC6347], or TCP-AO [RFC5925] mechanisms that protect transport 825 protocols or their contents is encouraged. It may not be possible to 826 use IPsec [RFC4301] in similar ways because of the different 827 relationship between IPsec and port numbers and because applications 828 may not be aware of IPsec protections. 830 This document reminds application and service designers that port 831 numbers do not protect against denial of service attack or guarantee 832 that traffic should be trusted. Using assigned numbers for port 833 filtering isn't a substitute for authentication, encryption, and 834 integrity protection. The port number alone should not be used to 835 avoid denial of service attacks or to manage firewall traffic 836 because the use of port numbers is not regulated or validated. 838 The use of assigned port numbers is the antithesis of privacy 839 because they are intended to explicitly indicate the desired 840 application or service. Strictly, port numbers are meaningful only 841 at the endpoints, so any interpretation elsewhere in the network can 842 be arbitrarily incorrect. However, those numbers can also expose 843 information about available services on a given host. This 844 information can be used by intermediate devices to monitor and 845 intercept traffic as well as to potentially identify key endpoint 846 software properties ("fingerprinting"), which can be used to direct 847 other attacks. 849 9. IANA Considerations 851 The entirety of this document focuses on suggestions that help 852 ensure the conservation of port numbers and provide useful hints for 853 issuing informative requests thereof. 855 10. References 857 10.1. Normative References 859 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 860 Requirement Levels", BCP 14, RFC 2119, March 1997. 862 [RFC2780] Bradner, S., and V. Paxson, "IANA Allocation Guidelines 863 For Values In the Internet Protocol and Related Headers", 864 BCP 37, RFC 2780, March 2000. 866 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 867 Considered Useful", BCP 82, RFC 3962, Jan. 2004. 869 [RFC4727] Fenner, B., "Experimental Values in IPv4, IPv6, ICMPv4, 870 ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 872 [RFC5246] Dierks, T., and E. Rescorla, "The Transport Layer Security 873 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 875 [RFC5405] Eggert, L., and G. Fairhurst, "Unicast UDP Usage 876 Guidelines for Application Designers", BCP 145, RFC 5405, 877 Nov. 2008. 879 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 880 Authentication Option", RFC 5925, June 2010. 882 [RFC6335] Cotton, M., L. Eggert, J. Touch, M. Westerlund, and S. 883 Cheshire, "Internet Assigned Numbers Authority (IANA) 884 Procedures for the Management of the Service Name and 885 Transport Protocol Port Number Registry", BCP 165, RFC 886 6335, August 2011. 888 [RFC6347] Rescorla, E., and N. Modadugu, "Datagram Transport Layer 889 Security Version 1.2", RFC 6347, January 2012. 891 10.2. Informative References 893 [IEN112] Postel, J., "Transmission Control Protocol", IEN 112, 894 August 1979. 896 [RFC33] Crocker, S., "New Host-Host Protocol", RFC 33 February 897 1970. 899 [RFC37] Crocker, S., "Network Meeting Epilogue", RFC 37, March 900 1970. 902 [RFC38] Wolfe, S., "Comments on Network Protocol from NWG/RFC 903 #36", RFC 38, March 1970. 905 [RFC48] Postel, J., and S. Crocker, "Possible protocol plateau", 906 RFC 48, April 1970. 908 [RFC61] Walden, D., "Note on Interprocess Communication in a 909 Resource Sharing Computer Network", RFC 61, July 1970. 911 [RFC76] Bouknight, J., J. Madden, and G. Grossman, "Connection by 912 name: User oriented protocol", RFC 76, October 1970. 914 [RFC333] Bressler, R., D. Murphy, and D. Walden. "Proposed 915 experiment with a Message Switching Protocol", RFC 333, 916 May 1972. 918 [RFC739] Postel, J., "Assigned numbers", RFC 739, November 1977. 920 [RFC758] Postel, J., "Assigned numbers", RFC 758, August 1979. 922 [RFC768] Postel, J., "User Datagram Protocol", RFC 768, August 923 1980. 925 [RFC793] Postel, J., "Transmission Control Protocol" RFC 793, 926 September 1981 928 [RFC820] Postel, J., "Assigned numbers", RFC 820, August 1982. 930 [RFC900] Reynolds, J., and J. Postel, "Assigned numbers", RFC 900, 931 June 1984. 933 [RFC959] Postel, J., and J. Reynolds, "FILE TRANSFER PROTOCOL 934 (FTP)", RFC 959, October 1985. 936 [RFC1122] Braden, B. (Ed.), "Requirements for Internet Hosts -- 937 Communication Layers", RFC 1122, October 1989. 939 [RFC1340] Reynolds, J., and J. Postel, "Assigned numbers", RFC 1340, 940 July 1992. 942 [RFC1700] Reynolds, J., and J. Postel, "Assigned numbers", RFC 1700, 943 October 1994. 945 [RFC1812] Baker, F. (Ed.), "Requirements for IP Version 4 Routers", 946 RFC 1812, June 1995. 948 [RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", 949 RFC 1833, August 1995. 951 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 952 2595, June 1999. 954 [RFC2644] Senie, D., "Changing the Default for Directed Broadcasts 955 in Routers", RFC 2644, August 1999. 957 [RFC2817] Khare, R., and S. Lawrence, "Upgrading to TLS Within 958 HTTP/1.1", RFC 2817, May 2000. 960 [RFC3232] Reynolds, J. (Ed.), "Assigned Numbers: RFC 1700 is 961 Replaced by an On-line Database", RFC 3232, January 2002. 963 [RFC3261] Rosenberg, J., H. Schulzrinne, G. Camarillo, A. Johnston, 964 J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: 965 Session Initiation Protocol", RFC 3261, June 2002. 967 [RFC4301] Kent, S., and K. Seo, "Security Architecture for the 968 Internet Protocol", RFC 4301, December 2005. 970 [RFC4340] Kohler, E., M. Handley, and S. Floyd, "Datagram Congestion 971 Control Protocol (DCCP)", RFC 4340, March 2006. 973 [RFC4960] Stewart, R. (Ed.), "Stream Control Transmission Protocol", 974 RFC 4960, September 2007. 976 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 977 (ICE): A Protocol for Network Address Translator (NAT) 978 Traversal for Offer/Answer Protocols", RFC 5245, April 979 2010. 981 [RFC5389] Rosenberg, J., R. Mahy, P. Matthews, and D. Wing, "Session 982 Traversal Utilities for NAT", RFC 5389, October 2008. 984 [RFC5766] Mahy, R., P. Matthews, and J. Rosenberg, "Traversal Using 985 Relays around NAT (TURN): Relay Extensions to Session 986 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 988 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 989 Extensions: Extension Definitions", RFC 6066, January 990 2011. 992 [RFC6762] Cheshire, S., and M. Krochmal, "Multicast DNS", RFC 6762, 993 February 2013. 995 [RFC6763] Cheshire, S., and M. Krochmal, "DNS-Based Service 996 Discovery", RFC 6763, February 2013. 998 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 999 Points", BCP 100, RFC 7120, January 2014. 1001 [RFC7230] Fielding, R., (Ed.), and J. Reshke, (Ed.), "Hypertext 1002 Transfer Protocol (HTTP/1.1): Message Syntax and Routing", 1003 RFC 7230, June 2014. 1005 11. Acknowledgments 1007 This work benefitted from the feedback from David Black, Lars 1008 Eggert, Gorry Fairhurst, and Eliot Lear, as well as discussions of 1009 the IETF TSVWG WG. 1011 This document was prepared using 2-Word-v2.0.template.dot. 1013 Authors' Addresses 1015 Joe Touch 1016 USC/ISI 1017 4676 Admiralty Way 1018 Marina del Rey, CA 90292-6695 1019 U.S.A. 1021 Phone: +1 (310) 448-9151 1022 EMail: touch@isi.edu