draft-ietf-tsvwg-port-use-08.txt   draft-ietf-tsvwg-port-use-09.txt 
TSVWG J. Touch TSVWG J. Touch
Internet Draft USC/ISI Internet Draft USC/ISI
Intended status: Best Current Practice March 13, 2015 Intended status: Best Current Practice March 23, 2015
Expires: September 2015 Expires: September 2015
Recommendations for Transport Port Number Uses Recommendations on Using Assigned Transport Port Numbers
draft-ietf-tsvwg-port-use-08.txt draft-ietf-tsvwg-port-use-09.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 31 skipping to change at page 1, line 31
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 13, 2015. This Internet-Draft will expire on September 23, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 6, line 30 skipping to change at page 6, line 30
number 80) is a service that uses HTTP as an application protocol number 80) is a service that uses HTTP as an application protocol
and provides access to a web server [RFC7230]. However, it is and provides access to a web server [RFC7230]. However, it is
possible to use HTTP for other purposes, such as command and possible to use HTTP for other purposes, such as command and
control. This is why some current services (HTTP, e.g.) are a bit control. This is why some current services (HTTP, e.g.) are a bit
overloaded - they describe not only the application protocol, but a overloaded - they describe not only the application protocol, but a
particular service. particular service.
IANA assigns port numbers so that Internet endpoints do not need IANA assigns port numbers so that Internet endpoints do not need
pairwise, explicit coordination of the meaning of their port pairwise, explicit coordination of the meaning of their port
numbers. This is the primary reason for requesting assigned port numbers. This is the primary reason for requesting assigned port
numbers with IANA - to have a common agreement between all endpoints numbers assigned by IANA - to have a common agreement between all
on the Internet as to the default meaning of a port number, which endpoints on the Internet as to the default meaning of a port
provides the endpoints with a default port number for a particular number, which provides the endpoints with a default port number for
protocol or service. a particular protocol or service.
Port numbers are sometimes used by intermediate devices on a network Port numbers are sometimes used by intermediate devices on a network
path, either to monitor available services, to monitor traffic path, either to monitor available services, to monitor traffic
(e.g., to indicate the data contents), or to intercept traffic (to (e.g., to indicate the data contents), or to intercept traffic (to
block, proxy, relay, aggregate, or otherwise process it). In each block, proxy, relay, aggregate, or otherwise process it). In each
case, the intermediate device interprets traffic based on the port case, the intermediate device interprets traffic based on the port
number. It is important to recognize that any interpretation of port number. It is important to recognize that any interpretation of port
numbers - except at the endpoints - may be incorrect, because port numbers - except at the endpoints - may be incorrect, because port
numbers are meaningful only at the endpoints. Further, port numbers numbers are meaningful only at the endpoints. Further, port numbers
may not be visible to these intermediate devices, such as when the may not be visible to these intermediate devices, such as when the
skipping to change at page 8, line 19 skipping to change at page 8, line 19
indicated in-band over the control port number [RFC959]. indicated in-band over the control port number [RFC959].
o A single assigned port number can indicate the Dynamic port o A single assigned port number can indicate the Dynamic port
number(s) on which different capabilities are supported, as number(s) on which different capabilities are supported, as
with passive-mode FTP [RFC959]. with passive-mode FTP [RFC959].
o Several existing services can indicate the Dynamic port o Several existing services can indicate the Dynamic port
number(s) on which other services are supported, such as with number(s) on which other services are supported, such as with
mDNS and portmapper [RFC1833] [RFC6762] [RFC6763]. mDNS and portmapper [RFC1833] [RFC6762] [RFC6763].
o Copies of an existing service can also be operated on
different IP addresses, either on different hosts or as
different real or virtual interfaces (or even operating
systems) on the same host.
o Copies of some existing services can be differentiated using o Copies of some existing services can be differentiated using
in-band information (e.g., URIs in HTTP Host field and TLS in-band information (e.g., URIs in HTTP Host field and TLS
Server Name Indication extension) [RFC7230] [RFC6066]. Server Name Indication extension) [RFC7230] [RFC6066].
o Services requiring varying performance properties can already o Services requiring varying performance properties can already
be supported using separate endpoint associations (connections be supported using separate endpoint associations (connections
or other associations), each configured to support the desired or other associations), each configured to support the desired
properties. E.g., a high-speed and low-speed variant can be properties. E.g., a high-speed and low-speed variant can be
determined within the service using the same assigned port. determined within the service using the same assigned port.
Assigned port numbers are intended to differentiate services, not Assigned port numbers are intended to differentiate services, not
variations of performance, replicas, pairwise endpoint associations, variations of performance, replicas, pairwise endpoint associations,
or payload types. Assigned port numbers are also a small space or payload types. Assigned port numbers are also a small space
compared to other Internet number spaces; it is never appropriate to compared to other Internet number spaces; it is never appropriate to
consume assigned port numbers to conserve larger spaces such as IP consume assigned port numbers to conserve larger spaces such as IP
addresses. addresses, especially where copies of a service represent different
endpoints.
6.2. Firewall and NAT Considerations 6.2. Firewall and NAT Considerations
Assigned port numbers are useful for configuring firewalls and other Assigned port numbers are useful for configuring firewalls and other
port-based systems for access control. Ultimately, these numbers port-based systems for access control. Ultimately, these numbers
indicate services only to the endpoints, and any intermediate device indicate services only to the endpoints, and any intermediate device
that assigns meaning to a value can be incorrect. End systems might that assigns meaning to a value can be incorrect. End systems might
agree to run web services (HTTP) over port number 53 (typically used agree to run web services (HTTP) over port number 53 (typically used
for DNS) rather than port number 80, at which point a firewall that for DNS) rather than port number 80, at which point a firewall that
blocks port number 80 but permits port number 53 would not have the blocks port number 80 but permits port number 53 would not have the
skipping to change at page 13, line 33 skipping to change at page 13, line 33
of the 1024 System values (17%), or 180 of the overall 49152 of the 1024 System values (17%), or 180 of the overall 49152
assigned (System and User) values (<0.04%). assigned (System and User) values (<0.04%).
7.4. Support for Security 7.4. Support for Security
Just as a service is a way to obtain information or processing from Just as a service is a way to obtain information or processing from
a host over a network, a service can also be the opening through a host over a network, a service can also be the opening through
which to compromise that host. Protecting a service involves which to compromise that host. Protecting a service involves
security, which includes integrity protection, source security, which includes integrity protection, source
authentication, privacy, or any combination of these capabilities. authentication, privacy, or any combination of these capabilities.
Security can be provided in a number of ways: Security can be provided in a number of ways, and thus:
>> New services SHOULD support security capabilities, either >> New services SHOULD support security capabilities, either
directly or via a content protection such as TLS [RFC5246] or DTLS directly or via a content protection such as TLS [RFC5246] or DTLS
[RFC6347] or transport protection such as TCP-AO [RFC5925]. Insecure [RFC6347] or transport protection such as TCP-AO [RFC5925]. Insecure
versions of new or existing secure services SHOULD be avoided versions of new or existing secure services SHOULD be avoided
because of the new vulnerability they create. because of the new vulnerability they create.
Secure versions of legacy services that are not already security-
capable via in-band negotiations can be very useful. However, there
is no IETF consensus on when separate ports should be used for
secure and insecure variants of the same service [RFC2595] [RFC2817]
[RFC6335]. The overall preference is for use of a single port, as
noted in Section 6 of this document and Section 7.2 of [RFC6335],
but the appropriate approach depends on the specific characteristics
of the service. As a result:
>> When simultaneously requesting both secure and insecure port >> When simultaneously requesting both secure and insecure port
assignments for the same service, strong justification is expected assignments for the same service, justification is expected for the
for the utility and safety of a separate insecure assigned port utility and safety of each port as an independent service (Section
[RFC2595]. Precedent (citing other protocols that use an insecure 6). Precedent (e.g., citing other protocols that use a separate
port) is not strong justification by itself. insecure port) is inadequate justification by itself.
It's also important to recognize that port number assignment is not It's also important to recognize that port number assignment is not
itself a guarantee that traffic using that number provides the itself a guarantee that traffic using that number provides the
corresponding service, or that a given service is always offered corresponding service, or that a given service is always offered
only on its assigned port number. Port numbers are ultimately only on its assigned port number. Port numbers are ultimately
meaningful only between endpoints and any service can be run on any meaningful only between endpoints and any service can be run on any
port. Thus: port. Thus:
>> Security SHOULD NOT rely on assigned port number distinctions >> Security SHOULD NOT rely on assigned port number distinctions
alone; every service, whether secure or not, is likely to be alone; every service, whether secure or not, is likely to be
attacked. attacked.
There is debate as to how to secure legacy insecure services Applications for a new service that requires both a secure and
[RFC6335]. Some argue that secure variants should share the existing insecure port may be found, on expert review, to be unacceptable,
port number assignment, such that security is enabled on a per- and may not be approved for allocation. Similarly, an application
connection or other association basis [RFC2595] [RFC2817]. Others for a new port to support an insecure variant of an existing secure
argue that security should be supported on a new port number protocol may be found unacceptable. In both cases, the resulting
assignment and be enabled by default. Either approach is currently security of the service in practice will be a significant
permitted. A separate port number might be important for security consideration in the decision as to whether to assign an insecure
coordination (e.g., firewall management), but this might further port.
argue for deprecation of the insecure variant.
Optional security can penalize performance, requiring additional
round-trip exchanges before a connection or other association can be
established. As discussed earlier, assigned port numbers are a
critical resource and it is inappropriate to consume assignments to
increase performance. As a result, the need for separate port
assignments for both secure and insecure variants is not justified
merely for performance - either for the performance of connection
establishment or association establishment, or for differences in
data performance between secure and insecure variants.
Note however that a new service might not be eligible for IANA
assignment of both an insecure and a secure variant of the same
service. In a similar way, applications requesting assignment for an
insecure port number for a secure service might not be appropriate.
In both cases, security of the service is compromised by adding the
insecure port number assignment.
7.5. Support for Future Versions 7.5. Support for Future Versions
Requests for assigned port numbers are expected to support multiple Requests for assigned port numbers are expected to support multiple
versions on the same assigned port number [RFC6335]. Versions are versions on the same assigned port number [RFC6335]. Versions are
typically indicated in-band, either at the beginning of a connection typically indicated in-band, either at the beginning of a connection
or other association, or in each protocol message. or other association, or in each protocol message.
>> Version support SHOULD be included in new services rather than >> Version support SHOULD be included in new services rather than
relying on different port number assignments for different versions. relying on different port number assignments for different versions.
skipping to change at page 18, line 40 skipping to change at page 18, line 35
be retained. However, in cases where the current assignee of a name be retained. However, in cases where the current assignee of a name
or number has reasonable knowledge of the impact on such uses, and or number has reasonable knowledge of the impact on such uses, and
is willing to accept that impact, the name or number of an is willing to accept that impact, the name or number of an
assignment can be changed [RFC6335] assignment can be changed [RFC6335]
Aliases, or multiple service names for the same assigned port Aliases, or multiple service names for the same assigned port
number, are no longer considered appropriate [RFC6335]. number, are no longer considered appropriate [RFC6335].
8. Security Considerations 8. Security Considerations
This document discusses ways to conserve assigned port numbers, This document focuses on the issues arising when designing services
notably through encouraging demultiplexing within a single port that require new port assignments. Section 7.4 addresses the
number. As such, there may be cases where two variants of a security and security-related issues of that interaction.
protocol - insecure and secure (such as using optional TLS or DTLS)
or different versions - are suggested to share the same assigned
port number.
The use of TLS [RFC5246], DTLS [RFC6347], or TCP-AO [RFC5925] that When designing a secure service, the use of TLS [RFC5246], DTLS
protect transport protocols or their contents is encouraged. It may [RFC6347], or TCP-AO [RFC5925] mechanisms that protect transport
not be possible to use IPsec [RFC4301] in similar ways because of protocols or their contents is encouraged. It may not be possible to
the different relationship between IPsec and port numbers and use IPsec [RFC4301] in similar ways because of the different
because applications may not be aware of IPsec protections. relationship between IPsec and port numbers and because applications
may not be aware of IPsec protections.
This document reminds application and service designers that port This document reminds application and service designers that port
numbers do not protect against denial of service attack or guarantee numbers do not protect against denial of service attack or guarantee
that traffic should be trusted. Using assigned numbers for port that traffic should be trusted. Using assigned numbers for port
filtering isn't a substitute for authentication, encryption, and filtering isn't a substitute for authentication, encryption, and
integrity protection. The port number alone should not be used to integrity protection. The port number alone should not be used to
avoid denial of service attacks or to manage firewall traffic avoid denial of service attacks or to manage firewall traffic
because the use of port numbers is not regulated or validated. because the use of port numbers is not regulated or validated.
The use of assigned port numbers is the antithesis of privacy The use of assigned port numbers is the antithesis of privacy
 End of changes. 12 change blocks. 
56 lines changed or deleted 41 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/