One document matched: draft-ietf-httpbis-tunnel-protocol-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<!--
This XML document is the output of clean-for-DTD.xslt; a tool that strips
extensions to RFC2629(bis) from documents for processing with xml2rfc.
--><!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<?xml-stylesheet type='text/xsl' href='lib/rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes"?>
<?rfc rfcedstyle="yes"?>
<!DOCTYPE rfc
PUBLIC "" "rfc2629.dtd">
<rfc category="std" docName="draft-ietf-httpbis-tunnel-protocol-01" ipr="trust200902">
<front>
<title abbrev="Tunnel-Protocol">The Tunnel-Protocol HTTP Request Header Field</title>
<author fullname="Andrew Hutton" initials="A." surname="Hutton">
<organization>Unify</organization>
<address>
<postal>
<street>Technology Drive</street>
<city>Nottingham</city>
<code>NG9 1LA</code>
<country>UK</country>
</postal>
<email>andrew.hutton@unify.com</email>
</address>
</author>
<author fullname="Justin Uberti" initials="J." surname="Uberti">
<organization>Google</organization>
<address>
<postal>
<street>747 6th Ave S</street>
<city>Kirkland</city>
<region>WA</region>
<code>98033</code>
<country>US</country>
</postal>
<email>justin@uberti.name</email>
</address>
</author>
<author fullname="Martin Thomson" initials="M." surname="Thomson">
<organization>Mozilla</organization>
<address>
<postal>
<street>331 E Evelyn Street</street>
<city>Mountain View</city>
<region>CA</region>
<code>94041</code>
<country>US</country>
</postal>
<email>martin.thomson@gmail.com</email>
</address>
</author>
<date year="2015"/>
<area>Applications</area>
<workgroup>HTTPbis Working Group</workgroup>
<keyword>HTTP CONNECT</keyword>
<keyword>Firewall</keyword>
<keyword>HTTP proxy</keyword>
<abstract>
<t>
This specification allows HTTP CONNECT requests to indicate what
protocol will be used within the tunnel once established, using the
Tunnel-Protocol request header field.
</t>
</abstract>
<note title="Editorial Note (To be removed by RFC Editor)">
<t>
Discussion of this draft takes place on the HTTPBIS working group mailing list
(ietf-http-wg@w3.org), which is archived at <eref target="https://lists.w3.org/Archives/Public/ietf-http-wg/"/>.
</t>
<t>
Working Group information can be found at <eref target="https://tools.ietf.org/wg/httpbis/"/>
and <eref target="http://httpwg.github.io/"/>; source code and issues
list for this draft can be found at
<eref target="https://github.com/httpwg/http-extensions"/>.
</t>
<!--<t>
The changes in this draft are summarized in <xref
target="change.log"/>.
</t>-->
</note>
</front>
<middle>
<section title="Introduction">
<t>
The HTTP CONNECT method (Section 4.3.6 of <xref target="RFC7231"/>)
requests that the recipient establish a tunnel to the identified origin
server and thereafter forward packets, in both directions, until the
tunnel is closed. Such tunnels are commonly used to create end-to-end
virtual connections, through one or more proxies, which may then be
secured using TLS (Transport Layer Security, <xref target="RFC5246"/>).
</t>
<t>
The HTTP Tunnel-Protocol header field identifies the protocol that will
be spoken within the tunnel, using the application layer next protocol
identifier <xref target="RFC7301"/> specified for TLS <xref target="RFC5246"/>.
</t>
<t>
When CONNECT is used to establish a TLS tunnel, the Tunnel-Protocol
header field may be used to carry the same application protocol label as
will be carried within the TLS handshake. If there are multiple
possible application protocols, all of those application protocols are
indicated.
</t>
<t>
The Tunnel-Protocol header field carries an indication only. In TLS,
the final choice of application protocol is made by the server. Proxies
do not implement the tunneled protocol, though they might choose to make
policy decisions based on the value of the header field.
</t>
<section title="Requirements Language">
<t>
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 <xref target="RFC2119">RFC 2119</xref>.
</t>
</section>
</section>
<section anchor="tp" title="The Tunnel-Protocol HTTP Request Header Field">
<t>
Clients include the `Tunnel-Protocol` Request Header field in an HTTP
CONNECT request to indicate the application layer protocol will be used
within the tunnel, or the set of protocols that might be used within the
tunnel.
</t>
<section title="Header Field Values">
<t>
Valid values for the protocol field are taken from the registry
established in <xref target="RFC7301"/>.
</t>
</section>
<section title="Syntax">
<t>
The ABNF (Augmented Backus-Naur Form) syntax for the `Tunnel-Protocol`
header field is given below. It is based on the Generic Grammar
defined in Section 2 of <xref target="RFC7230"/>.
</t>
<figure>
<artwork type="abnf2616"><![CDATA[
Tunnel-Protocol = "Tunnel-Protocol":" 1#protocol-id
protocol-id = token ; percent-encoded ALPN protocol identifier
]]></artwork>
</figure>
<t>
ALPN protocol names are octet sequences with no additional constraints
on format. Octets not allowed in tokens (<xref target="RFC7230"/>, Section 3.2.6) must be percent-encoded as per Section 2.1 of <xref target="RFC3986"/>. Consequently, the octet
representing the percent character "%" (hex 25) must be
percent-encoded as well.
</t>
<t>
In order to have precisely one way to represent any ALPN protocol
name, the following additional constraints apply:
<list style="symbols">
<t>
Octets in the ALPN protocol must not be percent-encoded if they
are valid token characters except "%", and
</t>
<t>
When using percent-encoding, uppercase hex digits must be used.
</t>
</list>
</t>
<t>
With these constraints, recipients can apply simple string comparison
to match protocol identifiers.
</t>
<figure>
<preamble>
For example:
</preamble>
<artwork type="message/http; msgtype="request""><![CDATA[
CONNECT www.example.com HTTP/1.1
Host: www.example.com
Tunnel-Protocol: h2, http%2F1.1
]]></artwork>
</figure>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
HTTP header fields are registered within the "Message Headers" registry
maintained at <eref target="https://www.iana.org/assignments/message-headers"/>. This
document defines and registers the `Tunnel-Protocol` header field,
according to <xref target="RFC3864"/> as follows:
<list style="hanging">
<t hangText="Header Field Name:">
Tunnel-Protocol
</t>
<t hangText="Protocol:">
http
</t>
<t hangText="Status:">
Standard
</t>
<t hangText="Reference:">
<xref target="tp"/>
</t>
<t hangText="Change Controller:">
IETF (iesg@ietf.org) - Internet Engineering Task Force
</t>
</list>
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
In case of using HTTP CONNECT to a TURN server the security
considerations of Section 4.3.6 of <xref target="RFC7231"/>
apply. It states that there "are significant risks in establishing a
tunnel to arbitrary servers, particularly when the destination is a
well-known or reserved TCP port that is not intended for Web
traffic. Proxies that support CONNECT SHOULD restrict its use to a
limited set of known ports or a configurable whitelist of safe request
targets."
</t>
<t>
The `Tunnel-Protocol` request header field described in this document is
an optional header. Clients and HTTP Proxies could choose to not support
the header and therefore fail to provide it, or ignore it when
present. If the header is not available or ignored, a proxy cannot
identify the purpose of the tunnel and use this as input to any
authorization decision regarding the tunnel. This is indistinguishable
from the case where either client or proxy does not support the
`Tunnel-Protocol` header.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="Scott Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year="1997" month="March"/>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
<list>
<t>
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.
</t></list></t>
<t>
Note that the force of these words is modified by the requirement
level of the document in which they are used.
</t></abstract></front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<format type="TXT" octets="4723" target="http://www.rfc-editor.org/rfc/rfc2119.txt"/>
<format type="HTML" octets="17970" target="http://xml.resource.org/public/rfc/html/rfc2119.html"/>
<format type="XML" octets="5777" target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"/>
</reference>
<reference anchor="RFC3864">
<front>
<title>Registration Procedures for Message Header Fields</title>
<author initials="G." surname="Klyne" fullname="G. Klyne">
<organization/></author>
<author initials="M." surname="Nottingham" fullname="M. Nottingham">
<organization/></author>
<author initials="J." surname="Mogul" fullname="J. Mogul">
<organization/></author>
<date year="2004" month="September"/>
<abstract>
<t>This specification defines registration procedures for the message header fields used by Internet mail, HTTP, Netnews and other applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract></front>
<seriesInfo name="BCP" value="90"/>
<seriesInfo name="RFC" value="3864"/>
<format type="TXT" octets="36231" target="http://www.rfc-editor.org/rfc/rfc3864.txt"/>
</reference>
<reference anchor="RFC3986">
<front>
<title abbrev="URI Generic Syntax">Uniform Resource Identifier (URI): Generic Syntax</title>
<author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
<organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
<address>
<postal>
<street>Massachusetts Institute of Technology</street>
<street>77 Massachusetts Avenue</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>USA</country></postal>
<phone>+1-617-253-5702</phone>
<facsimile>+1-617-258-5999</facsimile>
<email>timbl@w3.org</email>
<uri>http://www.w3.org/People/Berners-Lee/</uri></address></author>
<author initials="R." surname="Fielding" fullname="Roy T. Fielding">
<organization abbrev="Day Software">Day Software</organization>
<address>
<postal>
<street>5251 California Ave., Suite 110</street>
<city>Irvine</city>
<region>CA</region>
<code>92617</code>
<country>USA</country></postal>
<phone>+1-949-679-2960</phone>
<facsimile>+1-949-679-2972</facsimile>
<email>fielding@gbiv.com</email>
<uri>http://roy.gbiv.com/</uri></address></author>
<author initials="L." surname="Masinter" fullname="Larry Masinter">
<organization abbrev="Adobe Systems">Adobe Systems Incorporated</organization>
<address>
<postal>
<street>345 Park Ave</street>
<city>San Jose</city>
<region>CA</region>
<code>95110</code>
<country>USA</country></postal>
<phone>+1-408-536-3024</phone>
<email>LMM@acm.org</email>
<uri>http://larry.masinter.net/</uri></address></author>
<date year="2005" month="January"/>
<area>Applications</area>
<keyword>uniform resource identifier</keyword>
<keyword>URI</keyword>
<keyword>URL</keyword>
<keyword>URN</keyword>
<keyword>WWW</keyword>
<keyword>resource</keyword>
<abstract>
<t>
A Uniform Resource Identifier (URI) is a compact sequence of characters
that identifies an abstract or physical resource. This specification
defines the generic URI syntax and a process for resolving URI references
that might be in relative form, along with guidelines and security
considerations for the use of URIs on the Internet.
The URI syntax defines a grammar that is a superset of all valid URIs,
allowing an implementation to parse the common components of a URI
reference without knowing the scheme-specific requirements of every
possible identifier. This specification does not define a generative
grammar for URIs; that task is performed by the individual
specifications of each URI scheme.
</t></abstract></front>
<seriesInfo name="STD" value="66"/>
<seriesInfo name="RFC" value="3986"/>
<format type="TXT" octets="141811" target="http://www.rfc-editor.org/rfc/rfc3986.txt"/>
<format type="HTML" octets="214067" target="http://xml.resource.org/public/rfc/html/rfc3986.html"/>
<format type="XML" octets="163534" target="http://xml.resource.org/public/rfc/xml/rfc3986.xml"/>
</reference>
<reference anchor="RFC7230">
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
<author initials="R." surname="Fielding" fullname="R. Fielding">
<organization/></author>
<author initials="J." surname="Reschke" fullname="J. Reschke">
<organization/></author>
<date year="2014" month="June"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.</t></abstract></front>
<seriesInfo name="RFC" value="7230"/>
<format type="TXT" octets="205947" target="http://www.rfc-editor.org/rfc/rfc7230.txt"/>
</reference>
<reference anchor="RFC7231">
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
<author initials="R." surname="Fielding" fullname="R. Fielding">
<organization/></author>
<author initials="J." surname="Reschke" fullname="J. Reschke">
<organization/></author>
<date year="2014" month="June"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.</t></abstract></front>
<seriesInfo name="RFC" value="7231"/>
<format type="TXT" octets="235053" target="http://www.rfc-editor.org/rfc/rfc7231.txt"/>
</reference>
<reference anchor="RFC7301">
<front>
<title>Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension</title>
<author initials="S." surname="Friedl" fullname="S. Friedl">
<organization/></author>
<author initials="A." surname="Popov" fullname="A. Popov">
<organization/></author>
<author initials="A." surname="Langley" fullname="A. Langley">
<organization/></author>
<author initials="E." surname="Stephan" fullname="E. Stephan">
<organization/></author>
<date year="2014" month="July"/>
<abstract>
<t>This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection.</t></abstract></front>
<seriesInfo name="RFC" value="7301"/>
<format type="TXT" octets="17439" target="http://www.rfc-editor.org/rfc/rfc7301.txt"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC5246">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
<author initials="T." surname="Dierks" fullname="T. Dierks">
<organization/></author>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization/></author>
<date year="2008" month="August"/>
<abstract>
<t>This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name="RFC" value="5246"/>
<format type="TXT" octets="222395" target="http://www.rfc-editor.org/rfc/rfc5246.txt"/>
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 02:38:16 |