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