idnits 2.17.1 draft-perkins-quic-p2p-mux-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 176: '... behind a NAT MAY use the lite mecha...' RFC 2119 keyword, line 231: '...ng protocol that MAY be used if there ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2019) is 1873 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-04) exists of draft-aboba-avtcore-quic-multiplexing-03 -- Possible downref: Normative reference to a draft: ref. 'I-D.aboba-avtcore-quic-multiplexing' == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-18 ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) == Outdated reference: A later version (-39) exists of draft-ietf-mmusic-ice-sip-sdp-24 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Perkins 3 Internet-Draft University of Glasgow 4 Intended status: Standards Track March 11, 2019 5 Expires: September 12, 2019 7 Peer-to-Peer Connections for the QUIC Transport Protocol 8 draft-perkins-quic-p2p-mux-00 10 Abstract 12 The QUIC transport protocol is intended to be a general purpose 13 transport, but is currently defined for client-server operation only. 14 To be applicable to all use cases, it needs to develop support for 15 peer-to-peer connection establishment. This memo describes how this 16 can be done, in outline form. Future work is needed to determine if 17 such peer-to-peer use of QUIC is desirable and, if so, to define a 18 complete and workable standard for peer-to-peer QUIC connection 19 establishment. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 12, 2019. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. QUIC Connection Establishment in the Presence of NATs . . . . 4 58 3.1. Gathering Candidates . . . . . . . . . . . . . . . . . . 4 59 3.2. Exchanging Candidates . . . . . . . . . . . . . . . . . . 4 60 3.3. Connectivity Checks . . . . . . . . . . . . . . . . . . . 5 61 3.4. Connection Establishment . . . . . . . . . . . . . . . . 6 62 4. Demultiplexing QUIC and STUN . . . . . . . . . . . . . . . . 6 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 8.2. Informative References . . . . . . . . . . . . . . . . . 8 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 QUIC [I-D.ietf-quic-transport] is a multiplexed and secure general- 74 purpose transport protocol. It is a connection-oriented protocol, 75 where the end-points take the role of either client or server. The 76 server passively listens for incoming connections; clients actively 77 connect to servers. Once the connection has been established, QUIC 78 is symmetric and allows either end-point to send and receive data on 79 multiplexed streams within the connection. 81 The client-server design of QUIC supports connection establishment 82 when client and server are in the same addressing realm, or if the 83 client is behind a network address/port translator (NAT). In this 84 latter case, the outgoing connection request establishes state in the 85 NAT, opening the port to allow the response from the server to reach 86 the client. QUIC provides connection migration and path validation 87 mechanisms that ensure connections can survive NAT rebinding events. 88 The initial version of QUIC has no support, however, for establishing 89 connections with a server that is behind a NAT. Specifically, QUIC 90 does not provide any mechanism to probe connectivity and create the 91 necessary NAT bindings to allow incoming connections to a server that 92 is behind a NAT. 94 The combination of the STUN [RFC5389] protocol and the Interactive 95 Connectivity Establishment (ICE) framework [RFC8445] provides those 96 mechanisms needed to establish connections in the presence of NATs, 97 supporting path probing and NAT binding discovery/creation. This 98 memo discusses how STUN and ICE can be used with QUIC to establish 99 connections when the server (and optionally the client) are behind 100 NATs. 102 2. Background 104 A NAT translates IP addresses and ports in IP and UDP packet headers, 105 separating the addressing realm used behind the NAT from the external 106 addressing realm. The addressing realm behind the NAT will often use 107 private IP addresses [RFC1918], and the external addressing realm is 108 often the public Internet, but this is not mandated. When a packet 109 is sent from an endpoint behind a NAT to an external endpoint, state 110 is created in the NAT allowing replies to be returned. This is known 111 as a NAT binding. If the NAT receives a packet on an external port 112 that is not subject to an active NAT binding, that packet is dropped. 114 Two QUIC endpoints wish to communicate. One or both of the endpoints 115 might be behind a NAT. If the QUIC client is behind a NAT, then the 116 outgoing initial packet sent from client to server to establish the 117 connection will create a NAT binding, allowing the response from the 118 QUIC server to pass the NAT and reach the client. The QUIC handshake 119 proceeds as normal, and the connection is established. However, if 120 the QUIC server is behind a NAT, then the initial packet sent by the 121 QUIC client will reach a port on the NAT for which there is no active 122 binding and will be dropped. The connection cannot be established in 123 this case. 125 ICE provides a framework for probing connectivity and creating NAT 126 bindings to allow connections to be established. It proceeds in four 127 phases: 129 o Gathering candidates: The endpoints discover the set of possible 130 IP addresses and ports ("transport addresses") on which they can 131 be reached, known as the set of "candidates". The candidate set 132 includes transport addresses bound to directly attached network 133 interfaces, translated transport addresses on the outside of a NAT 134 ("server-reflexive addresses"), and transport addresses allocated 135 via some form of relay ("relayed addresses". When gathering the 136 candidates, STUN is used to discover server reflexive addresses, 137 and the relay protocol (e.g., TURN) is used to determine relayed 138 addresses. 140 o Exchanging candidates: The endpoints exchanges their candidate 141 sets. Since the two endpoints cannot directly communicate, due to 142 the presence of the NATs, this exchange has to be done indirectly 143 via an external relay that is reachable by both endpoints. In the 144 multimedia conferencing systems for which ICE was defined, this 145 exchange takes place over the signalling channel (e.g., SIP or 146 WebRTC). This signalling is heavyweight and multimedia specific, 147 and is not appropriate for QUIC, so an alternative mechanism will 148 need to be defined. 150 o Connectivity checks: Once the candidate sets have been exchanged, 151 the endpoint systematically probe all pairs of local and remote 152 candidates, in priority order, to determine which candidate pairs 153 can be used to communicate. Each pair of candidates is probed, by 154 sending a request and checking for a response, in both directions. 155 This ensures that NAT bindings are established form each endpoint, 156 so connectivity is found even if both endpoints are behind NATs. 158 o Connection establishment: Once the connectivity checks succeed for 159 a suitable pair of candidates, the connection is established using 160 those candidates in the normal manner. 162 The ICE framework was designed to support multimedia conferencing, 163 and defines the signalling to exchange candidates in a way that is 164 specific to those systems. The technique is generic however, and can 165 be adapted to support NAT traversal and connection establishment for 166 QUIC. 168 3. QUIC Connection Establishment in the Presence of NATs 170 3.1. Gathering Candidates 172 Candidates are gathered as in Section 5 of [RFC8445]. The Initiating 173 Agent is the QUIC client. The Responding Agent is the QUIC server. 174 RTP and RTCP are not used, and candidates are gathered for a single 175 QUIC component instead. A QUIC server that "knows" that it is not 176 behind a NAT MAY use the lite mechanism described in Section 5.2 of 177 [RFC8445]. 179 Editor's note: clarifications are likely needed since the candidate 180 gathering in [RFC8445] is written assuming RTP and RTCP candidates, 181 but the approach looks suitable for QUIC without significant change. 183 3.2. Exchanging Candidates 185 Section 5.3 of [RFC8445] describes the information to be communicated 186 during the exchange of candidates. This can be used unchanged, but 187 the protocol used to exchange the candidates needs to be defined for 188 the ICE usage for QUIC. 190 The key design decision to make is what is the signalling protocol to 191 be used with ICE when establishing QUIC connections? The multimedia 192 conferencing uses of ICE naturally use an SDP offer/answer exchange 194 [I-D.ietf-mmusic-ice-sip-sdp] to convey this information, but asking 195 QUIC endpoints to implement SDP is not acceptable. An alternative is 196 needed. 198 There are two approaches. Firstly, the candidate exchange can be 199 performed out-of-band from the point of view of QUIC, by some higher 200 level signalling protocol. This assumes that the application that 201 uses QUIC will perform the necessary signalling. The application 202 will extract the set of local candidates from the QUIC stack and pass 203 them to the peer, then later pass in the set of remote candidates 204 received from the peer to the QUIC stack to trigger the systematic 205 probing of candidate addresses. This requires no QUIC-specific 206 protocol standardisation, other than to specify when the exchange 207 happens, since the signalling protocol is application specific and 208 the interface between the QUIC stack and that signalling protocol is 209 implementation specific. Standards are likely needed to define the 210 signalling for specific applications that use QUIC in this way. 212 Alternatively, the candidate exchange can be embedded into QUIC to 213 provide a general way for an indirect QUIC connection, made via a 214 middlebox relay of some sort, to signal candidates to the endpoints, 215 allowing them to bootstrap a direct peer-to-peer QUIC connection. 216 This is a significant change to the QUIC security model, since it 217 introduces a trusted middlebox that can relay candidate information, 218 so exposing that communication is taking place. However, such a 219 trusted device is necessary to bootstrap any direct peer-to-peer 220 connection in the presence of NATs, since it is not possible to 221 establish a direct connection without the help of a relay. Adding 222 the candidate exchange mechanism to QUIC allows the provision of 223 generic NAT traversal bootstrapping, allowing for reusable libraries 224 and common mechanisms, but potentially risks missing out on 225 application integration that could provide useful peer identity 226 guarantees and end-to-end security mechanisms for the signalling. 228 The right approach is likely to define a common abstract interface 229 between QUIC and the candidate exchange signalling, specifying what 230 information is to be exchanged and when. Then, also define a common 231 signalling protocol that MAY be used if there is no more suitable 232 application specific mechanism. 234 3.3. Connectivity Checks 236 The assumption is that connectivity checks proceed using STUN, as is 237 described in Section 7 of [RFC8445]. This has the benefit of working 238 with existing STUN servers, reusing existing specifications, and of 239 allowing code reuse. It also continues to exercise the ability of 240 middleboxes to pass STUN traffic, which is necessary for WebRTC NAT 241 traversal and to support other peer to peer applications. It further 242 ossifies STUN as the commonly used protocol for connectivity checks 243 in the Internet. 245 Alternatively, a QUIC-specific connectivity check protocol could be 246 developed. This would fulfil the same role STUN plays in [RFC8445], 247 but could use a syntax that is closer to that of other QUIC packets, 248 and could perhaps better integrate with the QUIC security mechanisms. 249 It is the belief of the author that the benefits of such a new syntax 250 for a STUN-like service do not outweigh the complexity of developing 251 the new mechanism, and that it is beneficial to have a single, widely 252 used, connectivity checking standard. It is, however, possible to 253 define a new connectivity check protocol, and such a protocol could 254 avoid some of the complexity and backwards compatibility features 255 included in STUN. 257 3.4. Connection Establishment 259 The connectivity checks determine that it is possible to send STUN 260 packets in UDP on an particular 5-tuple. Once the connectivity 261 checks have concluded, and a candidate pair has been selected, the 262 QUIC endpoints will attempt to establish a QUIC connection on the 263 chosen path. 265 To ensure the NAT ports are open, it is necessary that traffic flows 266 in both directions. It might be that it is sufficient to pick a peer 267 to act as the server (e.g., highest numbered IP address becomes the 268 server), or it might be necessary to perform a simultaneous open of 269 the QUIC connection (in a similar manner to TCP simultaneous open). 270 This will depend on the extent to which middleboxes attempt to detect 271 and control QUIC connection establishment. Simultaneous open seems 272 most robust, but at the expense of complexity. 274 4. Demultiplexing QUIC and STUN 276 STUN and QUIC packets can be demultiplexed based on the value of the 277 first octet, as described in [I-D.aboba-avtcore-quic-multiplexing]. 278 This provides a mechanism for middleboxes to distinguish peer to peer 279 and regular QUIC flows on the wire. This is beneficial in that it 280 further establishes STUN as the connectivity check mechanism for the 281 Internet, supporting its use in protocols such as WebRTC. It is 282 problematic, in that it provides a mechanism that can be used to 283 detect and prevent peer to peer uses of QUIC. 285 5. Security Considerations 287 To be completed. Key initial topics include: 1) changes to the QUIC 288 security model, since any attempt to provide relayed connectivity 289 checks for NAT traversal requires some degree of trust in the relay 290 server; 2) information leaks via STUN, if used for connectivity 291 checks, even if just leaking that a peer-to-peer connection 292 establishment is ongoing (the latter can likely be inferred from the 293 range of IP addresses used, but there might be other information 294 leaks); and 3) security properties of the signalling protocol used to 295 communicate with the relay server. 297 6. IANA Considerations 299 No IANA actions needed. Yet. 301 7. Acknowledgements 303 This work was supported by the UK Engineering and Physical Sciences 304 Research Council under grant EP/R04144X/1. 306 8. References 308 8.1. Normative References 310 [I-D.aboba-avtcore-quic-multiplexing] 311 Aboba, B., Thatcher, P., and C. Perkins, "QUIC 312 Multiplexing", draft-aboba-avtcore-quic-multiplexing-03 313 (work in progress), January 2019. 315 [I-D.ietf-quic-transport] 316 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 317 and Secure Transport", draft-ietf-quic-transport-18 (work 318 in progress), January 2019. 320 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 321 and E. Lear, "Address Allocation for Private Internets", 322 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 323 . 325 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 326 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 327 DOI 10.17487/RFC5389, October 2008, . 330 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 331 Connectivity Establishment (ICE): A Protocol for Network 332 Address Translator (NAT) Traversal", RFC 8445, 333 DOI 10.17487/RFC8445, July 2018, . 336 8.2. Informative References 338 [I-D.ietf-mmusic-ice-sip-sdp] 339 Petit-Huguenin, M., Nandakumar, S., and A. Keranen, 340 "Session Description Protocol (SDP) Offer/Answer 341 procedures for Interactive Connectivity Establishment 342 (ICE)", draft-ietf-mmusic-ice-sip-sdp-24 (work in 343 progress), November 2018. 345 Author's Address 347 Colin Perkins 348 University of Glasgow 349 School of Computing Science 350 Glasgow G12 8QQ 351 United Kingdom 353 Email: csp@csperkins.org