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