Split DNS Configuration for the Internet Key Exchange Protocol Version 2 (IKEv2)
RFC 8598
Yes
No Objection
Note: This ballot was opened for revision 13 and is now closed.
Alvaro Retana No Objection
Warren Kumari (was Discuss) No Objection
Thank you for addressing my DISCUSS. I still don't love this idea / solution, but after asking the DNSOP list for review (https://www.ietf.org/mail-archive/web/dnsop/current/msg24835.html) and getting feedback (https://www.ietf.org/mail-archive/web/dnsop/current/msg24881.html) I've been persuaded that the benefits (with the mitigations) outweigh the risks. ---- Original DISCUSS position ---- I hope I'm just missing something obvious here, but this seems like it may cause a significant security issue. Lots of "regular" users use VPNs for access the Internet, either to bypass censorship / content restrictions, or to improve their privacy. These are not "corporate" / "enterprise" VPNs, but rather public ones - and sometimes they are run by people I wouldn't entirely trust. What is to stop one of these VPN providers setting: INTERNAL_DNS_DOMAIN(www.paypal.com) INTERNAL_DNSSEC_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4...) or, better yet: INTERNAL_DNS_DOMAIN(com) INTERNAL_DNSSEC_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4...) and so being able to spoof DNSSEC for paypal.com / all of .com? This is especially worrying if something like DANE is ever deployed... The draft *does* says: "Other generic or public domains, such as top-level domains, similarly SHOULD NOT be whitelisted." - this doesn't really answer the above. 1: It is increasingly hard to know what is a "real" TLD (.internal? .bank? .home?) 2: How do I programatically tell if www.foo.net is a "public domain"? What is a public domain anyway? How is an implementer supposed to address this? It also says: "Any updates to this whitelist of domain names MUST happen via explicit human interaction to prevent invisible installation of trust anchors." Is my auntie really expected (or competent) to understand what "Your VPN provider, TrustVPN wants to whitelist com. Do you want to allow this? [Y/N]" means? I'm hoping that I'm completely misunderstanding how the INTERNAL_DNSSEC_TA bit works. Also, some of the DNS behavior is handwavey - I think that the document really should be reviewed by DNSOP, but will leave it to Eric to make that call. -------------- This section: " The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be passed to another (DNS) program for processing. As with any network input, the content SHOULD be considered untrusted and handled accordingly." feels a bit handwavey. Are there currently any DNSSEC validating clients which can easily take a targeted TA for a specific domain / set of domains? I’m also not quite sure how this interacts with delegations. E.g: example.com 600 IN NS ns01.internal.example And then INTERNAL_DNS_DOMAIN(internal.example) — if the client runs a local recursive, does it need to send the query to ns01 though the VPN or not?
(Adam Roach; former steering group member) Yes
Thanks to everyone who worked on this document. It seems a very useful extension to IKEv2. I have a handful of minor and editorial comments that you may want to consider addressing. --------------------------------------------------------------------------- Please expand "IKEv2" in the title and abstract. See https://www.rfc-editor.org/materials/abbrev.expansion.txt for details. --------------------------------------------------------------------------- §2.1: > To indicate support for Split DNS, an initiator includes one more > INTERNAL_DNS_DOMAIN attributes as defined in Section 3 as part of the > CFG_REQUEST payload. I can't parse this. Is it mean to say "...one or more..."? Or is "attributes" supposed to be "attribute"? --------------------------------------------------------------------------- §2.1: > includes an INTERNAL_DNSSEC_TA attribute, but does not inclue an Nit: "include" --------------------------------------------------------------------------- §2.1: > An initiator MAY convey its current DNSSEC trust anchors for the > domain specified in the INTERNAL_DNS_DOMAIN attribute. If it does > not wish to convey this information, it MUST use a length of 0. As an implementor, I would have no idea whether this was something I wanted to include. If it is configurable, then I would have no idea as an operator whether how to set such configuration. Could we add some guidance here about when implementations and/or operators might want to send this, and when they might not? --------------------------------------------------------------------------- §2.4.1: > The responder replies with two DNS server addresses, and two internal > domains, "example.com" and "city.other.com". The domain "other.com" appears to be in active use by an organization known as "Other Entertainment." Please consider using an example domain as described in RFC 2606 section 2 or 3. --------------------------------------------------------------------------- §2.4.2: > In this example, the initiator has no existing DNSSEC trust anchors > would the requested domain. the "example.com" dommain has DNSSEC Nit: "...domain. The..." --------------------------------------------------------------------------- §4: > For example, if the INTERNAL_DNS_DOMAIN attribute > specifies "example.com", then "example.com", "www.example.com" and > "mail.eng.example.com" MUST be resolved using the internal DNS > resolver(s), but "anotherexample.com" and "ample.com" SHOULD NOT be > resolved using the internal resolver and SHOULD use the system's > external DNS resolver(s). The domain "anotherexample.com" is in use by a personal web site. The domain "ample.com" is registered anonymously through Amazon.com. For this example that needs to show a domain whose name is a subset of the indicated domain, please consider using an example domain as described in RFC 2602 section 2. --------------------------------------------------------------------------- §5: > DNS records can be used to publish specific records containing trust > anchors for applications. The most common record type is the TLSA > record specified in [RFC6698]. This DNS record type publishes which > CA certificate or EE certificate to expect for a certain host name. Please expand "CA" and "EE". --------------------------------------------------------------------------- §5: > In most deployment scenario's, the IKE client has an expectation that Nit: "scenarios"
(Benjamin Kaduk; former steering group member) Yes
I am balloting YES because I think this mechanism has significant value, but I do also
have some substantial comments that will likely result in changes to the draft.
(I also have a number of nit-level comments.)
Section 1
nit: the Abstract and Introduction are supposed to stand on their own, so
starting off with "Split DNS is a common configuration" before defining it
makes the reader work a bit harder than perhaps they need to.
Section 2
When Split DNS
has been negotiated, the existing DNS server configuration attributes
will be interpreted as internal DNS servers that can resolve
hostnames within the internal domains.
nit: maybe add a word or two to emphasize that the existing attributes are
also IKEv2 Configuration Payload Attributes?
Section 2.1
If an INTERNAL_DNS_DOMAIN attribute is included
in the CFG_REQUEST, the initiator MUST also include one or more
INTERNAL_IP4_DNS and INTERNAL_IP6_DNS attributes in the CFG_REQUEST.
nit: I think I could parse this as saying that I need one or more IP4 and also
one or more IP6 attributes (i.e., precluding v4- or v6-only
configurations), which I assume is not the intent. Maybe "or" or "and/or"
would be better than "and"?
To indicate support for DNSSEC, an initiator includes one or more
INTERNAL_DNSSEC_TA attributes as defined in Section 3 as part of the
CFG_REQUEST payload. [...]
nit: There are perhaps philosophical arguments to have about whether this
indicates support for DNSSEC as a whole, or just for receiving trust
anchors for DNSSEC from the responder [for the split-DNS domain(s)].
Section 2.2
supported by the server, unless the initiator has been configured
with local polict to define a set of Split DNS domains to use by
default.
typo: "policy"
We have to use DNS presentation format for the DS records and not wire
format?
Section 2.4
Please consider using IPv6 examples, per
https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ .
Section 3.1
o Domain Name (0 or more octets) - A Fully Qualified Domain Name
used for Split DNS rules, such as "example.com", in DNS
presentation format and optionally using IDNA [RFC5890] for
Internationalized Domain Names. Implementors need to be careful
that this value is not null-terminated.
W.r.t. IDNA, is this an A-label or a U-label?
W.r.t NUL-termination, do they need to not send the zero byte or not expect
to receive one?
Section 3.2
Any
INTERNAL_DNSSEC_TA attribute that is not immediately preceded by an
INTERNAL_DNS_DOMAIN or another INTERNAL_DNSSEC_TA attribute applying
to the same domain name MUST be ignored and treated as a protocol
error.
Isn't "ignored" incompatible with "treated as a protocol error"?
Section 4
If a client is configured by local policy to only accept a limited
number of INTERNAL_DNS_DOMAIN values, the client MUST ignore any
other INTERNAL_DNS_DOMAIN values.
Is this a limited *number* or a limited *set*? (If the former, exposition
about which ones are the "other" ones is probably in order.)
private remote network using the IPsec connection. If all traffic is
routed over the IPsec connection, the existing global
INTERNAL_IP4_DNS and INTERNAL_IP6_DNS can be used without creating
specific DNS exemptions.
DNS or DNSSEC exemptions (i.e., both)?
Section 5
DNS records can be used to publish specific records containing trust
anchors for applications. The most common record type is the TLSA
record specified in [RFC6698]. This DNS record type publishes which
CA certificate or EE certificate to expect for a certain host name.
These records are protected by DNSSEC and thus can be trusted by the
application. [...]
I'm probably thinking too much about "trust" as a concept (due to the RATS
BoF), but especially given that this goes on to say that this is a local
policy decision, I'd suggest replacing "can be trusted" with something like
"has a trust path in" or "are trustable by". Merely being in DNS with
valid DNSSEC signatures does not make the client trust it; that's still a
local policy decision.
It allows the remote IKE/IPsec server to modify DNS
answers including its DNSSEC cryptographic signatures by overriding
existing DNS information with trust anchor conveyed via IKE and
(temporarilly) installed on the IKE client. [...]
nits: "including DNSSEC cryptographic signatures" (no "its"); "trust
anchor(s)"
IKE clients willing to accept INTERNAL_DNSSEC_TA attributes MUST use
a whitelist of one or more domains that can be updated out of band.
IKE clients with an empty whitelist MUST NOT use any
INTERNAL_DNSSEC_TA attributes received over IKE. Such clients MAY
interpret receiving an INTERNAL_DNSSEC_TA attribute for a non-
whitelisted domain as an indication that their local configuration
may need to be updated out of band.
[...]
IKE clients MAY interpret an INTERNAL_DNSSEC_TA for domain that was
not preconfigured as an indication that it needs to update its IKE
configuration (out of band). The client MUST NOT use such a
INTERNAL_DNSSEC_TA to reconfigure its local DNS settings.
These two paragraphs seem essentially redundant (the first seems better to
me).
IKE clients MUST ignore any received INTERNAL_DNSSEC_TA requests for
a FDQN for which it did not receive and accept an INTERNAL_DNS_DOMAIN
Configuration Payload.
nit: are these really "requests"?
Section 6
It's probably appropriate to reiterate here that "As discussed in Section
5, the INTERNAL_DNSSEC_TA mechanism allows the credential used to
authenticate an IKEv2 association to be leveraged into authenticating
credentials for TLS and other connections. This reflects something of a
privilege escalation, and initiators should ensure that they have
sufficient trust in the communications peer to responsibly use (or not use)
that elevated privilege."
If the initiator is using DNSSEC validation for a domain in its
public DNS view, and it requests and receives an INTERNAL_DNS_DOMAIN
attribute without an INTERNAL_DNSSEC_TA, it will need to reconfigure
its DNS resolver to allow for an insecure delegation. It SHOULD NOT
accept insecure delegations for domains that are DNSSEC signed in the
public DNS view, for which it has not explicitely requested such
deletation by specifying the domain specifically using a
INTERNAL_DNS_DOMAIN(domain) request.
It seems like heeding this SHOULD NOT would potentially require the
initiator to make extra DNS requests from the external view that it would
not otherwise need to make. I agree that this is the behavior we want to
encourage with respect to not downgrading away from DNSSEC, but it's less
clear to me that we want to encourage the initiator to go out of its way to
check, as opposed to just using information it may happen to have already.
(Eric Rescorla; former steering group member) Yes
(Alexey Melnikov; former steering group member) (was Discuss) No Objection
Thank you for addressing my DISCUSS.
(Alissa Cooper; former steering group member) No Objection
Section 5: "Enterprise Certificate Agency" --> I would have expected this to say Enterprise Certificate Authority. "Other generic or public domains, such as top-level domains, similarly SHOULD NOT be whitelisted." Under what exceptional circumstances would it make sense to whitelist a TLD? Is this like if I run Example Corp and I own .example?
(Ben Campbell; former steering group member) No Objection
- General: Once my client signals support for split DNS, what prevents a server from over claiming the domains that should be resolved via the private DNS servers? Perhaps for purposes of employee monitoring or censoring NTFW domains? (I've known some IT managers who would think that was a fine idea.) §6: "the IKE connection SHOULD only process the DNS information if the two connections are part of the same logical entity" How does a client determine the connections are part of the same logical entity? I can think of some ways, but I think the draft should be give some explicit guidance.
(Deborah Brungard; former steering group member) No Objection
(Ignas Bagdonas; former steering group member) No Objection
(Martin Vigoureux; former steering group member) No Objection
(Mirja Kühlewind; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
Perhaps it would be helpful to give an example of why A client using these configuration payloads will be able to request and receive Split DNS configurations using the INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA configuration attributes. The client device can use the internal DNS server(s) for any DNS queries within the assigned domains. DNS queries for other domains SHOULD be sent to the regular external DNS server. DNS queries for other domains might not be sent to the regular external DNS server? I'm thinking of one, but I'm flat-out guessing.
(Suresh Krishnan; former steering group member) No Objection
* Sections 3.1 and 7 I have a hard time seeing why the length of the INTERNAL_DNS_DOMAIN attribute would ever be zero. Do you expect someone to send an empty attribute? If not, the attribute definition should be updated in Section 7. * Meta comment Since the draft needs and uses a lot of example domain names, I would suggest using a reserved TLD (e.g. ".example") from BCP32 to build up the examples instead of using registered domain names.
(Terry Manderson; former steering group member) No Objection
Thanks for the time and effort invested in this document. I'm also very interested to see the resolution to Warren's DISCUSS regarding ipsecme-split-dns being used as an easy tool to over-claim entire sections of the DNS hierarchy. Perhaps specifying that the DOMAIN and TA sent to the client MUST be in the administrative control of the VPN provider (I'm not sure I read that in the draft) might be one way out, yet I wonder if this is a case of simply having to trust that the VPN provider does the right thing (as cold as that leaves me) regardless of the words in the document.