idnits 2.17.1 draft-kuehlewind-masque-proxy-discovery-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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** 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 186: '...he proxy addresses SHOULD no longer be...' RFC 2119 keyword, line 220: '...he proxy addresses SHOULD no longer be...' RFC 2119 keyword, line 260: '... means that the proxy addresses SHOULD...' RFC 2119 keyword, line 377: '...erved: 8 bits. MUST be set to 0 on t...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 11, 2020) is 1322 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-masque-connect-udp-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Kuehlewind 3 Internet-Draft Z. Sarker 4 Intended status: Informational M. Westerlund 5 Expires: March 15, 2021 Ericsson 6 September 11, 2020 8 Discovery Mechanisms for QUIC-based Proxy Services 9 draft-kuehlewind-masque-proxy-discovery-00 11 Abstract 13 Often an intermediate instance (such as a proxy server) is used to 14 connect to a web server or a communicating peer if a direct end-to- 15 end IP connectivity is not possible or the proxy can provide a 16 support service like, e.g., address anonymisation. To use a non- 17 transparent proxy a client explicitly connects to it and requests 18 forwarding to the final target server. The MASQUE Connect-UDP Proxy 19 service is an example of such a proxy service. The client either 20 knows the proxy address as preconfigured in the application or can 21 dynamically learn about available proxy services. This document 22 describes different discovery mechanisms for non-transparent proxies 23 that are either located in the local network, e.g. home or enterprise 24 network, in the access network, or somewhere else on the Internet 25 usually close to the target server or even in the same network as the 26 target server. 28 This document assumes that the non-transparent proxy server is 29 connected via QUIC and discusses potential discovery mechanisms for 30 such a QUIC-based, non-transparent proxy. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on March 15, 2021. 49 Copyright Notice 51 Copyright (c) 2020 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Using DHCP for Local Discovery . . . . . . . . . . . . . . . 4 68 3. Using IPv6 Neighbor Discovery for Local Discovery . . . . . . 5 69 3.1. Using PVDs . . . . . . . . . . . . . . . . . . . . . . . 6 70 4. DNS Service Discovery (DNS-SD) . . . . . . . . . . . . . . . 7 71 4.1. Local discovery using mDNS . . . . . . . . . . . . . . . 7 72 4.2. Discovery for Remote Domains . . . . . . . . . . . . . . 8 73 5. Using PCP options . . . . . . . . . . . . . . . . . . . . . . 8 74 6. Using Anycast address . . . . . . . . . . . . . . . . . . . . 9 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 8. Security Consideration . . . . . . . . . . . . . . . . . . . 10 77 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 78 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 81 11.2. Informative References . . . . . . . . . . . . . . . . . 12 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 84 1. Introduction 86 QUIC is a new transport protocol that was initially developed as a 87 way to optimize HTTP traffic by supporting multiplexing without head- 88 of-line-blocking and integrating security directly into the 89 transport. This tight integration of security allows the transport 90 and security handshakes to be combined into a single round-trip 91 exchange, after which both the transport connection and authenticated 92 encryption keys are ready. 94 Often an intermediate instance (such as a proxy server) is used to 95 connect to a web server or a communicating peer if a direct end-to- 96 end IP connectivity is not possible or the proxy can provide a 97 support service like, e.g., address anonymization. QUIC's ability to 98 multiplex, encrypt data, and migrate between network paths makes it 99 ideal for solutions that need to tunnel or proxy traffic. 101 Existing proxies that are based on TCP and HTTP are often 102 transparent. That is, they do not require the cooperation of the 103 ultimate connection endpoints, and are often not visible to one or 104 both of the endpoints. When QUIC provides the basis for a tunneling 105 and proxying solutions, such as defined in MASQUE WG, this 106 relationship will change. At least one of the endpoints will be 107 aware of the proxy, explicitly connect to it, and coordinate with it. 108 This makes the proxy and tunneling non-transparent to at least one 109 party, most often the client. This allows client hosts to make 110 explicit decisions about the services they request from proxies (for 111 example, simple forwarding or more advance performance-optimizing 112 services), and to do so using a secure communication channel between 113 itself and the proxy. [I-D.kuehlewind-masque-quic-substrate] 114 describes some of the use cases for using QUIC for proxying and 115 tunneling. 117 To use a non-transparent proxy service a client explicitly connects 118 to the proxy and requests forwarding to the final target server. The 119 client either knows the proxy address as preconfigured in the 120 application or can dynamically learn about available proxy servers. 121 This document describes different discovery mechanisms for proxies 122 that are either located in the local network, e.g. home or enterprise 123 network, in the access network, or somewhere else on the Internet 124 usually close to the target server or even in the same network as the 125 target server. For the rest of the document the work "proxy" refers 126 to a non-transparent proxy. 128 The discovery mechanisms proposed in this document cover a range of 129 approaches based on IETF protocols and commonly used mechanisms, 130 however, other mechanisms in more specialized networks are possible 131 as well. For 5G networks, the 3GPP specifies an extended exposure 132 framework that potentially can also be used for proxy discovery and 133 routing support. 135 After discovery a client can connect to the proxy and request a proxy 136 service, such as the MASQUE Connect-UDP service 137 [I-D.ietf-masque-connect-udp], to instruct the proxy forward traffic 138 to a target server as well as negotiate and request proxy 139 capabilities and parameters. 141 The specific solutions for discovery of proxy services and their 142 specification will need to evolve as the nature of the MASQUE proxy 143 services evolve. How specifically bound the discovery should be to 144 MASQUE proxy services also will need further discussion. 146 2. Using DHCP for Local Discovery 148 DHCP [RFC2131] can be used to announce the IP address of local proxy 149 server in IPv4 networks, as well DHCPv6 [RFC8415] in IPv6 networks. 150 New options for both protocols are specified below and as shown in 151 Figure 1 and Figure 2. In both cases the option can contain one or 152 more IP addresses (but of course IPV4 and IOv6 address respectively) 153 of QUIC-based proxy servers (indicated by the Q flag). All of the 154 addresses in one option share the same Lifetime value. If it is 155 desirable to have different Lifetime values, multiple options can be 156 used. 158 0 1 159 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 160 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 161 | Code | Len | 162 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 163 | Reserved |Q | 164 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 165 | Lifetime | 166 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 167 | | 168 : IPv4 Addresses of QUIC-based Proxy Servers : 169 | | 170 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 172 Figure 1: IPv4 Proxy Discovery DHCP option format 174 Code: Proxy Discovery option code (TBD) (8 bit) 176 Len: length of the option (without the Code and Len fields) in units 177 of octets. The minimum value is 8 if one IPv4 address is 178 contained in the option. Every additional IPv4 address increases 179 the length by 4. (8-bit unsigned integer) 181 Q: is set to one if proxy supports QUIC on port 443 (1 bit) 183 Lifetime: maximum time in seconds (relative to the time the packet 184 is received) over which these IP4 addresses can be used for proxy 185 discovery. A value of all one bits (0xffff) represents infinity. 186 A value of zero means that the proxy addresses SHOULD no longer be 187 used. (16-bit unsigned integer) 189 IPv4 Addresses of QUIC-based Proxy Servers: one or more 64-bit IPv4 190 addresses of QUIC-based proxy servers. The number of addresses is 191 determined by the Length field. That is, the number of addresses 192 is equal to (Length - 4) / 4. 194 0 1 2 3 195 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | option-code | option-len | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Reserved |Q| Lifetime | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | | 202 : IPv6 Addresses of QUIC-based Proxy Servers : 203 | | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 Figure 2: IPv6 Proxy Discovery DHCP option format 208 option-code: Proxy Discovery option code (TBD) (16 bit) 210 option-len: length of the option (without the Type and Length 211 fields) in units of octets. The minimum value is 20 if one IPv6 212 address is contained in the option. Every additional IPv6 address 213 increases the length by 16. (16-bit unsigned integer) 215 Q: is set to one if proxy supports QUIC on port 443 (1 bit) 217 Lifetime: maximum time in seconds (relative to the time the packet 218 is received) over which these IPv6 addresses can be used for proxy 219 discovery. A value of all one bits (0xffff) represents infinity. 220 A value of zero means that the proxy addresses SHOULD no longer be 221 used. (16-bit unsigned integer) 223 IPv6 Addresses of QUIC-based Proxy Servers: one or more 128-bit IPv6 224 addresses of QUIC-based proxy servers. The number of addresses is 225 determined by the Length field. That is, the number of addresses 226 is equal to (Length - 4) / 16. 228 3. Using IPv6 Neighbor Discovery for Local Discovery 230 If a proxy is located in the local network, information to discover a 231 proxy service can be provided in a new Router Advertisement (RA) 232 Option [RFC4861], the Proxy Discovery option. 234 0 1 2 3 235 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Type | Length | Reserved |Q| 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Lifetime | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | | 242 : IPv6 Addresses of QUIC-based Proxy Servers : 243 | | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 Figure 3: Proxy Discovery RA option format 248 Type: Proxy Discovery option type (TBD) (8 bit) 250 Length: length of the option (including the Type and Length fields) 251 in units of 8 octets. The minimum value is 3 if one IPv6 address 252 is contained in the option. Every additional IPv6 address 253 increases the length by 2. (8-bit unsigned integer) 255 Q: is set to one if proxy supports QUIC on port 443 (1 bit) 257 Lifetime: maximum time in seconds (relative to the time the packet 258 is received) over which these IPv6 addresses can be used for proxy 259 discovery. A value of all one bits (0xffffffff) represents 260 infinity. A value of zero means that the proxy addresses SHOULD 261 no longer be used. (32-bit unsigned integer) 263 IPv6 Addresses of QUIC-based Proxy Servers: one or more 128-bit IPv6 264 addresses of QUIC-based proxy servers. The number of addresses is 265 determined by the Length field. That is, the number of addresses 266 is equal to (Length - 1) / 2. 268 3.1. Using PVDs 270 If the local network provides configuration with an Explicit 271 Provisioning Domain (PvD) [RFC8801], the RA defined above can be used 272 with the PvD Option or alternatively proxy information can be 273 retrieved in the additional information JSON files associated with 274 the PvD ID. The endhost resolves the URL provided in the PvD ID into 275 an IP address using the local DNS server that is associated with the 276 corresponding PvD (see also section 3.4.4 of [RFC8801]). If a QUIC- 277 based proxy services is provided the additional information JSON file 278 contains the key "QuicProxyIP". It can then optionally also contain 279 more information about the specific proxy services offered using the 280 "ProxyService" key. Or the client can connect directly to the proxy 281 over QUIC on port 443 and request information about the proxy service 282 directly from the proxy server. 284 For remote network a Web PvD might be available that contains proxy 285 information. If provided, the PvD JSON configuration file 286 retrievable at the URI with the format: 288 https:///.well-known/pvd 290 4. DNS Service Discovery (DNS-SD) 292 [RFC6763] describes the use of SRV records to discover the available 293 instances of a type of service. To get a list of names of the 294 available instance for a certain service a client requests records of 295 type "PTR" (pointer from one name to another) in the DNS namespace 296 [RFC1035] for a name containing the service and domain. 298 As specified in [RFC6763] the client can perform a PTR query for a 299 list of available proxy instance in the following way: 301 _quicproxy._udp. 303 here the portion is the domain name where the service is 304 registered. The domain name can be obtained via DHCP options or 305 preconfigured. 307 The result of this PTR lookup is a set of zero or more PTR records 308 giving Service Instance names. Then to contact a particular service, 309 the client can query for the SRV [RFC2782] and TXT records of the 310 selected service instance name. The SRV record contains the IP 311 address of the proxy service instance as well as the port number. 312 The port number of QUIC-based proxy is usually expected to be 443 but 313 may differ. The TXT can contain additional information describing 314 the kind of proxy services that is offered. 316 4.1. Local discovery using mDNS 318 [RFC6762] defines the use of ".local." for performing DNS like 319 operations on the local link. Any DNS query for a name ending 320 "local." will be sent to a predefined IPv4 or IPv6 link local 321 multicast address. 323 To discover QUIC-based proxy services locally, the client request the 324 PTR record for the name: 326 _quicproxy._udp.local. 328 The result of this PTR lookup is a set of zero or more PTR records 329 giving Service Instance Names of the form: 331 ._quicproxy._udp.local. 333 Editors' Note: Or _masque._udp ? Or _proxy._quic._udp or 334 _quicproxy._http._udp ...? However in the later case the proxy 335 should probably also actually offer a webpage... 337 4.2. Discovery for Remote Domains 339 If a client wants to discover a QUIC-based proxy server for a remote 340 domain, this domain has to be known by the client, e.g. being 341 preconfigured in the application. 343 5. Using PCP options 345 Port Control Protocol (PCP), described in [RFC6887], defines 346 mechanism to do packet forwarding for different types of IPv4/Ipv6 347 Network Address Translators (NAT) or firewalls. Usual deployments of 348 PCP include Carrier-Grade NAT (CGN), Customer-premises Equipment 349 (CPE), or residential NATs. When PCP is used to control address 350 translation and forwarding, the PCP server can also be used to 351 announce the existence of a QUIC-based proxy to the client. 353 PCP allows options to be included in the PCP request and response 354 header. To announce information from the PCP server to the client, 355 information about who to find a the QUIC-based proxy can be included 356 in the response header as an option. As [RFC6887] describes, the 357 client will ignore any options that it does not understand. A new 358 PCP option carrying QUIC-based proxy information is speficied below. 360 0 1 2 3 361 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 |