Summary: Needs 7 more YES or NO OBJECTION positions to pass.
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.