Internet DRAFT - draft-perkins-quic-p2p-mux
draft-perkins-quic-p2p-mux
Network Working Group C. Perkins
Internet-Draft University of Glasgow
Intended status: Standards Track March 11, 2019
Expires: September 12, 2019
Peer-to-Peer Connections for the QUIC Transport Protocol
draft-perkins-quic-p2p-mux-00
Abstract
The QUIC transport protocol is intended to be a general purpose
transport, but is currently defined for client-server operation only.
To be applicable to all use cases, it needs to develop support for
peer-to-peer connection establishment. This memo describes how this
can be done, in outline form. Future work is needed to determine if
such peer-to-peer use of QUIC is desirable and, if so, to define a
complete and workable standard for peer-to-peer QUIC connection
establishment.
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). 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 September 12, 2019.
Copyright Notice
Copyright (c) 2019 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
Perkins Expires September 12, 2019 [Page 1]
Internet-Draft Peer-to-Peer QUIC March 2019
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. QUIC Connection Establishment in the Presence of NATs . . . . 4
3.1. Gathering Candidates . . . . . . . . . . . . . . . . . . 4
3.2. Exchanging Candidates . . . . . . . . . . . . . . . . . . 4
3.3. Connectivity Checks . . . . . . . . . . . . . . . . . . . 5
3.4. Connection Establishment . . . . . . . . . . . . . . . . 6
4. Demultiplexing QUIC and STUN . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
QUIC [I-D.ietf-quic-transport] is a multiplexed and secure general-
purpose transport protocol. It is a connection-oriented protocol,
where the end-points take the role of either client or server. The
server passively listens for incoming connections; clients actively
connect to servers. Once the connection has been established, QUIC
is symmetric and allows either end-point to send and receive data on
multiplexed streams within the connection.
The client-server design of QUIC supports connection establishment
when client and server are in the same addressing realm, or if the
client is behind a network address/port translator (NAT). In this
latter case, the outgoing connection request establishes state in the
NAT, opening the port to allow the response from the server to reach
the client. QUIC provides connection migration and path validation
mechanisms that ensure connections can survive NAT rebinding events.
The initial version of QUIC has no support, however, for establishing
connections with a server that is behind a NAT. Specifically, QUIC
does not provide any mechanism to probe connectivity and create the
necessary NAT bindings to allow incoming connections to a server that
is behind a NAT.
The combination of the STUN [RFC5389] protocol and the Interactive
Connectivity Establishment (ICE) framework [RFC8445] provides those
mechanisms needed to establish connections in the presence of NATs,
Perkins Expires September 12, 2019 [Page 2]
Internet-Draft Peer-to-Peer QUIC March 2019
supporting path probing and NAT binding discovery/creation. This
memo discusses how STUN and ICE can be used with QUIC to establish
connections when the server (and optionally the client) are behind
NATs.
2. Background
A NAT translates IP addresses and ports in IP and UDP packet headers,
separating the addressing realm used behind the NAT from the external
addressing realm. The addressing realm behind the NAT will often use
private IP addresses [RFC1918], and the external addressing realm is
often the public Internet, but this is not mandated. When a packet
is sent from an endpoint behind a NAT to an external endpoint, state
is created in the NAT allowing replies to be returned. This is known
as a NAT binding. If the NAT receives a packet on an external port
that is not subject to an active NAT binding, that packet is dropped.
Two QUIC endpoints wish to communicate. One or both of the endpoints
might be behind a NAT. If the QUIC client is behind a NAT, then the
outgoing initial packet sent from client to server to establish the
connection will create a NAT binding, allowing the response from the
QUIC server to pass the NAT and reach the client. The QUIC handshake
proceeds as normal, and the connection is established. However, if
the QUIC server is behind a NAT, then the initial packet sent by the
QUIC client will reach a port on the NAT for which there is no active
binding and will be dropped. The connection cannot be established in
this case.
ICE provides a framework for probing connectivity and creating NAT
bindings to allow connections to be established. It proceeds in four
phases:
o Gathering candidates: The endpoints discover the set of possible
IP addresses and ports ("transport addresses") on which they can
be reached, known as the set of "candidates". The candidate set
includes transport addresses bound to directly attached network
interfaces, translated transport addresses on the outside of a NAT
("server-reflexive addresses"), and transport addresses allocated
via some form of relay ("relayed addresses". When gathering the
candidates, STUN is used to discover server reflexive addresses,
and the relay protocol (e.g., TURN) is used to determine relayed
addresses.
o Exchanging candidates: The endpoints exchanges their candidate
sets. Since the two endpoints cannot directly communicate, due to
the presence of the NATs, this exchange has to be done indirectly
via an external relay that is reachable by both endpoints. In the
multimedia conferencing systems for which ICE was defined, this
Perkins Expires September 12, 2019 [Page 3]
Internet-Draft Peer-to-Peer QUIC March 2019
exchange takes place over the signalling channel (e.g., SIP or
WebRTC). This signalling is heavyweight and multimedia specific,
and is not appropriate for QUIC, so an alternative mechanism will
need to be defined.
o Connectivity checks: Once the candidate sets have been exchanged,
the endpoint systematically probe all pairs of local and remote
candidates, in priority order, to determine which candidate pairs
can be used to communicate. Each pair of candidates is probed, by
sending a request and checking for a response, in both directions.
This ensures that NAT bindings are established form each endpoint,
so connectivity is found even if both endpoints are behind NATs.
o Connection establishment: Once the connectivity checks succeed for
a suitable pair of candidates, the connection is established using
those candidates in the normal manner.
The ICE framework was designed to support multimedia conferencing,
and defines the signalling to exchange candidates in a way that is
specific to those systems. The technique is generic however, and can
be adapted to support NAT traversal and connection establishment for
QUIC.
3. QUIC Connection Establishment in the Presence of NATs
3.1. Gathering Candidates
Candidates are gathered as in Section 5 of [RFC8445]. The Initiating
Agent is the QUIC client. The Responding Agent is the QUIC server.
RTP and RTCP are not used, and candidates are gathered for a single
QUIC component instead. A QUIC server that "knows" that it is not
behind a NAT MAY use the lite mechanism described in Section 5.2 of
[RFC8445].
Editor's note: clarifications are likely needed since the candidate
gathering in [RFC8445] is written assuming RTP and RTCP candidates,
but the approach looks suitable for QUIC without significant change.
3.2. Exchanging Candidates
Section 5.3 of [RFC8445] describes the information to be communicated
during the exchange of candidates. This can be used unchanged, but
the protocol used to exchange the candidates needs to be defined for
the ICE usage for QUIC.
The key design decision to make is what is the signalling protocol to
be used with ICE when establishing QUIC connections? The multimedia
conferencing uses of ICE naturally use an SDP offer/answer exchange
Perkins Expires September 12, 2019 [Page 4]
Internet-Draft Peer-to-Peer QUIC March 2019
[I-D.ietf-mmusic-ice-sip-sdp] to convey this information, but asking
QUIC endpoints to implement SDP is not acceptable. An alternative is
needed.
There are two approaches. Firstly, the candidate exchange can be
performed out-of-band from the point of view of QUIC, by some higher
level signalling protocol. This assumes that the application that
uses QUIC will perform the necessary signalling. The application
will extract the set of local candidates from the QUIC stack and pass
them to the peer, then later pass in the set of remote candidates
received from the peer to the QUIC stack to trigger the systematic
probing of candidate addresses. This requires no QUIC-specific
protocol standardisation, other than to specify when the exchange
happens, since the signalling protocol is application specific and
the interface between the QUIC stack and that signalling protocol is
implementation specific. Standards are likely needed to define the
signalling for specific applications that use QUIC in this way.
Alternatively, the candidate exchange can be embedded into QUIC to
provide a general way for an indirect QUIC connection, made via a
middlebox relay of some sort, to signal candidates to the endpoints,
allowing them to bootstrap a direct peer-to-peer QUIC connection.
This is a significant change to the QUIC security model, since it
introduces a trusted middlebox that can relay candidate information,
so exposing that communication is taking place. However, such a
trusted device is necessary to bootstrap any direct peer-to-peer
connection in the presence of NATs, since it is not possible to
establish a direct connection without the help of a relay. Adding
the candidate exchange mechanism to QUIC allows the provision of
generic NAT traversal bootstrapping, allowing for reusable libraries
and common mechanisms, but potentially risks missing out on
application integration that could provide useful peer identity
guarantees and end-to-end security mechanisms for the signalling.
The right approach is likely to define a common abstract interface
between QUIC and the candidate exchange signalling, specifying what
information is to be exchanged and when. Then, also define a common
signalling protocol that MAY be used if there is no more suitable
application specific mechanism.
3.3. Connectivity Checks
The assumption is that connectivity checks proceed using STUN, as is
described in Section 7 of [RFC8445]. This has the benefit of working
with existing STUN servers, reusing existing specifications, and of
allowing code reuse. It also continues to exercise the ability of
middleboxes to pass STUN traffic, which is necessary for WebRTC NAT
traversal and to support other peer to peer applications. It further
Perkins Expires September 12, 2019 [Page 5]
Internet-Draft Peer-to-Peer QUIC March 2019
ossifies STUN as the commonly used protocol for connectivity checks
in the Internet.
Alternatively, a QUIC-specific connectivity check protocol could be
developed. This would fulfil the same role STUN plays in [RFC8445],
but could use a syntax that is closer to that of other QUIC packets,
and could perhaps better integrate with the QUIC security mechanisms.
It is the belief of the author that the benefits of such a new syntax
for a STUN-like service do not outweigh the complexity of developing
the new mechanism, and that it is beneficial to have a single, widely
used, connectivity checking standard. It is, however, possible to
define a new connectivity check protocol, and such a protocol could
avoid some of the complexity and backwards compatibility features
included in STUN.
3.4. Connection Establishment
The connectivity checks determine that it is possible to send STUN
packets in UDP on an particular 5-tuple. Once the connectivity
checks have concluded, and a candidate pair has been selected, the
QUIC endpoints will attempt to establish a QUIC connection on the
chosen path.
To ensure the NAT ports are open, it is necessary that traffic flows
in both directions. It might be that it is sufficient to pick a peer
to act as the server (e.g., highest numbered IP address becomes the
server), or it might be necessary to perform a simultaneous open of
the QUIC connection (in a similar manner to TCP simultaneous open).
This will depend on the extent to which middleboxes attempt to detect
and control QUIC connection establishment. Simultaneous open seems
most robust, but at the expense of complexity.
4. Demultiplexing QUIC and STUN
STUN and QUIC packets can be demultiplexed based on the value of the
first octet, as described in [I-D.aboba-avtcore-quic-multiplexing].
This provides a mechanism for middleboxes to distinguish peer to peer
and regular QUIC flows on the wire. This is beneficial in that it
further establishes STUN as the connectivity check mechanism for the
Internet, supporting its use in protocols such as WebRTC. It is
problematic, in that it provides a mechanism that can be used to
detect and prevent peer to peer uses of QUIC.
5. Security Considerations
To be completed. Key initial topics include: 1) changes to the QUIC
security model, since any attempt to provide relayed connectivity
checks for NAT traversal requires some degree of trust in the relay
Perkins Expires September 12, 2019 [Page 6]
Internet-Draft Peer-to-Peer QUIC March 2019
server; 2) information leaks via STUN, if used for connectivity
checks, even if just leaking that a peer-to-peer connection
establishment is ongoing (the latter can likely be inferred from the
range of IP addresses used, but there might be other information
leaks); and 3) security properties of the signalling protocol used to
communicate with the relay server.
6. IANA Considerations
No IANA actions needed. Yet.
7. Acknowledgements
This work was supported by the UK Engineering and Physical Sciences
Research Council under grant EP/R04144X/1.
8. References
8.1. Normative References
[I-D.aboba-avtcore-quic-multiplexing]
Aboba, B., Thatcher, P., and C. Perkins, "QUIC
Multiplexing", draft-aboba-avtcore-quic-multiplexing-03
(work in progress), January 2019.
[I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", draft-ietf-quic-transport-18 (work
in progress), January 2019.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<https://www.rfc-editor.org/info/rfc1918>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
DOI 10.17487/RFC5389, October 2008, <https://www.rfc-
editor.org/info/rfc5389>.
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018, <https://www.rfc-
editor.org/info/rfc8445>.
Perkins Expires September 12, 2019 [Page 7]
Internet-Draft Peer-to-Peer QUIC March 2019
8.2. Informative References
[I-D.ietf-mmusic-ice-sip-sdp]
Petit-Huguenin, M., Nandakumar, S., and A. Keranen,
"Session Description Protocol (SDP) Offer/Answer
procedures for Interactive Connectivity Establishment
(ICE)", draft-ietf-mmusic-ice-sip-sdp-24 (work in
progress), November 2018.
Author's Address
Colin Perkins
University of Glasgow
School of Computing Science
Glasgow G12 8QQ
United Kingdom
Email: csp@csperkins.org
Perkins Expires September 12, 2019 [Page 8]
