Identifying Protocols

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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

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”.

This Internet-Draft will expire on March 26, 2018.

Copyright © 2017 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 warranty as described in the Simplified BSD License.

• Assuring that the endpoints positively support the intended protocol (e.g., to avoid cross-protocol attacks)
• Negotiating the use of a protocol (or protocol version)
• Configuring protocol details, such as transport parameters, or optional features
• Discriminating traffic based upon protocol, for policy enforcement or quality of service
• Establishing a name space for extensions and other protocol artefacts

Internet standards define a number of ways to identify a protocol. Less is said about the appropriate use of these identifiers for various purposes. This document defines best practices for the use of several kinds of protocol identifiers.

It’s very common for protocols to specify an initial set of octets that are to be sent by endpoints on a connection, so-called “magic.”

Magic is best used to assure that the protocol being used is unambiguous, to prevent cross-protocol attacks as well as plain misconfiguration.

• PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n

This was carefully designed to quickly and unambiguously break as many HTTP/1.1 servers as possible, so that if a HTTP/2 client were to accidentally connect to a HTTP/1.1 server, it would fail quickly and as reliably as possible. This aids error recovery.

Magic is less helpful for negotiating the protocol to be used. For example, the PROXY protocol uses magic to preface metadata onto a connection. However, the client needs to be configured to use the PROXY protocol on an endpoint-by-endpoint basis, since negotiation will fail otherwise.

Since Magic only applies to the data stream it is used within, it is also less than useful for negotiating alternative transports. However, a protocol can overload magic to perform some kinds of configuration. This is effectively what the HTTP/2 SETTINGS frame does.

Transport protocols like TCP [RFC0793] and UDP [RFC0768] use port numbers to identify protocols. Historically, port numbers have been used to identify the application in use, which maps roughly to the protocol.

Generally, a protocol registers a “default” port that is to be used for it; this allows a client to connect to a server for a given purpose only using that server’s name.

However, there are cases where different applications use the same protocol on different ports (e.g, SMTP on port 25, submission on port 587); conversely, different applications sometimes use the same protocol on the same port (e.g., countless applications using HTTP on ports 80 and 443).

The binding between a port number and a protocol is also weak; just because HTTPS is allocated port 443, it isn’t constrained to operate only on that port (and is commonly deployed on other ports as well). Likewise, ports are sometimes used for purposes other than that allocated; again using 443 as an example, other protocols are known to use it for firewall traversal.

This means that while they serve their primary purpose of multiplexing multiple protocols onto the same host well, port numbers have limited utility for the purposes of protocol identification outlined above.

The most commonly cited case, discriminating traffic in the network, can only be described as “best effort” generously, especially in these times of pervasive encryption [RFC7258]. The port number that traffic uses is no guarantee of the application or protocol in use. At best, it is an indicator of possible application and/or protocol.

URI schemes [RFC3986] occur as part of a resource identifier that’s often (but not always) end user-visible.

The primary purpose of URIs is identification.

A newer form of protocol identification was introduced by ALPN [RFC7301], which establishes a name space of Protocol Identifiers.

The original purpose of ALPN Protocol IDs was to identify the “next” protocol inside a TLS connection, so that HTTP could negotiate the use of HTTP/2 instead of HTTP/1. HTTP/2 quickly adopted this name space for other purposes, including the identification of protocols in Alternative Services [RFC7838].

This document has no requirements for IANA.