DNS Extensions for Proxying IP in HTTP
draft-schinazi-masque-connect-ip-dns-00
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | David Schinazi | ||
| Last updated | 2024-03-18 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-schinazi-masque-connect-ip-dns-00
MASQUE D. Schinazi
Internet-Draft Google LLC
Intended status: Standards Track 19 March 2024
Expires: 20 September 2024
DNS Extensions for Proxying IP in HTTP
draft-schinazi-masque-connect-ip-dns-00
Abstract
Proxying IP in HTTP allows building a VPN through HTTP load
balancers. However, at the time of writing, that mechanism doesn't
offer a mechanism for communicating DNS information inline. In
contrast, most existing VPN protocols provide a mechanism to exchange
DNS configuration information. This document describes an extension
that exchanges this information using HTTP capsules.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://DavidSchinazi.github.io/draft-schinazi-masque-connect-ip-dns/
draft-schinazi-masque-connect-ip-dns.html. Status information for
this document may be found at https://datatracker.ietf.org/doc/draft-
schinazi-masque-connect-ip-dns/.
Discussion of this document takes place on the Multiplexed
Application Substrate over QUIC Encryption Working Group mailing list
(mailto:masque@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/masque/. Subscribe at
https://www.ietf.org/mailman/listinfo/masque/.
Source for this draft and an issue tracker can be found at
https://github.com/DavidSchinazi/draft-schinazi-masque-connect-ip-
dns.
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/.
Schinazi Expires 20 September 2024 [Page 1]
Internet-Draft CONNECT-IP DNS March 2024
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 20 September 2024.
Copyright Notice
Copyright (c) 2024 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 (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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3
2. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. DNS_REQUEST Capsule . . . . . . . . . . . . . . . . . . . 5
2.2. DNS_ASSIGN Capsule . . . . . . . . . . . . . . . . . . . 5
3. Handling . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 7
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Proxying IP in HTTP ([CONNECT-IP]) allows building a VPN through HTTP
load balancers. However, at the time of writing, that mechanism
doesn't offer a mechanism for communicating DNS information inline.
In contrast, most existing VPN protocols provide a mechanism to
exchange DNS configuration information (e.g., [IKEv2]). This
document describes an extension that exchanges this information using
HTTP capsules ([HTTP-DGRAM]).
Schinazi Expires 20 September 2024 [Page 2]
Internet-Draft CONNECT-IP DNS March 2024
1.1. Conventions and Definitions
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.
2. Mechanism
Similar to how Proxying IP in HTTP exchanges IP addresses
(Section 4.7 of [CONNECT-IP]), this mechanism leverages capsules to
request configuration and to assign it. Similarly, this mechanism is
bidirectional: either endpoint can request DNS configuration by
sending a DNS_REQUEST capsule, and either endpoint can send DNS
configuration in a DNS_ASSIGN capsule. These capsules follow the
format defined below.
Nameserver Address {
IP Version (8),
IP Address (32..128),
}
Figure 1: Nameserver Address Format
Each Nameserver Address contains the following fields:
IP Version: IP Version of this nameserver address, encoded as an
unsigned 8-bit integer. It MUST be either 4 or 6.
IP Address: DNS nameserver IP address. If the IP Version field has
value 4, the IP Address field SHALL have a length of 32 bits. If
the IP Version field has value 6, the IP Address field SHALL have
a length of 128 bits.
Domain {
Domain Length (i),
Domain Name (..),
}
Figure 2: Internal Domain Format
Each Domain contains the following fields:
Domain Length: Length of the following Domain field, encoded as a
variable-length integer.
Domain Name: Fully Qualified Domain Name in DNS presentation format
Schinazi Expires 20 September 2024 [Page 3]
Internet-Draft CONNECT-IP DNS March 2024
and using an Internationalized Domain Names for Applications
(IDNA) A-label ([IDNA]).
DNS Configuration {
Request ID (i),
Nameserver Address Count (i),
Nameserver Address (..) ...,
Internal Domain Count (i),
Internal Domain (..) ...,
Search Domain Count (i),
Search Domain (..) ...,
}
Figure 3: Assigned Address Format
Each DNS Configuration contains the following fields:
Request ID:
Request identifier, encoded as a variable-length integer. If this
DNS Configuration is part of a request, then this contains a
unique request identifier. If this DNS configuration is part of
an assignment that is in response to a DNS configuration request
then this field SHALL contain the value of the corresponding field
in the request. If this DNS configuration is part of an
unsolicited assignment, this field SHALL be zero.
Nameserver Address Count:
The number of Nameserver Address structures following this field.
Encoded as a variable-length integer.
Nameserver Address:
A series of Nameserver Address structures representing DNS name
servers.
Internal Domain Count:
The number of Domain structures following this field. Encoded as
a variable-length integer.
Internal Domain:
A series of Domain structures representing internal DNS names.
Search Domain Count:
The number of Domain structures following this field. Encoded as
a variable-length integer.
Search Domain:
A series of Domain structures representing search domains.
Schinazi Expires 20 September 2024 [Page 4]
Internet-Draft CONNECT-IP DNS March 2024
2.1. DNS_REQUEST Capsule
The DNS_REQUEST capsule (see Section 5 for the value of the capsule
type) allows an endpoint to request DNS configuration from its peer.
The capsule allows the endpoint to optionally indicate a preference
for which DNS configuration it would get assigned. The sender can
indicate that it has no preference by not sending any addresses or
names in its request DNS Configuration.
DNS_REQUEST Capsule {
Type (i) = DNS_REQUEST,
Length (i),
DNS Configuration (..),
}
Figure 4: DNS_REQUEST Capsule Format
When sending a DNS_REQUEST capsule, the sender MUST generate and send
a new non-zero request ID that was not previously used on this IP
Proxying stream.
An endpoint that receives a DNS_REQUEST capsule SHALL reply by
sending a DNS_ASSIGN capsule with the corresponding request ID. That
DNS_ASSIGN capsule MAY be empty, that indicates that its sender has
no DNS configuration to share with its peer.
2.2. DNS_ASSIGN Capsule
The DNS_ASSIGN capsule (see Section 5 for the value of the capsule
type) allows an endpoint to send DNS configuration to its peer.
DNS_ASSIGN Capsule {
Type (i) = DNS_ASSIGN,
Length (i),
DNS Configuration (..),
}
Figure 5: DNS_ASSIGN Capsule Format
When sending a DNS_ASSIGN capsule in response to a received
DNS_REQUEST capsule, the Request ID field in the DNS_ASSIGN capsule
SHALL be set to the value in the received DNS_REQUEST capsule.
Otherwise the request ID MUST be set to zero.
Schinazi Expires 20 September 2024 [Page 5]
Internet-Draft CONNECT-IP DNS March 2024
3. Handling
Note that internal domains include subdomains. In other words, if
the DNS configuration contains a domain, that indicates that the
corresponding domain and all of its subdomains can be resolved by the
nameservers exchanged in the same DNS configuration.
As with other IP Proxying capsules, the receiver can decide to
whether to use or ignore the configuration information. For example,
in the consumer VPN scenario, clients will trust the server and apply
received DNS configuration, whereas servers will ignore any DNS
configuration sent by the client.
4. Security Considerations
Acting on received DNS_ASSIGN capsules can have significant impact on
endpoint security. Endpoints MUST ignore DNS_ASSIGN capsules unless
it has reason to trust its peer and is expecting DNS configuration
from it.
The requirement for an endpoint to always send DNS_ASSIGN capsules in
response to DNS_REQUEST capsules could lead it to buffer unbounded
amounts of memory if the underlying stream is blocked by flow or
congestion control. Implementations MUST place an upper bound on
that buffering and abort the stream if that limit is reached.
5. IANA Considerations
This document, if approved, will request IANA add the following
values to the "HTTP Capsule Types" registry maintained at
<https://www.iana.org/assignments/masque>.
+============+==============+
| Value | Capsule Type |
+============+==============+
| 0x2B40144C | DNS_ASSIGN |
+------------+--------------+
| 0x2B40144D | DNS_REQUEST |
+------------+--------------+
Table 1: New Capsules
Note that, if this document is approved, the values defined above
will be replaced by smaller ones before publication.
All of these new entries use the following values for these fields:
Status: provisional (permanent if this document is approved)
Schinazi Expires 20 September 2024 [Page 6]
Internet-Draft CONNECT-IP DNS March 2024
Reference: This document
Change Controller: IETF
Contact: masque@ietf.org
Notes: None
6. References
6.1. Normative References
[CONNECT-IP]
Pauly, T., Ed., Schinazi, D., Chernyakhovsky, A.,
Kühlewind, M., and M. Westerlund, "Proxying IP in HTTP",
RFC 9484, DOI 10.17487/RFC9484, October 2023,
<https://www.rfc-editor.org/rfc/rfc9484>.
[HTTP-DGRAM]
Schinazi, D. and L. Pardue, "HTTP Datagrams and the
Capsule Protocol", RFC 9297, DOI 10.17487/RFC9297, August
2022, <https://www.rfc-editor.org/rfc/rfc9297>.
[IDNA] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/rfc/rfc5890>.
[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/rfc/rfc2119>.
[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/rfc/rfc8174>.
6.2. Informative References
[IKEv2] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/rfc/rfc7296>.
[IKEv2-DNS]
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/rfc/rfc8598>.
Schinazi Expires 20 September 2024 [Page 7]
Internet-Draft CONNECT-IP DNS March 2024
Acknowledgments
The mechanism is this document was inspired by [IKEv2] and
[IKEv2-DNS].
Author's Address
David Schinazi
Google LLC
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States of America
Email: dschinazi.ietf@gmail.com
Schinazi Expires 20 September 2024 [Page 8]