-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathdraft-reddy-add-enterprise-split-dns-08.txt
616 lines (437 loc) · 26.9 KB
/
draft-reddy-add-enterprise-split-dns-08.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
ADD T. Reddy
Internet-Draft Akamai
Intended status: Standards Track D. Wing
Expires: July 24, 2022 Citrix
K. Smith
Vodafone
B. Schwartz
Google
January 20, 2022
Split-Horizon DNS Configuration
draft-reddy-add-enterprise-split-dns-08
Abstract
When split-horizon DNS is deployed by a network, certain domains can
be resolved authoritatively by the network-provided DNS resolver.
DNS clients that don't always use this resolver might wish to do so
for these domains. This specification enables networks to inform DNS
clients about domains that are inside the split-horizon DNS, and
describes how clients can confirm the local resolver's authority over
these domains.
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 https://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 July 24, 2022.
Copyright Notice
Copyright (c) 2022 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
Reddy, et al. Expires July 24, 2022 [Page 1]
Internet-Draft Split-Horizon DNS Configuration January 2022
(https://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
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Authorized Split Horizon . . . . . . . . . . . . . . . . 4
2.2. Domain Camping . . . . . . . . . . . . . . . . . . . . . 4
3. Provisioning Domains dnsZones . . . . . . . . . . . . . . . . 4
3.1. Confirming Authority over the Domains . . . . . . . . . . 5
3.1.1. Confirmation using a pre-configured public resolver . 5
3.1.2. Confirmation using DNSSEC . . . . . . . . . . . . . . 5
4. An example of Split-Horizon DNS Configuration . . . . . . . . 6
5. Split DNS Configuration for IKEv2 . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
To resolve a DNS query, there are three essential behaviors that an
implementation can apply: (1) answer from a local database, (2) query
the relevant authorities and their parents, or (3) ask a server to
query those authorities and return the final answer. Implementations
that use these behaviors are called "authoritative nameservers",
"full resolvers", and "forwarders" (or "stub resolvers"). However,
an implementation can also implement a mixture of these behaviors,
depending on a local policy, for each query. We term such an
implementation a "hybrid resolver".
Most DNS resolvers are hybrids of some kind. For example, stub
resolvers frequently support a local "hosts file" that preempts query
forwarding, and most DNS forwarders and full resolvers can also serve
responses from a local zone file. Other standardized hybrid
resolution behaviors include Local Root [RFC8806], mDNS [RFC6762],
and NXDOMAIN synthesis for .onion [RFC7686].
Reddy, et al. Expires July 24, 2022 [Page 2]
Internet-Draft Split-Horizon DNS Configuration January 2022
In many network environments, the network offers clients a DNS server
(e.g. DHCP OFFER, IPv6 Router Advertisement). Although this server
is formally specified as a recursive resolver (e.g. Section 5.1 of
[RFC6106]), some networks provide a hybrid resolver instead. If this
resolver acts as an authoritative server for some names, we say that
the network has "split-horizon DNS", because those names resolve in
this way only from inside the network.
Network clients that use pure stub resolution, sending all queries to
the network-provided resolver, will always receive the split-horizon
results. Conversely, clients that send all queries to a different
resolver or implement pure full resolution locally will never receive
them. Clients with either pure resolution behavior are out of scope
for this specification. Instead, this specification enables hybrid
clients to access split-horizon results from a network-provided
hybrid resolver, while using a different resolution method for some
or all other names.
To achieve the required security properties, clients must be able to
authenticate the DNS servers provided by the network, for example
using the techniques proposed in [I-D.ietf-add-dnr] and
[I-D.ietf-add-ddr], and prove that they are authorized to serve the
offered split-horizon DNS names. As a result, use of this
specification is limited to servers that support authenticated
encryption and split-horizon DNS names that are properly rooted in
the global DNS.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document makes use of the terms defined in [RFC8499]. The terms
"Private DNS", "Global DNS" and "Split DNS" are defined in [RFC8499].
'Encrypted DNS' refers to a DNS protocol that provides an encrypted
channel between a DNS client and server (e.g., DoT, DoH, or DoQ).
The terms 'Authorized Split Horizon' and 'Domain Camping' are also
defined.
Reddy, et al. Expires July 24, 2022 [Page 3]
Internet-Draft Split-Horizon DNS Configuration January 2022
2.1. Authorized Split Horizon
A split horizon configuration for some name is considered
"authorized" if any parent of that name has given the local network
permission to serve its own responses for that name. Such
authorizations generally extend to the entire subtree of names below
the authorization point.
2.2. Domain Camping
Domain Camping refers to operating a nameserver which claims to be
authoritative for a zone, but actually isn't. For example, a domain
called example.com on the Internet and an internal DNS server also
claims to be authoritative for example.com, but has no delegation
from example.com on the Internet. Someone might domain camp on a
popular domain name providing the ability to monitor queries and
modify answers for that domain.
A common variation on domain camping is "NXDOMAIN camping", in which
a nameserver claims a zone that does not exist in the global DNS.
This is a form of domain camping because it seizes a portion of the
parent zone without permission. The use of nonexistent TLDs for
local services is a form of NXDOMAIN camping on the root zone.
Any form of domain camping likely violates the IAB's guidance
regarding "the Unique DNS Root" [RFC2826].
3. Provisioning Domains dnsZones
Provisioning Domains (PvDs) are defined in [RFC7556] as sets of
network configuration information that clients can use to access
networks, including rules for DNS resolution and proxy configuration.
The PvD Key dnsZones is defined in [RFC8801]. The PvD Key dnsZones
notifies clients of names for which one of the network-provided
resolvers is authoritative. Attempting to resolve these names via
another resolver might fail or return results that are not correct
for this network.
Each dnsZones entry indicates a claim of authority over a domain and
its subdomains. For example, if the dnsZones entry is
"example.test", this covers "example.test", "www.example.test", and
"mail.eng.example.test", but not "otherexample.test" or
"example.test.net".
[RFC8801] defines a mechanism for discovering multiple Explicit PvDs
on a single network and their Additional Information by means of an
HTTP-over-TLS query using a URI derived from the PvD ID. This set of
additional configuration information is referred to as a Web
Reddy, et al. Expires July 24, 2022 [Page 4]
Internet-Draft Split-Horizon DNS Configuration January 2022
Provisioning Domain (Web PvD). The PvD RA option defined in
[RFC8801] SHOULD set the H-flag to indicate that Additional
Information is available. This Additional Information JSON object
SHOULD include the "dnsZones" key to define the DNS domains for which
the network claims authority.
3.1. Confirming Authority over the Domains
To comply with [RFC2826], each dnsZones entry must be authorized in
the global DNS hierarchy. To prevent domain camping, clients must
confirm this authorization before making use of the entry.
To enable confirmation, the client must discover and validate the
Authentication Domain Names (ADNs) of the network-designated
resolvers using a method such as DNR [I-D.ietf-add-dnr]. The client
must also perform an NS query for each dnsZones entry and confirm
that at least one of the ADNs appears in each NS RRSet. This NS
query must be conducted in a manner that is not vulnerable to
tampering by the local network. Suitable tamperproof resolution
strategies are described in Section 3.1.1 and Section 3.1.2.
Note that each dnsZones entry is authorized only for the specific
resolvers whose ADNs appear in its NS RRSet. If a network offers
multiple encrypted resolvers via DNR, each dnsZones entry may be
authorized for a distinct subset of the network-provided resolvers.
3.1.1. Confirmation using a pre-configured public resolver
The client sends an NS query for the domain in dnsZones to a pre-
configured resolver that is external to the network, over a secure
transport. Clients SHOULD apply whatever acceptance rules they would
otherwise apply when using this resolver (e.g. checking the AD bit,
validating RRSIGs).
3.1.2. Confirmation using DNSSEC
The client resolves the NS record using any resolution method of its
choice (e.g. querying one of the network-provided resolvers,
performing iterative resolution locally), and performs full DNSSEC
validation locally [RFC6698]. The result is processed based on its
DNSSEC validation state (Section 4.3 of [RFC4035]):
o "Secure": the NS record is used for confirmation.
o "Bogus" or "Indeterminate": the record is rejected and
confirmation is considered to have failed.
Reddy, et al. Expires July 24, 2022 [Page 5]
Internet-Draft Split-Horizon DNS Configuration January 2022
o "Insecure": the client SHOULD retry the confirmation process using
a different method, such as the one in Section 3.1.1, to ensure
compatibility with unsigned names.
4. An example of Split-Horizon DNS Configuration
Consider an organization that operates "example.com", and runs a
different version of its global domain on its internal network.
Today, on the Internet it publishes two NS records, "ns1.example.com"
and "ns2.example.com".
To add support for the mechanism described in this document, the
network and endpoints first need to support [I-D.ietf-add-dnr] and
[RFC8801]. Then, for each site, the administrator would add DNS
servers named "ns1.example.com" or "ns2.example.com" (the names
published on the Internet). Those names would be advertised to the
endpoints as described in [I-D.ietf-add-dnr].
The endpoints compliant with this specification can then determine
the network's internal nameservers are owned and managed by the same
entity that has published the NS records on the Internet as shown in
Figure 1:
Steps 1-2: The client joins the network, obtains an IP address, and
discovers the resolvers "ns1.example.com" and "ns2.example.com"
and their IP addresses using DNR [I-D.ietf-add-dnr]. Using
[RFC8801], the client also discovers the PvD FQDN is
"pvd.example.com".
Steps 3-7: The client establishes an encrypted DNS connection with
"ns1.example.com", validates its TLS certificate, and queries it
for "pvd.example.com" to retrieve the PvD JSON object. Note that
[RFC8801] in Section 4.1 mandates the PvD FQDN MUST be resolved
using the DNS servers indicated by the associated PvD. The PvD
contains:
{
"identifier": "pvd.example.com",
"expires": "2020-05-23T06:00:00Z",
"prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"],
"dnsZones:": ["example.com"]
}
The JSON keys "identifier", "expires", and "prefixes" are defined
in [RFC8801].
Steps 8-9: The client then uses an encrypted DNS connection to a
public resolver (e.g., 1.1.1.1) to issue NS queries for the
Reddy, et al. Expires July 24, 2022 [Page 6]
Internet-Draft Split-Horizon DNS Configuration January 2022
domains in dnsZones. The NS lookup for "example.com" will return
"ns1.example.com" and "ns2.example.com".
Step 10: As the network-provided nameservers are the same as the
names retrieved from the public resolver and the network-
designated resolver's certificate includes at least one of the
names retrieved from the public resolver, the client has finished
validation that the nameservers signaled in [I-D.ietf-add-dnr] and
[RFC8801] are owned and managed by the same entity that published
the NS records on the Internet. The endpoint will then use that
information from [I-D.ietf-add-dnr] and [RFC8801] to resolve names
within dnsZones.
+---------+ +---------------------+ +------------+ +---------+ +---------+
| client | | Network | | Network | | Router | | public |
| | | encrypted resolvr | | PvD server | | | | resolvr |
+---------+ +---------------------+ +------------+ +---------+ +---------+
| | | | |
| Router Solicitation (1) | | | |
|-------------------------------------------------------------->| |
| | | | |
| Router Advertisement with DNR hostnames & PvD FQDN (2) | |
|<--------------------------------------------------------------| |
| -------------------------------------\ | | | |
|-| now knows DNR hostnames & PvD FQDN | | | | |
| |------------------------------------| | | | |
| | | | |
| TLS connection to ns1.example.com (3) | | | |
|----------------------------------------->| | | |
| ---------------------------\ | | | |
|-| validate TLS certificate | | | | |
| |--------------------------| | | | |
| | | | |
| resolve pvd.example.com (4) | | | |
|----------------------------------------->| | | |
| | | | |
| AAAA records (5) | | | |
|<-----------------------------------------| | | |
| | | | |
| https://pvd.example.com/.well-known/pvd (6) | | |
|--------------------------------------------------->| | |
| | | | |
| 200 OK (JSON Additional Information) (7) | | |
|<---------------------------------------------------| | |
| -----------------------\ | | | |
|-| dnsZones=example.com | | | | |
| |----------------------| | | | |
| | | | |
Reddy, et al. Expires July 24, 2022 [Page 7]
Internet-Draft Split-Horizon DNS Configuration January 2022
| TLS connection | | | |
|-------------------------------------------------------------------------->|
| ---------------------------\ | | | |
|-| validate TLS certificate | | | | |
| |--------------------------| | | | |
| | | | |
| NS? example.com (8) | | | |
|-------------------------------------------------------------------------->|
| | | | |
| NS=ns1.example.com, ns2.example.com (9) |
|<--------------------------------------------------------------------------|
| -------------------------------\ | | | |
|-| both DNR ADNs are authorized | | | | |
| ----------------------\--------| | | | |
|-| finished validation | | | | |
| |---------------------| | | | |
| | | | |
| use network-designated resolver | | | |
| for example.com (10) | | | |
|----------------------------------------->| | | |
| | | | |
Figure 1: An Example of Split-Horizon DNS Configuration
5. Split DNS Configuration for IKEv2
The split-tunnel Virtual Private Network (VPN) configuration allows
the endpoint to access resources that reside in the VPN [RFC8598] via
the tunnel; other traffic not destined to the VPN does not traverse
the tunnel. In contrast, a non-split-tunnel VPN configuration causes
all traffic to traverse the tunnel into the VPN.
When the VPN tunnel is IPsec, the encrypted DNS resolver hosted by
the VPN service provider can be securely discovered by the endpoint
using the ENCDNS_IP*_* IKEv2 Configuration Payload Attribute Types
defined in [I-D.ietf-ipsecme-add-ike]. For split-tunnel VPN
configurations, the endpoint uses the discovered encrypted DNS server
to resolve domain names for which the VPN provider claims authority.
For non-split-tunnel VPN configurations, the endpoint uses the
discovered encrypted DNS server to resolve both global and private
domain names. For split-tunnel VPN configurations, the IKE client
can use any one of the mechanisms discussed in Section 3.1 to
determine if the VPN service provider is authoritative over the Split
Horizon DNS domains.
Other VPN tunnel types have similar configuration capabilities, not
detailed here.
Reddy, et al. Expires July 24, 2022 [Page 8]
Internet-Draft Split-Horizon DNS Configuration January 2022
6. Security Considerations
The content of dnsZones may be passed to another (DNS) program for
processing. As with any network input, the content SHOULD be
considered untrusted and handled accordingly. The client must
perform the mechanisms discussed in Section 3.1 to determine if the
network-designated encrypted resolvers are authoritative over the
domains in dnsZones. If they are not, the client must ignore those
dnsZones.
This specification does not alter DNSSEC validation behaviour. To
ensure compatibility with validating clients, network operators MUST
ensure that names under the split horizon are correctly signed or
place them in an unsigned zone.
7. IANA Considerations
This document has no IANA actions.
8. Acknowledgements
Thanks to Mohamed Boucadair, Jim Reid, Tommy Pauly, Paul Vixie, Paul
Wouters and Vinny Parla for the discussion and comments.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2826] Internet Architecture Board, "IAB Technical Comment on the
Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May
2000, <https://www.rfc-editor.org/info/rfc2826>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<https://www.rfc-editor.org/info/rfc4035>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <https://www.rfc-editor.org/info/rfc6698>.
Reddy, et al. Expires July 24, 2022 [Page 9]
Internet-Draft Split-Horizon DNS Configuration January 2022
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/info/rfc6762>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8801] Pfister, P., Vyncke, E., Pauly, T., Schinazi, D., and W.
Shao, "Discovering Provisioning Domain Names and Data",
RFC 8801, DOI 10.17487/RFC8801, July 2020,
<https://www.rfc-editor.org/info/rfc8801>.
9.2. Informative References
[I-D.ietf-add-ddr]
Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T.
Jensen, "Discovery of Designated Resolvers", draft-ietf-
add-ddr-04 (work in progress), November 2021.
[I-D.ietf-add-dnr]
Boucadair, M., Reddy, T., Wing, D., Cook, N., and T.
Jensen, "DHCP and Router Advertisement Options for the
Discovery of Network-designated Resolvers (DNR)", draft-
ietf-add-dnr-05 (work in progress), December 2021.
[I-D.ietf-ipsecme-add-ike]
Boucadair, M., Reddy, T., Wing, D., and V. Smyslov,
"Internet Key Exchange Protocol Version 2 (IKEv2)
Configuration for Encrypted DNS", draft-ietf-ipsecme-add-
ike-00 (work in progress), December 2021.
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration",
RFC 6106, DOI 10.17487/RFC6106, November 2010,
<https://www.rfc-editor.org/info/rfc6106>.
[RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain
Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015,
<https://www.rfc-editor.org/info/rfc7556>.
[RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use
Domain Name", RFC 7686, DOI 10.17487/RFC7686, October
2015, <https://www.rfc-editor.org/info/rfc7686>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>.
Reddy, et al. Expires July 24, 2022 [Page 10]
Internet-Draft Split-Horizon DNS Configuration January 2022
[RFC8598] Pauly, T. and P. Wouters, "Split DNS Configuration for the
Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 8598, DOI 10.17487/RFC8598, May 2019,
<https://www.rfc-editor.org/info/rfc8598>.
[RFC8806] Kumari, W. and P. Hoffman, "Running a Root Server Local to
a Resolver", RFC 8806, DOI 10.17487/RFC8806, June 2020,
<https://www.rfc-editor.org/info/rfc8806>.
Authors' Addresses
Tirumaleswar Reddy
Akamai
Embassy Golf Link Business Park
Bangalore, Karnataka 560071
India
Email: [email protected]
Dan Wing
Citrix Systems, Inc.
4988 Great America Pkwy
Santa Clara, CA 95054
USA
Email: [email protected]
Kevin Smith
Vodafone Group
One Kingdom Street
London
UK
Email: [email protected]
Benjamin Schwartz
Google LLC
Email: [email protected]
Reddy, et al. Expires July 24, 2022 [Page 11]