TSVWG J. Touch Internet Draft USC/ISI Intended status: Best Current Practice May 30, 2012 Expires: November 2012 Recommendations for Transport Port Uses draft-ietf-tsvwg-port-use-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on November 30, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without Touch Expires November 30, 2012 [Page 1] Internet-Draft Recommendations for Transport Port Use May 2012 warranty as described in the Simplified BSD License. Abstract This document provides recommendations to application and service designers on how to use the transport protocol port number space to help in its preservation. **NOTE THAT THIS CURRENT VERSION IS LARGELY AN OUTLINE OF ISSUES**. Table of Contents 1. Introduction...................................................2 2. Conventions used in this document..............................2 3. History........................................................3 4. Current Port Use...............................................4 5. What is a Port?................................................5 6. Conservation...................................................6 7. How to Use Registered Ports....................................6 7.1. Do You Need a Port?.......................................6 7.2. How Many Ports?...........................................6 7.3. Picking a Port Number.....................................7 7.4. Support for Security......................................7 7.5. Support for Future Versions...............................7 7.6. Transport Protocols.......................................7 7.7. When to Register..........................................7 7.8. Other Considerations......................................8 8. Recommendations for Future Allocation..........................8 9. Security Considerations........................................8 10. IANA Considerations...........................................8 11. Conclusions...................................................9 12. References....................................................9 12.1. Normative References.....................................9 12.2. Informative References...................................9 13. Acknowledgments..............................................11 1. Introduction (TBD) 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. Touch Expires November 30, 2012 [Page 2] Internet-Draft Recommendations for Transport Port Use May 2012 In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. In this document, the characters ">>" preceding an indented line(s) indicates a compliance requirement statement using the key words listed above. This convention aids reviewers in quickly identifying or finding the explicit compliance requirements of this RFC. 3. History The term 'port' was first used in RFC33 to describe a simplex communication path from a process [RFC33]. At a meeting described in RFC37, an idea was presented to decouple connections between processes and links that they use as paths, and thus to include source and destination socket identifiers in packets. RFC38 explains this in detail, in which processes might have more than one of these paths, and that more than one may be active at a time [RFC38]. As a result, there was the need to add a process identifier to the header of each message, so that the incoming data could be demultiplexed to the appropriate process. RFC38 further suggested that 32 bits would be used for these identifiers. RFC48 discusses the current notion of listening on a given port, but does not discuss how the issue of port determination [RFC48]. RFC61 notes that the challenge of knowing the appropriate port numbers is "left to the processes" in general, but introduces the concept of a "well-known" port for common services [RFC61]. RFC76 addresses this issue more constructively, proposing a "telephone book" by which an index would allow ports to be used by name, but still assumes that both source and destination ports are fixed by such a system [RFC76]. RFC333 suggests that the port pair, rather than an individual port, would be used on both sides of the connection for demultiplexing messages [RFC333]. This is the final view in RFC793 (and its predecessors, including IEN 112 [IEN112]), and brings us to their current meaning. RFC739 introduces the notion of generic reserved ports, used for groups of protocols, such as "any private RJE server" [RFC739]. Although the overall range of such ports was (and remains) 16 bits, only the first 256 (high 8 bits cleared) in the range were considered assigned. RFC758 is the first to describe a list of such well-known ports, as well as describing ranges used for different purposes [RFC758]: Touch Expires November 30, 2012 [Page 3] Internet-Draft Recommendations for Transport Port Use May 2012 Binary Octal ----------------------------------------------------------- 0-63 0-77 Network Wide Standard Function 64-127 100-177 Hosts Specific Functions 128-223 200-337 Reserved for Future Use 224-255 340-377 Any Experimental Function In RFC820, those range meanings disappeared, and a single list of assignments is presented [RFC820]. By RFC900, they appeared as decimal numbers rather than the octal ranges used previously [RFC900]. RFC1340 increased this range from 0..255 to 0..1023, and began to list TCP and UDP port assignments individually (although the assumption was, and remains, that once assigned a port applies to all transport protocols, including TCP, UDP, recently SCTP and DCCP, as well as ISO-TP4 for a brief period in the early 1990s) [RFC1340]. RFC1340 also established the Registered space of 1024- 59151, though it notes that it is not controlled by the IANA at that point. The list provided by RFC1700 in 1994 remained the standard until it was declared replaced by an on-line version, as of RFC3232 in 2002 [RFC1700][RFC3232]. 4. Current Port Use The current IANA website (www.iana.org) indicates three ranges of port assignments: Binary Hex ----------------------------------------------------------- 0-1023 0x03FF Well-Known (a.k.a. 'system') 1024-49151 0x0300-0xBFFF Registered (a.k.a. 'user') 49152-65535 0xC000-0xFFFF Dynamic/Private Well-known encompasses the range 0..1023. On some systems, use of these ports requires privileged access, e.g., that the process run as 'root', which is why these are referred to as 'system' ports. The ports from 1024..49151 denotes non-privileged services, known as 'registered'; because these ports do not run with special Touch Expires November 30, 2012 [Page 4] Internet-Draft Recommendations for Transport Port Use May 2012 privileges, they are often referred to as 'user' ports. Dynamic or Private ports are not registered through IANA. Both Well-Known and Registered ports are registered through IANA, so both are sometimes called "registered ports". As a result, the term 'registered' is ambiguous, referring either to the entire range 0- 49151 or to the user ports. Complicating matters further, 'system' ports do not always require special (i.e., 'root') privilege. Regardless, for clarity, throughout the remainder of this document we will refer to the port ranges as 'system', 'user', and 'private'. 5. What is a Port? A port is a 16-bit number used for two distinct purposes: o Demultiplexing transport connections within an end host o Identifying a service The first reason requires that each transport connection between a given pair of IP addresses use a different pair of ports, but does not require either coordination or registration of port use. It is the second reason that drives the need for a common registry. Consider a user wanting to run a web server. That service could run on any port, provided that all clients knew what port to use to access that service at that host. Such information can be distributed out of band, e.g., in the URL, such as: http:51509//www.example.com/ Ultimately, it's important to keep in mind that the correlation of a service with a port number is an agreement between the two endpoints of the connection only. The rest of the world might think that you're sending DNS packets on port 53, but you can run a web server on that port just fine, provided the server and client both decide that port 53 is for HTTP web server traffic. Which brings us to the concept of a service. A service is the combination of ISO Layers 5-7 that represent an application protocol capability. For example www (port 80) is a service that uses HTTP as an application protocol, and provides a common web server. However, it is possible to use HTTP for other purposes, such as command and control. This is why some current service names (HTTP, e.g.) are a bit overloaded - they describe not only the application protocol, but a particular service. Touch Expires November 30, 2012 [Page 5] Internet-Draft Recommendations for Transport Port Use May 2012 IANA registers ports so that endpoints on the Internet do not need to pairwise, explicitly coordinate the meaning of their port numbers. This is the primary reason for registering ports with IANA - to have a common agreement between all endpoints on the Internet as to the meaning of a port. Ports are used for other purposes as well, however. The other primary reason for registering ports with IANA is to simplify end system configuration, so individual installations do not need to coordinate their use of arbitrary ports. A similar reason is to simplify firewall management, so that a single, fixed firewall configuration can either permit or deny a service. 6. Conservation (statistics of port allocations) Ways to conserve, e.g., use service names (DNS SRV, TCP portnames, etc.), use portmapper, Bonjour, or other services for demuxing 7. How to Use Registered Ports 7.1. Do You Need a Port? How to carefully use experimental ports (ref TCPM doc) Reasons NOT to register a port, e.g., o not for a copy of an existing service o not for anything a vanilla web client can connect to o not for performance o not for insecure versions of secure services (creates security hole) Ports vs. SRV names Reasons why only server ports are registered (not client) 7.2. How Many Ports? Reasons NOT to have multiple ports (performance, etc.) Techniques to reduce port use: Touch Expires November 30, 2012 [Page 6] Internet-Draft Recommendations for Transport Port Use May 2012 o When can you use a discovery service o When can you use multiplexing o When can you use handoff with in-band IDs 7.3. Picking a Port Number Would you still want one if you can't pick the value? Would you still want the UDP / TCP one if it didn't match the value for a previously assigned TCP / UDP one? 7.4. Support for Security Why this is generally expected Why this should/should not use a separate port (it's a performance issue, and performance would argue for multiple ports anyway, and ports are a limited resource) TLS allows optional security 7.5. Support for Future Versions Reasons NOT to include the version number in the name 7.6. Transport Protocols UDP vs. TCP vs. others - and when the transport you lookup is not always the one you end up using When/why you need multiples When UDP is -disc Caveats about using broadcast as discovery. 7.7. When to Register What range to use before registering When are you ready to register (basically when you have enough information to fill out the application) Reasons NOT to squat Touch Expires November 30, 2012 [Page 7] Internet-Draft Recommendations for Transport Port Use May 2012 7.8. Other Considerations Higher bar for system ports Changing a name Why aliases are bad and now deprecated Providing enough information for IANA review, e.g., to avoid Internet congestion, fit in MTUs, deal with reordering, etc. Provide enough information that's stand-alone; don't describe a protocol by a URL, e.g. - how to do a high-level description (what are we looking for?) Why a heartbeat port MUST be on the same port as a service. Relation of this doc to the IANA Port Experts review process (this is just a summary from the user/designer viewpoint, and is NOT binding to IANA or its Expert Review team) 8. Recommendations for Future Allocation Abolish the distinction of system ports? BIG QUESTION HERE... Why NOT to allocate ports or names for use as examples 9. Security Considerations This document discusses ways to conserve port numbers, notably through encouraging demultiplexing within a single port. As such, there may be cases where two variants of a protocol - insecure and secure, are suggested to share the same port (e.g., HTTP and HTTPS, though currently those are assigned different ports). This document reminds protocol designers that port numbers are not a substitute for security, and should not alone be used to avoid denial of service or firewall traffic, notably because their use is not regulated or authenticated. 10. IANA Considerations The entirety of this document focuses on IANA issues, notably suggestions that help ensure the conservation of port numbers and provide useful hints for issuing informative requests thereof. Touch Expires November 30, 2012 [Page 8] Internet-Draft Recommendations for Transport Port Use May 2012 11. Conclusions 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 12.2. Informative References [Hi95] Hickman, K., "The SSL Protocol", February 1995. [IEN112] Postel, J., "Transmission Control Protocol", IEN 112, August 1979. [RFC33] Crocker, S., "New Host-Host Protocol", RFC 33 February 1970. [RFC37] Crocker, S., "Network Meeting Epilogue", RFC 37, March 1970. [RFC38] Wolfe, S., "Comments on Network Protocol from NWG/RFC #36", RFC 38, March 1970. [RFC48] Postel, J., S. Crocker, "Possible protocol plateau", RFC 48, April 1970. [RFC61] Walden, D., "Note on Interprocess Communication in a Resource Sharing Computer Network", RFC 61, July 1970. [RFC76] Bouknight, J., J. Madden, G. Grossman, "Connection by name: User oriented protocol", RFC 76, October 1970. [RFC333] Bressler, R., D. Murphy, D. Walden. "Proposed experiment with a Message Switching Protocol", RFC 333, May 1972. [RFC739] Postel, J., "Assigned numbers", RFC 739, November 1977. [RFC758] Postel, J., "Assigned numbers", RFC 758, August 1979. [RFC768] Postel, J., "User Datagram Protocol", RFC 768, August 1980. Touch Expires November 30, 2012 [Page 9] Internet-Draft Recommendations for Transport Port Use May 2012 [RFC793] Postel, J., "Transmission Control Protocol" RFC 793, September 1981 [RFC820] Postel, J., "Assigned numbers", RFC 820, August 1982. [RFC900] Reynolds, J., J. Postel, "Assigned numbers", RFC 900, June 1984. [RFC1122] Deering, S., "Host extensions for IP multicasting", RFC 1122, August 1989. [RFC1340] Reynolds, J., J. Postel, "Assigned numbers", RFC 1340, July 1992. [RFC1700] Reynolds, J., J. Postel, "Assigned numbers", RFC 1700, October 1994. [RFC1918] Rekhter, Y., B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear, "Address Allocation for Private Internets", RFC 1918, February 1996. [RFC2616] Fielding, R., J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2780] Bradner, S., V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", RFC 2780, March 2000. [RFC2817] Khare, R., S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC3232] Reynolds, J. (Ed.), "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002. [RFC4340] Kohler, E., M. Handley, S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006. [RFC4960] Stewart, R. (Ed.), "Stream Control Transmission Protocol", RFC 4960, September 2007. [RFC5246] Dierks, T., E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. Touch Expires November 30, 2012 [Page 10] Internet-Draft Recommendations for Transport Port Use May 2012 13. Acknowledgments TBD This document was prepared using 2-Word-v2.0.template.dot. Authors' Addresses Joe Touch USC/ISI 4676 Admiralty Way Marina del Rey, CA 90292-6695 U.S.A. Phone: +1 (310) 448-9151 EMail: touch@isi.edu Touch Expires November 30, 2012 [Page 11]