[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-touch-tsvwg-port-use) 00 01 02 03 04 05 06 07 08 09 10 11 RFC 7605

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

   <Add any 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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/