draft-ietf-tsvwg-port-use-09.txt   draft-ietf-tsvwg-port-use-10.txt 
TSVWG J. Touch TSVWG J. Touch
Internet Draft USC/ISI Internet Draft USC/ISI
Intended status: Best Current Practice March 23, 2015 Intended status: Best Current Practice March 25, 2015
Expires: September 2015 Expires: September 2015
Recommendations on Using Assigned Transport Port Numbers Recommendations on Using Assigned Transport Port Numbers
draft-ietf-tsvwg-port-use-09.txt draft-ietf-tsvwg-port-use-10.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 23, 2015. This Internet-Draft will expire on September 25, 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 29 skipping to change at page 6, line 29
represents an application protocol capability. For example www (port represents an application protocol capability. For example www (port
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 port number
numbers assigned by IANA - to have a common agreement between all assignment by IANA - to have a common agreement between all
endpoints on the Internet as to the default meaning of a port endpoints on the Internet as to the default meaning of a port
number, which provides the endpoints with a default port number for number, which provides the endpoints with a default port number for
a particular 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
skipping to change at page 14, line 5 skipping to change at page 14, line 5
Secure versions of legacy services that are not already security- Secure versions of legacy services that are not already security-
capable via in-band negotiations can be very useful. However, there capable via in-band negotiations can be very useful. However, there
is no IETF consensus on when separate ports should be used for is no IETF consensus on when separate ports should be used for
secure and insecure variants of the same service [RFC2595] [RFC2817] secure and insecure variants of the same service [RFC2595] [RFC2817]
[RFC6335]. The overall preference is for use of a single port, as [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], noted in Section 6 of this document and Section 7.2 of [RFC6335],
but the appropriate approach depends on the specific characteristics but the appropriate approach depends on the specific characteristics
of the service. As a result: of the service. As a result:
>> When simultaneously requesting both secure and insecure port >> When requesting both secure and insecure port assignments for the
assignments for the same service, justification is expected for the same service, justification is expected for the utility and safety
utility and safety of each port as an independent service (Section of each port as an independent service (Section 6). Precedent (e.g.,
6). Precedent (e.g., citing other protocols that use a separate citing other protocols that use a separate insecure port) is
insecure port) is inadequate justification by itself. 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
 End of changes. 5 change blocks. 
10 lines changed or deleted 10 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/